Ooh, fun times. I'll have to write up a number of benchmarks for doing this with Prima.
Of course, the numbers I end up with depend on precisely what I benchmark. Benchmarking the point plotting performance will depend on 1. Is it autoscaling or is the scaling fixed? If we have an idea for the data's bounds ahead of time, we can speed things up substantially by fixing the bounds first. 2. Is it drawn to the screen or is it a hard copy? If it's the former, Prima should be *very* fast for point plotting because I've optimized it for this. (In fact, the library is so centered on widget-based rendering that there's no simple function for just making a plot without first building the widget. I've managed to do this in my own code when I just want hard copies, but it requires jumping through a few hoops and I haven't written a publicly available function or interface for this as of yet. I plan to decouple these some day, but it's not a terribly high priority.) 3. It looks like you're using the basic point plotting routine. Does the performance of the other libraries depend in any great degree on the plot type? Line plotting in Prima is a bit slower because of bad value handling and infinity handling. For benchmarking, I'd rather stick with point plotting. :-) I have not spent any time trying to optimize the image plotting, focusing exclusively on getting it to do the correct thing for different axis scaling or non-uniform "bin" widths. I'm sure there are some common cases that could be highly optimized compared to what it does right now. So, yeah, Prima is gonna suck on that. But that's OK, benchmarks are supposed to help point out where real work needs to happen. I'll cook up a bunch of scripts soon, maybe later this afternoon. David On Tue, Mar 5, 2013 at 11:43 AM, Craig DeForest <[email protected]>wrote: > Funny you should mention that -- there's a Mac Port of PLplot now, and it > installed flawlessly when I tried it last night -- which is a huge change > from my earlier experience. It is indeed a very nice plotting package - > the high level plots, in particular, are very nice looking. > > Derek has had difficulty using it for image plotting, largely because it > uses a very expensive algorithm that is best adapted to low resolution data > (and does a fabulous job in that case) but does not scale well to high > resolution images. The difficulty is best summed up in the performance > plot (apropos to the performance discussion last night). I don't know if > there's a better way than the existing high-level contour plot method. As > far as point-plotting speed, it's about the same as gnuplot. The plot > times are on a 2011 MacBook Pro with stock Ports install. > > > > > On Mar 5, 2013, at 10:03 AM, Doug Hunt <[email protected]> wrote: > > Hi Karl: I still maintain that PLplot is a good, modern plotting package > that runs on all required platforms. It is well maintained and has a nice > build system. It also has interactive capabilities which I don't know much > about. > > I have not supported Windows and Mac with PDL::Graphics::PLplot because I > don't have the time and access to required machines. > > I think others who have time/machines could do this without much effort. > > I think PLplot could be brought up to speed with minor enhancements to > PDL::Graphics::PLplot, which I don't necessarily have time to do. > > Regards, > > Doug > > [email protected] > Software Engineer > UCAR - COSMIC, Tel. (303) 497-2611 > > On Tue, 5 Mar 2013, Karl Glazebrook wrote: > > If GNUplot can plot a million points or a 4096^2 image with a delay < 1s > and no memory disaster then that would be fast enough for me. > > I wish there was a better solution > > Karl > > > > On 04/03/2013, at 2:04 AM, Henning Glawe wrote: > > On Sun, Mar 03, 2013 at 10:04:45PM +1100, Karl Glazebrook wrote: > > I don't know how 'modern' PLplot is. The documentation still talks about > Tektronix terminals! > > I did some googling, DISLIN seemed the closest but is only semi-frree. > > In astronomy people really only use pgplot at the c/f77 level. (At a > higher level they use language specific graphics, e.g. IDL, IRAF, Python, > sm (!), gnuplot, MMA). > > What about other scientific fields? What do people you know use? > > > In my field (computational quantum physics/chemistry), computation and > visualization are usually treated separately. Typically, the actual > numerical simulations are very heavy (taking CPU-days or even CPU-weeks on > current HPC-Clusters). > The visualization is performed in a separate step, where different > "classes" > of tools are employed: > * Special purpuse tools for molecule/crystal visualization, which show: > - crystal structures > - densities either on cutting planes or as equipotential surfaces > Tools belonging to this class are: > - xcrysden http://www.xcrysden.org/ > - v-sim http://www-drfmc.cea.fr/L_Sim/V_Sim/index.en.html > * General-purpose plotting tools with a focus on 2D-visualization: > - gnuplot http://gnuplot.sourceforge.net/ > - grace http://plasma-gate.weizmann.ac.il/Grace/ > * General-purpose plotting tools with more focus on 3D-visualization: > - OpenDX http://en.wikipedia.org/wiki/IBM_OpenDX > (Official website seems to be down) > Learning curve is quite steep, interface is a bit awkward to use (for > modern standards) > - paraview http://www.paraview.org/ > Easier to use than OpenDX; very powerful visualization tool, integrated > python scripting support for > - sources (data generation) > - filters (data processing) > - general-purpose macros > > Looks dismal. Perhaps the moral is people who put significant effort in to > visuals tend to go commercial? > > > I don't think so. You can get quite good results out of free > visualization tools, altough sometimes you may have to tweak the settings a > bit. One very good example for this is gnuplot; the default settings have > not > changed much in the past 20 years (think backwards compatibility), but with > some modifications in your gnuplot scripts, plots may look a lot more > attractive. This is one of the websites showing how to do this: > http://www.gnuplotting.org > > For paraview, there are some good examples in the image gallery: > http://www.paraview.org/paraview/project/imagegallery.php > > > Maybe we have to go back to the question what _kind_ of visualization > support > we need to have available directly within PDL. > > In my opinion, a very simple plotting interface used mainly for > debugging/development is enough. > For anything beyond this, there are really good plotting tools available > also > as free software, we just need to be able to export data in a format > readable > by them. > > -- > c u > henning > > > > > _______________________________________________ > 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 > > -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." -- Brian Kernighan
<<performance.png>>
_______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
