1
$\begingroup$

I have read a few threads about parallel execution and I have fixed the problem with dispatch tables, but still my code is very slow. I have isolated the problem and into the following

First some preparation:

LaunchKernels[]    
Remove[pTest1,pTest2,g];
g=Range[100000000];
pTest1[a_]:=Module[{g},1]
pTest2[a_]:=Module[{g$1234},1]

Then some benchmarking:

AbsoluteTiming[ParallelMap[pTest1,Range[16]];]
{7.27915,Null}
AbsoluteTiming[ParallelMap[pTest2,Range[16]];]
{0.00587179,Null}
 AbsoluteTiming[Map[pTest1,Range[16]];]
{0.0000463645,Null}

The execution is 1000 times slower just because a local variable in pTest1 has the same name as a global variable g. Of course non-parallel is even faster but that could be expected since the overhead is large compared to the simple function body.

If I do DistributeDefinitions[g] first, it does not happen, but that takes some time also and why would I have to do that?

Is this expected or a bug?

$\endgroup$
1
$\begingroup$

The parallel tools framework tries to be smart and do lots of things for you automatically. Especially with a language as complex and flexible as Mathematica, automatic decisions are going to fail at least some of the time.

In early versions of Mathematica (v7?), it was necessary to distribute variables manually before they could be used on subkernels. In later versions, most functions, such as ParallelMap, try to do this automatically for you. ParallelMap examines the definition of pTest1 and automatically distributes any symbols that appear in it. Then it looks at the definitions of those symbols as well, and so on ...

It is clear that this strategy won't always work. What if you have ToExpression["a"]? It won't detect that a has to be distributed. Similarly, in your case it does not detect that g is not actually used by pTest1. Note that the symbol g in pTest1 is exactly the same as the "global" g. There aren't true local symbols in Mathematica. Module just happens to rename g to something else before evaluation proceeds, thus the global value of g is never touched.

I would not call this a bug. It is a limitation when trying to automate certain decisions. Whether this level of automation is a good or bad thing is up for debate—personally I am against it, but Wolfram very clearly prefers it. Just think about how most Mathematica functions select a Method to use fully automatically, and how the manually settable values of Method are typically underdocumented.

| improve this answer | |
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.