Hmmm... I'm not sure how to do it (maybe David will chime in here).  One reason 
I see Prima as more potentially revolutionary as the basis for a data GUI than 
immediately useful for generating figures for journal articles, is that there's 
no obvious way (from the CPAN docs anyway) to do basic things like send a plot 
to an output device and return.  It's just not that kind of tool, so 
benchmarking it against PGPLOT for plotting speed would be like comparing a 
power drill to a hammer.  It would be equally unfair to ask about PGPLOT's or 
Gnuplot's performance as widget drivers.

That said, if I do this:

use PDL::Graphics::Prima;
use PDL::Graphics::Prima::Simple;
$x = random(1e6);
$y = random(1e6);
plot(-data=>ds::Pair($x,$y,plotTypes=>[ppair::Squares(lineWidths=>1)]));

it takes about 1.5 seconds before the axes and points render on my screen.  
Doing the same thing with 1e7 points gives a lag of about 11 seconds, which is 
reasonable if the dominant delay is O(n).  But dragging the plotted points 
around gives a faster delay - with 10^7 points, the graphical update loop lags 
by only 2-3 seconds, so much of that initial 11 seconds must be initializing 
data structures that are only exercised during scroll operations.


On Mar 4, 2013, at 10:21 PM, Joel Berger <[email protected]> wrote:

> I'd be curious to see Prima in that comparison. I know David put some thought 
> into the large data concepts.
> 
> Joel
> 
> On Mon, Mar 4, 2013 at 11:15 PM, Craig DeForest <[email protected]> 
> wrote:
> I hope this isn't beating a dead horse - but I got interested in performance, 
> so I ran both of your tests, Karl - point-plotting and image plotting - 
> against PGPLOT.  Results are plotted below.  Gnuplot is about 2x slower than 
> PGPLOT for plotting points.  It's about 6x slower for plotting images in the 
> large-image regime, and 30x or more slower at displaying them - but see the 
> caveat below.  
> 
> On my machine, neither PGPLOT nor Gnuplot meets the "Karl standard" for 
> speed.  
> 
> All of the elapsed times include time to construct the output repository 
> (either X11 window or postscript file).  
> 
> I used the postscript output in the imaging test, because stock PGPLOT 
> doesn't actually touch all the data -- it uses sampling, so displaying images 
> larger than the display window doesn't involve touching every pixel -- at 
> least by the actual display code.  Sampling is useful for some things, 
> ghastly for others.  The postscript output may be a "fairer" test, since it 
> requires both engines to touch every pixel.  But I left the X11 in because 
> for some applications the PGPLOT choice is the correct one (e.g. 
> quick-and-dirty movies).
> 
> It might be interesting to throw PLPlot and Prima into the mix too...
> 
> <performance.png>
> 
> 
> _______________________________________________
> Perldl mailing list
> [email protected]
> http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
> 
> 

_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl

Reply via email to