Menu
▾
▴
gnuplot-beta
|
From: Jonathan T. <jt...@as...> - 2013-04-12 22:39:32
|
Ethan Merritt <merritt@u.washington.edu> writes:
> Or maybe hardly anyone is using x11 anymore. I know I strongly prefer
> either wxt or qt to the x11 terminal. I'm not saying we shouldn't fix
> this if possible, but the reality is that I view the x11 terminal as having
> been superseded by newer, more capable terminal options. There
> are many things that it just doesn't handle very well (font scaling,
> non-ascii encodings, transparency, anti-aliasing, ...).
Dima Kogan <gn...@di...> replied
> My only reason for sticking with x11 is performance. Last year I tried
> wxt and qt, and they were both noticeably more sluggish. I just tried it
> again, and while qt was very slow, wxt seemed about as fast as x11. So
> maybe I'll jump ship too in a bit.
On my computer wxt is subjectively *much* more sluggish than x11.
I just tried a quantitative performance test (details below), and wxt
was about a factor of 3 slower than x11 when interactively rotating
the 'splot' of a medium-sized data file.
It's interesting that the relative performance of wxt vs x11 differs
so much from one system to another. I don't know whether this is the
underlying graphics hardware/acceleration, some feature(s) of the
different X servers used by wxt vs x11, or what.
It would be interesting to run such performance tests on a range of
different systems and see how the relative performance of different
terminals varies from one {gnuplot version, compiler, computer system}
to another.
Details of my performance test
==============================
This test measures the responsiveness of interactively rotating the
'splot' of a medium-sized data file. The data file can be downloaded at
http://www.astro.indiana.edu/~jthorn/spool/gnuplot-speed-test.dat
The file contains is a bit under 1/2 megabyte in size, and contains
16791 lines (16310 non-blank non-comment); each line containing 4 columns
of data (of which only the first 3 are used in this test).
The actual performance test is to enter the gnuplot commands
set terminal ....
unset hidden3d
set style data lines
splot 'gnuplot-speed-test.dat'
then enlarge the terminal window to a size of about 1200 x 1000 pixels,
and then interactively rotate the 3-D plot. Measure the frequency of
updates by dragging the mouse (i.e., rotating the plot) continuously for
10 seconds and counting the number of times the plot updates. If you
have a rapidly-updating CPU-usage meter, you can watch it to see what
fraction of the (a) CPU gnuplot and its outboard terminal driver are
using.
Test results
============
I'm using
> G N U P L O T
> Version 4.6 patchlevel 0 last modified 2012-03-04
> Build System: OpenBSD amd64
> Compile options:
> -READLINE +LIBREADLINE -HISTORY
> -BACKWARDS_COMPATIBILITY +BINARY_DATA
> +GD_PNG +GD_JPEG +GD_TTF +GD_GIF +ANIMATION
> -USE_CWDRC +X11 +X11_POLYGON +MULTIBYTE +X11_EXTERNAL +USE_MOUSE +HIDDEN3D_QUADTREE
> +DATASTRINGS +HISTOGRAMS +OBJECTS +STRINGVARS +MACROS +IMAGE +USER_LINETYPES +STATS
compiled with gcc 4.2.1 -O2. I'm run the tests on a Lenovo Thinkpad
T60 laptop, Intel Core 2 T7200 dual-core cpu locked at its minimum clock
rate of 1.0GHz (this makes timing easier), ATI Radeon Mobility X1400
graphics, running OpenBSD 5.1-stable.
On my computer, x11 updates this plot between 26 and 28 times in 10 seconds
(using about 70-80% CPU on one core), while wxt updates around 8 or 9
times in 10 seconds (using about 100% CPU on one core).
ciao,
--
-- "Jonathan Thornburg [remove -animal to reply]" <jt...@as...>
Dept of Astronomy & IUCSS, Indiana University, Bloomington, Indiana, USA
on sabbatical in Canada starting August 2012
"Washing one's hands of the conflict between the powerful and the
powerless means to side with the powerful, not to be neutral."
-- quote by Freire / poster by Oxfam
|
|
From: Ethan M. <merritt@u.washington.edu> - 2013-04-13 00:20:53
|
On Friday, April 12, 2013 03:39:21 pm Jonathan Thornburg wrote:
> Ethan Merritt <merritt@u.washington.edu> writes:
> > Or maybe hardly anyone is using x11 anymore. I know I strongly prefer
> > either wxt or qt to the x11 terminal. I'm not saying we shouldn't fix
> > this if possible, but the reality is that I view the x11 terminal as having
> > been superseded by newer, more capable terminal options. There
> > are many things that it just doesn't handle very well (font scaling,
> > non-ascii encodings, transparency, anti-aliasing, ...).
>
> Dima Kogan <gn...@di...> replied
> > My only reason for sticking with x11 is performance. Last year I tried
> > wxt and qt, and they were both noticeably more sluggish. I just tried it
> > again, and while qt was very slow, wxt seemed about as fast as x11. So
> > maybe I'll jump ship too in a bit.
>
> On my computer wxt is subjectively *much* more sluggish than x11.
> I just tried a quantitative performance test (details below), and wxt
> was about a factor of 3 slower than x11 when interactively rotating
> the 'splot' of a medium-sized data file.
I don't think anyone is disputing that x11 is faster than wxt or qt
for 3D rotation. Qt in particular is slow in 3D, glacially slow for
image plots. If that is your typical usage then I can certainly understand
a preference for the faster terminal[s].
> It would be interesting to run such performance tests on a range of
> different systems and see how the relative performance of different
> terminals varies from one {gnuplot version, compiler, computer system}
> to another.
32-bit linux Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz
gcc 4.4.3
qt size 1200,1000 glacial
wxt size 1200,1000 approx 2.5 frames per second
x11 size 1200,1000 no visible lag in response to mouse movement
So yeah, the perceived speed runs from "glacial" to "infinitely fast".
On the other hand, wxt is quite fast enough to use for composing
a figure even though it doesn't spin smoothly. If I understand your
report correctly then my setup refreshes wxt at about the same rate
as yours refreshes x11.
The x11 terminal throughput was improved by 10%-20% for large plots in
version 4.7. That was accomplished by reducing the amount of data sent
through the pipe from gnuplot to gnuplot_x11, which doesn't necessarily
translate into an equivalent increase in the perceived interactive
responsiveness.
I have not looked into where the speed bottlenecks are in the
wxt terminal. Maybe it could be sped up, maybe not.
Note that the speed I see for your test case does not seem to depend
on the display window size. I think the time is almost entirely spent
copying data around internally, not by the actual graphics rendering.
I am told that using the OpenGL rendering mode for Qt makes it
significantly faster, but unfortunately that doesn't seem to be supported
by any of my test machines so I can't benchmark it.
Ethan
>
> Details of my performance test
> ==============================
>
> This test measures the responsiveness of interactively rotating the
> 'splot' of a medium-sized data file. The data file can be downloaded at
> http://www.astro.indiana.edu/~jthorn/spool/gnuplot-speed-test.dat
> The file contains is a bit under 1/2 megabyte in size, and contains
> 16791 lines (16310 non-blank non-comment); each line containing 4 columns
> of data (of which only the first 3 are used in this test).
>
> The actual performance test is to enter the gnuplot commands
> set terminal ....
> unset hidden3d
> set style data lines
> splot 'gnuplot-speed-test.dat'
> then enlarge the terminal window to a size of about 1200 x 1000 pixels,
> and then interactively rotate the 3-D plot. Measure the frequency of
> updates by dragging the mouse (i.e., rotating the plot) continuously for
> 10 seconds and counting the number of times the plot updates. If you
> have a rapidly-updating CPU-usage meter, you can watch it to see what
> fraction of the (a) CPU gnuplot and its outboard terminal driver are
> using.
>
>
> Test results
> ============
> I'm using
> > G N U P L O T
> > Version 4.6 patchlevel 0 last modified 2012-03-04
> > Build System: OpenBSD amd64
>
> > Compile options:
> > -READLINE +LIBREADLINE -HISTORY
> > -BACKWARDS_COMPATIBILITY +BINARY_DATA
> > +GD_PNG +GD_JPEG +GD_TTF +GD_GIF +ANIMATION
> > -USE_CWDRC +X11 +X11_POLYGON +MULTIBYTE +X11_EXTERNAL +USE_MOUSE +HIDDEN3D_QUADTREE
> > +DATASTRINGS +HISTOGRAMS +OBJECTS +STRINGVARS +MACROS +IMAGE +USER_LINETYPES +STATS
>
> compiled with gcc 4.2.1 -O2. I'm run the tests on a Lenovo Thinkpad
> T60 laptop, Intel Core 2 T7200 dual-core cpu locked at its minimum clock
> rate of 1.0GHz (this makes timing easier), ATI Radeon Mobility X1400
> graphics, running OpenBSD 5.1-stable.
>
> On my computer, x11 updates this plot between 26 and 28 times in 10 seconds
> (using about 70-80% CPU on one core), while wxt updates around 8 or 9
> times in 10 seconds (using about 100% CPU on one core).
>
> ciao,
>
>
--
Ethan A Merritt
Biomolecular Structure Center, K-428 Health Sciences Bldg
University of Washington, Seattle 98195-7742
|
|
From: <pl...@pi...> - 2013-04-13 10:31:11
|
On 04/13/13 02:18, Ethan Merritt wrote: > On my computer, x11 updates this plot between 26 and 28 times in 10 seconds Hey, you can count quicker that I can ;) This is good idea, is there a way to create a command line version of this or similar test that can be actually timed with 'time' command? I use a fast 32 bit CPU. I use almost exclusively wxt and confirm that it's rather sluggish with data files of that size. But since I mostly do straight , with lines, plots I just wait a second or so. Useful to know x11 is much faster. I have only done 3D plots on relatively small data files. It was a bit slow but usable. Next time I'll use x11. It would be interesting to see where the bottlenecks are but I think there is alway a significant hit when passing through an extra layer of software. The first graphics plotting software I produced in Turbo Pascal wrote straight to video memory and was plenty fast enough on an original XT PC with 480kB of RAM. The more layers of abstraction you add the slower it gets. Peter. |
|
From: Dima K. <gn...@di...> - 2013-04-13 00:44:42
|
Jonathan Thornburg <jt...@as...> writes:
> Dima Kogan <gn...@di...> replied
>> My only reason for sticking with x11 is performance. Last year I tried
>> wxt and qt, and they were both noticeably more sluggish. I just tried it
>> again, and while qt was very slow, wxt seemed about as fast as x11. So
>> maybe I'll jump ship too in a bit.
>
> On my computer wxt is subjectively *much* more sluggish than x11.
> I just tried a quantitative performance test (details below), and wxt
> was about a factor of 3 slower than x11 when interactively rotating
> the 'splot' of a medium-sized data file.
>
> It's interesting that the relative performance of wxt vs x11 differs
> so much from one system to another. I don't know whether this is the
> underlying graphics hardware/acceleration, some feature(s) of the
> different X servers used by wxt vs x11, or what.
>
> It would be interesting to run such performance tests on a range of
> different systems and see how the relative performance of different
> terminals varies from one {gnuplot version, compiler, computer system}
> to another.
I just tried out your test, and I do see the wxt being slow. I retract
my statement that it seems quick-enough now. :) I see similar
differences in performance on two thinkpad laptops (integrated Intel
graphics and nvidia nvs140). Previously I used a thinkpad with a radeon
x1400 (such as what you have), and it was similarly slow.
It looks line an important factor to the slowness is the 'lines' plots.
If you change your test case to plot with points instead of lines, the
x11 becomes a LOT slower, but the wxt only somewhat so, and the two
become comparable.
dima
|
