Re: much power to mathematica
- To: mathgroup at smc.vnet.net
- Subject: [mg125391] Re: much power to mathematica
- From: "djmpark" <djmpark at comcast.net>
- Date: Sun, 11 Mar 2012 04:08:51 -0500 (EST)
- Delivered-to: l-mathgroup@mail-archive0.wolfram.com
- References: <jj4qn7$ifa$1@smc.vnet.net> <15040062.90100.1331201203073.JavaMail.root@m06> <jjcob0$q6e$1@smc.vnet.net> <731051.142975.1331379110527.JavaMail.root@m06>
David,
Well, I hope I can keep my thinking straight on this and the speedup in
dividing graphics into pieces depends on the internals of the WRI plotting
routines and maybe interactions between PlotPoints and MaxRecursion.
I did some experimentation and basically it looks like one doesn't obtain
much improvement simply by breaking a plot into sequentially calculated
pieces and using fewer plot points, so that the total plot points
corresponds to those used in the initial plot. But one does get a
significant improvement with serial processing if the pieces are simpler
than the overall plot and thus less recursion is used on each piece. (So
fractal structures probably wouldn't give a speed improvement simply by
breaking into pieces.) And, of course, parallel processing gives an
additional boost. Many graphics also have symmetry and this gives an
additional boost by using translation, reflection or rotation to fill in the
symmetrical parts.
Here is an example of plotting a complex function
Re[Cos[z^4 - z^3 + 10 z^2 -
1/(z^4 - 10000 z^3 - 3025 z^2 - z + 2)]] >= 0
over PlotRange -> 2 with 35 by 35 PlotPoints . I used MaxRecursion 1, 2,
4,and 6. The time for the plots was {0.67, 2.5, 28.6, 259} seconds. (The low
MaxRecursions did not give very good resolution.) When I divided this into 4
horizontal slices with 35 by 8 PlotPoints, and processed sequentially, I
obtained speedup factors of 1.35, 1.70, 2.88 and 3.67. So it appears that
fewer recursions with simpler plot pieces is the major speedup factor.
The example function has symmetry about the real axis. When I used that,
with MaxRecursion -> 4, and 35 by 5 plot points (we only have to parallel
process the upper half) I obtained a timing of 1.24 seconds, which is 23
times faster than the initial plot. Half of this was due to the use of
symmetry but still a factor of 11 is much better than the factor of 4 one
might naively expect from four cores.
Again, the use of symmetry gives an additional boost because of simpler
pieces and less recursion. The actual amount of parallel processing speedup
depends on the details of the graphic. If the graphic can be broken into
pieces of roughly uniform complexity one obtains the best load balancing and
speedup.
I haven't found too much of a problem in pasting the pieces together. The
major problem is in drawing boundaries of regions. This produces lines on
the edge of the pieces so I leave them out. Sometimes fitting density type
plots together can produce thin gaps between the pieces. I found this could
be minimized by using some overlap.
I have routines for aiding in the parallel processing of graphics in the
development Presentations, but haven't released it yet.
So, if one pays a pretty penny for Premier Service, why won't Wolfram let
one use all cores on a standard 6-core processor?
David Park
djmpark at comcast.net
http://home.comcast.net/~djmpark/index.html
From: David Bailey [mailto:dave at removedbailey.co.uk]
On 09/03/2012 11:08, djmpark wrote:
> David,
>
> There is a case where parallel processing will give a gain much
> greater than the number of cores used! This is when breaking a
> complicated graphic, say a contour or density plot, into multiple pieces.
>
> If you have to use 200 x 200 PlotPoints for a regular plot, then you
> can break it into four 100 x 100 plots for the same resolution. You
> obtain the approximate factor of 4 but also much faster execution
> because you are using only 1/4 the PlotPoints for each plot. There
> might also be some improvement with MaxRecursion, because each plot is
simpler.
>
> I've found that the easiest way to understand and use parallel
> processing is to learn about and use ParallelSubmit and WaitAll.
>
>
David,
Wouldn't that imply that the plotting process could be speeded up anyway be
splitting it up into smaller pieces?
Also, I imagine that the contour plot must deteriorate if constructed in
this way - contours not joining across the borders, etc. I mean the parallel
computation isn't computing the same result as the original sequential one.
David Bailey
http://www.dbaileyconsultancy.co.uk