On 2009-10-06 15:27+0200 Paul Boley wrote:
> Dear all,
>
> I've just subscribed to this list and am rather new to PLplot, so
> please excuse me if I'm asking something which I should know from the
> documentation or mailing list archives! I've taken a look, but haven't
> found anything dealing with this issue.
>
> I'm using plshades to draw 2d data. In my case, it's a FITS
> image with dimensions 1044x1046 (about 2 megabytes). When drawing to
> the xwin device (or when reading a pdf created using the pdf device), I
> find that the image is rendered very slowly. It takes about a minute
> to draw the entire image. Using the PDL bindings (I've also tried this
> in C, with no substantial difference), I have (for example), the
> following:
>
> $fits = rfits("foo.fits");
> $shades = min($fits) + sequence(50)/50 * (max($fits) - min($fits));
> plinit();
> plenv(0, $fits->getdim(0), 0, $fits->getdim(1), 0, 0);
> plshades($fits, 0, $fits->getdim(0), 0, $fits->getdim(1), $shades, 1,
> 1, 0, 0, 0, \&pltr0, 0);
>
> It seems very straightforward, but the result is drawn very slowly.
> It draws several layers from left to right (presumably corresponding
> to the shades), and each successive later draws faster and faster
> (presumably as fewer elements correspond to higher color levels). Am I
> doing something wrong? Is there any way to speed up the rendering?
Hi Paul:
I am glad you also tried plshades in C because that tests the speed of our
fundamental library rather than a particular set of language bindings to it.
I investigated further, and I think you may be up against a fundamental
limitation (no plot shading algorithm could do substantially better).
Here is why I have come to that tentative conclusion.
Our standard example 16 exercises a combination of plshades and plcont, but
it is easy to bypass all but the last page (which just exercises plshades)
with the appropriate goto. That example (modified or otherwise) allows user
control of the size of the array (nx and ny) that is plotted and the number
of shades (ns). Here are the timing results for the last page of example 16
for various sizes of ns for rather large nx and ny values:
softw...@raven> time ./x16c -nx 2048 -ny 1536 -ns 25 -dev xwin
real 0m23.602s
user 0m15.193s
sys 0m2.172s
softw...@raven> time ./x16c -nx 2048 -ny 1536 -ns 50 -dev xwin
real 0m29.468s
user 0m19.557s
sys 0m2.680s
softw...@raven> time ./x16c -nx 2048 -ny 1536 -ns 100 -dev xwin
real 0m42.407s
user 0m28.250s
sys 0m3.568s
(These are reliable timing results because I hit the enter key immediately
in the xwin window to allow the plot to exit without delay when it was done.
Also, -dev qtwidget results were essentially identical so these timings are
controlled by the core library of PLplot rather than device driver which is
not an unexpected result.)
The above timing results are reasonably approximated by
t ~ (16 + 0.26 ns) seconds
where t is the elapsed (real) time.
This approximation result makes sense. There is some some substantial
overhead to calculate xg, yg, and z values for a total of nx*my pixels, then
plshades is called which in turn calls plshade ns times.
Here is a timing series for fixed ns = 100, for three different nx, ny values
arranged so there is a factor of 4 change in number of pixels between each
test. (The middle of the pair repeats the numbers from the last test above.)
softw...@raven> time ./x16c -nx 1024 -ny 768 -ns 100 -dev xwin
real 0m13.705s
user 0m9.101s
sys 0m1.188s
softw...@raven> time ./x16c -nx 2048 -ny 1536 -ns 100 -dev xwin
real 0m42.407s
user 0m28.250s
sys 0m3.568s
softw...@raven> time ./x16c -nx 4096 -ny 3072 -ns 100 -dev xwin
real 2m33.068s
user 1m37.366s
sys 0m18.349s
These results are approximated pretty well by
t ~ (4.5 + 11.7 npixels/10^6) seconds
where npixels = nx*ny = number of pixels. This result is indicative of a
relatively small amount of overhead + something that scales linearly with
the number of pixels. That result seems entirely reasonable since the
function preparation is done for npixels values, and a large fraction of the
work of plshade (called by plshades) must be proportional to the npixels
value as well.
I am not aware of any theorems which predict how shade plot computer time
should scale with number of shades and number of pixels in the ideal case,
but I also see nothing alarming in the above "constant + linear power"
results so we may in fact be close to the best you can do for a shade plot.
Of course, the above tests say nothing about the overall proportionality
factor in these timing tests, but plshade (which plshades calls for each
desired shade) was developed a long time ago when computers were slow and
developers paid a lot of attention to efficiency. So it may be worthwhile
to review plshade for efficiency (e.g., to make sure it does not generate an
excessive number of cache misses), but it is also possible we won't find
anything to improve.
Of course, such a review becomes much more urgent if you present evidence
that other plot libraries produce shade plots much faster than PLplot. :-)
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________
Linux-powered Science
__________________________
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Plplot-general mailing list
Plplot-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-general
