Services & Resources / Wolfram Forums / MathGroup Archive
-----

MathGroup Archive 2014

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

Search the Archive

Parallelization sometimes a plus, sometimes not

  • To: mathgroup at smc.vnet.net
  • Subject: [mg132508] Parallelization sometimes a plus, sometimes not
  • From: John Villarrubia <John.Villarrubia at nist.gov>
  • Date: Fri, 4 Apr 2014 03:55:58 -0400 (EDT)
  • Delivered-to: l-mathgroup@mail-archive0.wolfram.com
  • Delivered-to: l-mathgroup@wolfram.com
  • Delivered-to: mathgroup-outx@smc.vnet.net
  • Delivered-to: mathgroup-newsendx@smc.vnet.net
  • Reply-to: <John.Villarrubia at nist.gov>

I noticed recently that some of my calculations using ParallelMap are 
much slower than the same calculation with Map. The call is in the form

fits = ParallelMap[f[a,#,b,c]&,argumentList]

It takes a factor of 4 or 5 more time to run this using ParallelMap on 
my 8-core machine than using Map. I had seen this behavior in the old 
days, when I forgot to pass necessary definitions to the subkernels and 
the main kernel ended up doing all the work. That does not seem to be 
the issue here: ParallelMap in the Mathematica version I'm using (v. 8) 
is supposed to automatically pass the needed definitions and, indeed, it 
seems to have done so: In the TaskManager I can see all 8 subkernels 
busily maxed out for the whole time, while the main kernel runs at 1% or 
less (presumably gathering results).

You'll be wondering what's inside f. {a,b,c} are fixed arguments. The 
argumentList specifies a location in an image where a model function is 
fit to the data using a call to NonlinearModelFit. The model function 
has 4 floating parameters that are arguments of a 10-argument 
InterpolationFunction. (The other 6 parameters are held constant during 
any given fit.) The interpolation data set is huge and f itself is 
rather long, so it's not practical to list it here.

Naturally, since I can't easily list the code, I don't expect anyone to 
be able to pinpoint the problem. What I'm hoping is that someone else 
has experienced this and can say what the issue turned out to be--or 
that someone with experience doing parallel computing in Mathematica can 
say what sorts of things might be relevant to this. I'm struggling to 
think of those: For example, in browsing the list I see that shared 
variables are implicated in lots of people's problems. However, f is 
pretty self-contained. I have not set any shared variables or shared 
functions. There are some nonlocal variables that f reads, but does not 
alter.

What other sorts of things should I be investigating?

John





  • Prev by Date: Re: Efficient function to accumulate a list of {value,coord} into array
  • Next by Date: Re: Efficient function to accumulate a list of {value,coord} into array
  • Previous by thread: Re: Efficient function to accumulate a list of {value,coord} into array
  • Next by thread: Re: Efficient function to accumulate a list of