Re: ParallelMap inefficient?
- To: mathgroup at smc.vnet.net
- Subject: [mg27336] Re: ParallelMap inefficient?
- From: Mike Yukish <may106 at psu.edu>
- Date: Wed, 21 Feb 2001 03:17:14 -0500 (EST)
- Organization: Penn State University, Center for Academic Computing
- References: <96irro$df8@smc.vnet.net> <XPIj6.5844$Rl5.43836@ralph.vnet.net> <96q2ha$mtj@smc.vnet.net> <96t8op$pq8@smc.vnet.net>
- Sender: owner-wri-mathgroup at wolfram.com
Hello again,
Jens-Peer Kuska wrote:
> In the simple examples you gave, the overhead for exchanging data and
> data
> will dominate allmost everything
I've traded email with the Mathematica support folks since, and here is the nugget of my
point.
Make a list of 100 elements.
list = {0, ...., 100};
Start one remote processor. Compare these calls...
ParallelMap[Sin, list];
Map[RemoteEvaluate[Sin[#]] &, list];
Both calls do the same thing, and theoretically have the exact same amount of
communication and computation. Yet you see a six-fold difference in the time spent
other than calculating, between these two. The first call takes 200 seconds. The
second call takes 30 seconds. With two processors, it is still better to Map[ ] it
across a single remote than it is to ParallelMap[ ] it across two remote. And so on
up to six or so remote processors. These processors are on PCs communicating across
a 10 MB ethernet hub. An even faster call is:
RemoteEvaluate[Map[Sin,list]]]
Which is almost instantaneous. This points out that it is much better to split a
list up into N segments for N processors and farm them out, than it is to let
ParallelMap[ ] handle the comms for you. The advantages for using ParallelMap[ ]
are that it handles the admin details, and it will handle cases where the task time
for each element differs.