Skip to main content
replaced http://mathematica.stackexchange.com/ with https://mathematica.stackexchange.com/
Source Link

Please see the answer I gave herehere.


Parallelization works well and reliable only if you use constructs with no side effects. This is an essential point when using Mathematica's parallel computing tools. If you are not sure what a side effect is, please read about it.

This explains why For won't be auto-parallelized.


The reason why the function b does not seem to change f is that f will be changed only on the parallel kernels, but the results won't be sent back to the main kernel. It is not even clear which f should be sent back. The one on kernel 1 or the one on kernel 2? (Obviously you want them merged in a special way, but there is no way for the computer to guess how.) I discuss this issue as well herehere.


You can use SetSharedVariable[f] to force all accessed to f to be synchronized through the main kernel. This will give you the desired result, but it will hurt performance because of the constant communication between the main kernel and subkernels. It is also a potential source of errors because two different subkernels might change the same value in f.

I recommend you never change any "global" variables from parallel calculations. This is always a potential source of mistakes and when done properly, it will reduce performance. Instead formulate your problem without using side effects. Your specific example would look like ParallelTable[k+1, {k, num}]. Think about if you can do this with your actual problem as well.

Please see the answer I gave here.


Parallelization works well and reliable only if you use constructs with no side effects. This is an essential point when using Mathematica's parallel computing tools. If you are not sure what a side effect is, please read about it.

This explains why For won't be auto-parallelized.


The reason why the function b does not seem to change f is that f will be changed only on the parallel kernels, but the results won't be sent back to the main kernel. It is not even clear which f should be sent back. The one on kernel 1 or the one on kernel 2? (Obviously you want them merged in a special way, but there is no way for the computer to guess how.) I discuss this issue as well here.


You can use SetSharedVariable[f] to force all accessed to f to be synchronized through the main kernel. This will give you the desired result, but it will hurt performance because of the constant communication between the main kernel and subkernels. It is also a potential source of errors because two different subkernels might change the same value in f.

I recommend you never change any "global" variables from parallel calculations. This is always a potential source of mistakes and when done properly, it will reduce performance. Instead formulate your problem without using side effects. Your specific example would look like ParallelTable[k+1, {k, num}]. Think about if you can do this with your actual problem as well.

Please see the answer I gave here.


Parallelization works well and reliable only if you use constructs with no side effects. This is an essential point when using Mathematica's parallel computing tools. If you are not sure what a side effect is, please read about it.

This explains why For won't be auto-parallelized.


The reason why the function b does not seem to change f is that f will be changed only on the parallel kernels, but the results won't be sent back to the main kernel. It is not even clear which f should be sent back. The one on kernel 1 or the one on kernel 2? (Obviously you want them merged in a special way, but there is no way for the computer to guess how.) I discuss this issue as well here.


You can use SetSharedVariable[f] to force all accessed to f to be synchronized through the main kernel. This will give you the desired result, but it will hurt performance because of the constant communication between the main kernel and subkernels. It is also a potential source of errors because two different subkernels might change the same value in f.

I recommend you never change any "global" variables from parallel calculations. This is always a potential source of mistakes and when done properly, it will reduce performance. Instead formulate your problem without using side effects. Your specific example would look like ParallelTable[k+1, {k, num}]. Think about if you can do this with your actual problem as well.

Source Link
Szabolcs
  • 238.9k
  • 32
  • 653
  • 1.3k

Please see the answer I gave here.


Parallelization works well and reliable only if you use constructs with no side effects. This is an essential point when using Mathematica's parallel computing tools. If you are not sure what a side effect is, please read about it.

This explains why For won't be auto-parallelized.


The reason why the function b does not seem to change f is that f will be changed only on the parallel kernels, but the results won't be sent back to the main kernel. It is not even clear which f should be sent back. The one on kernel 1 or the one on kernel 2? (Obviously you want them merged in a special way, but there is no way for the computer to guess how.) I discuss this issue as well here.


You can use SetSharedVariable[f] to force all accessed to f to be synchronized through the main kernel. This will give you the desired result, but it will hurt performance because of the constant communication between the main kernel and subkernels. It is also a potential source of errors because two different subkernels might change the same value in f.

I recommend you never change any "global" variables from parallel calculations. This is always a potential source of mistakes and when done properly, it will reduce performance. Instead formulate your problem without using side effects. Your specific example would look like ParallelTable[k+1, {k, num}]. Think about if you can do this with your actual problem as well.