Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
2001
*January
*February
*March
*April
*May
*June
*July
*August
*September
*October
*November
*December
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

MathGroup Archive 2001

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: ParallelMap inefficient?

  • To: mathgroup at smc.vnet.net
  • Subject: [mg27306] Re: ParallelMap inefficient?
  • From: Jens-Peer Kuska <kuska at informatik.uni-leipzig.de>
  • Date: Tue, 20 Feb 2001 03:05:15 -0500 (EST)
  • Organization: Universitaet Leipzig
  • References: <96irro$df8@smc.vnet.net> <XPIj6.5844$Rl5.43836@ralph.vnet.net> <96q2ha$mtj@smc.vnet.net>
  • Sender: owner-wri-mathgroup at wolfram.com

Hi,

> Hi Jens. The ParallelMap[ ] routine is for algorithms that are "embarassingly
> parallel", i.e., there is no coupling between the processes. 

Since the toolkit has only the master/worker model you must send
the data from the master to the workers and get the results back.

In the simple examples you gave, the overhead for exchanging data and
data
will dominate allmost everything

> Therefore, if you
> map N processors over a 50 element list, with a single master computer and N
> slaves, an upper bound on the time might be
> 
> time to process = 50 *  T_slowest_comm_master_slave  +  50/N *
> T_compute_slowest_computer  +/-  small_fudge_factor
> 
> When I hand code the ParallelMap[ ] functionality myself, I see this sort of
> performance. When I use the function supplied with the toolbox, I see
> something different. That was the point.

What kind of client tasks  ??

Regards
  Jens


  • Prev by Date: UnitStep[] Problem.
  • Next by Date: Re: two y-axis
  • Previous by thread: Re: ParallelMap inefficient?
  • Next by thread: Re: ParallelMap inefficient?