# Tag Info

0

If you want to use AppendTo, you could just make list a shared variable and change your ParallelTable to a ParallelDo: list = {}; SetSharedVariable[list]; ParallelDo[Block[{x = x2, y}, y = 2 x^2; AppendTo[list, {x, y}];];, {x2, 1, 4}]

3

It is important to understand that in Mathematica, semi-automatic parallelization, such as the one provided by ParallelTable or ParallelMap works only if the chunks of code executed in parallel have no side effects. What does it really mean to say that f has no side effect? Another way to say it is that the output of f depends only on it's input and ...

1

The documentation for ParallelMap and ParallelTable specifically state: ParallelMap will give the same results as Map, except for side effects during the computation. ParallelTable will give the same results as Table, except for side effects during the computation. If you actually experience out-of-order results you have encountered a bug. ...

4

I cannot reproduce this behavior. With the following code I tested whether two very long series of random numbers when processed serially or in parallel ever yield different results: c = 0; (* counter to count the number of times the two results differ *) Do[ m = RandomInteger[1000, 10^6]; If[Map[#^2 &, m] =!= ParallelMap[#^2 &, m], c++] , {1000} ...

6

Using Trace we can see that the evaluation of ParallelTable[a[1], {a[1], 0, 10}] becomes: ParallelCombinePrivateparallelIterateE[ ParallelTable, Table, Join, Identity, a[1], {a[1], 0, 10}, {Automatic, "Global"} ] Further using PrintDefinitions in the GeneralUtilities package lets us peek behind the curtain: Needs["GeneralUtilities`"] ...

6

The definition a = 0 is not being distributed among the subkernels, therefore in f2 the Sum is evaluated symbolically. After the results are returned to the master kernel a is substituted in. It happens that in this case a symbolic sum is much faster: ClearAll[a] Sum[N@Gamma[i + 1], {i, 10000}] // AbsoluteTiming Sum[N@Gamma[a + i + 1], {i, 10000}] /. a ...

2

This works for any table dimension. It also sends the \$Assumptions to all parallel kernels (otherwise a simplification inside the parallel table will not be done properly). MonitoredTimedParallelTable[expression_,indexesDescriptors__]:=Module[{tuplesLength,counter,printTemporaryCell,tableResult}, ...

9

As a more complete answer to my comment above, Mathematica doesn't necessarily assume a variable is a number upon introduction. Initialize the counter variable equal to zero and then the increment will be handled correctly for the shared variable. monitoredParallelTable[expr_, {x_,xmin_,xmax_,xstep_}]:=Module[{counter = 0,tmp}, SetSharedVariable[counter]; ...

4

Recasting my comment as an answer, as suggested by Leonid. ParallelEvaluate hasn't changed, the reason is that LaunchKernels[1] used to return a kernel object, while now it returns a single element list. I think this is more consistent, and the old behavior was never explicitly documented.

2

As you have written it, it is not easily parallelizable. There is just a single task that consists of a Nest. Each iteration in the Nest needs the result of the previous step and that should be available at the start of the next iteration. I don't see how you could parallelize that without a lot of slow inter-process communication. The best way to ...

1

I don't have a complete explanation, but some observations that may be helpful. First, this behavior doesn't specifically have to do with Association, since you see a similar slow-down when parallelizing using a plain old list of rules: rules = {2 -> 7, 3 -> 8, 4 -> 9, 5 -> 10, 6 -> 11, _ -> 0}; calcF[x_, y_, Max_] := Sum[x + y /. rules, ...

5

This seems to just be a limitation of ParallelTable, can't comment whether that has a deeper reason due to parallelism or is just a simple oversight. I think it was not possible to use expressions like a[i] as e.g. iterators in older versions but in newer version that has been added as a feature to many functions, but obviously not ParallelTable (as of ...

Top 50 recent answers are included