4 replaced http://mathematica.stackexchange.com/ with https://mathematica.stackexchange.com/
source | link

Do SetSharedVariable/SetSharedFunction ruin the benefits of ParallelTable?

Yes, they do. This has been discussed here many times, for example at:

Mathematica uses separate processes for parallelization. This means that the parallel threads cannot share any memory. What SetSharedVariable really does is that it causes that variable to always be evaluated an set on the main kernel. This involves a callback from the subkernel to the main kernel. Main kernel – subkernel communication is already a major bottleneck in the parallel tools. Forcing it for every single evaluation will typically kill all speed benefits. (Note that otherwise communication may happen only as few times as the number of subkernels. This is the case with Method -> "CoarsestGrained".)

The only exception is when the evaluation on the subkernel takes significantly longer than the callback to the main kernel. For example, take

list={};
SetSharedVariable[list];
ParallelDo[AppendTo[list, f[i]], {i, 100}]

This is effective only if f[i] takes long to evaluate (say, 1 second or more), and it does not return a lot of data (say, it returns a number instead of an array). The subkernel evaluations should take significantly longer than the communication between kernels.


Because of this, the key to effective parallelization in Mathematica is to fully separate the tasks of subkernels and avoid any communication between them. If they need to access the same variable, things get much more difficult.

Functional programming is much more amenable to parallelization because it avoids mutable data structures and side effects. To put it in simple terms, a problem is well parallelizable if you can phrase it in terms of Map (ParallelMap) or ParallelCombine.

Do SetSharedVariable/SetSharedFunction ruin the benefits of ParallelTable?

Yes, they do. This has been discussed here many times, for example at:

Mathematica uses separate processes for parallelization. This means that the parallel threads cannot share any memory. What SetSharedVariable really does is that it causes that variable to always be evaluated an set on the main kernel. This involves a callback from the subkernel to the main kernel. Main kernel – subkernel communication is already a major bottleneck in the parallel tools. Forcing it for every single evaluation will typically kill all speed benefits. (Note that otherwise communication may happen only as few times as the number of subkernels. This is the case with Method -> "CoarsestGrained".)

The only exception is when the evaluation on the subkernel takes significantly longer than the callback to the main kernel. For example, take

list={};
SetSharedVariable[list];
ParallelDo[AppendTo[list, f[i]], {i, 100}]

This is effective only if f[i] takes long to evaluate (say, 1 second or more), and it does not return a lot of data (say, it returns a number instead of an array). The subkernel evaluations should take significantly longer than the communication between kernels.


Because of this, the key to effective parallelization in Mathematica is to fully separate the tasks of subkernels and avoid any communication between them. If they need to access the same variable, things get much more difficult.

Functional programming is much more amenable to parallelization because it avoids mutable data structures and side effects. To put it in simple terms, a problem is well parallelizable if you can phrase it in terms of Map (ParallelMap) or ParallelCombine.

Do SetSharedVariable/SetSharedFunction ruin the benefits of ParallelTable?

Yes, they do. This has been discussed here many times, for example at:

Mathematica uses separate processes for parallelization. This means that the parallel threads cannot share any memory. What SetSharedVariable really does is that it causes that variable to always be evaluated an set on the main kernel. This involves a callback from the subkernel to the main kernel. Main kernel – subkernel communication is already a major bottleneck in the parallel tools. Forcing it for every single evaluation will typically kill all speed benefits. (Note that otherwise communication may happen only as few times as the number of subkernels. This is the case with Method -> "CoarsestGrained".)

The only exception is when the evaluation on the subkernel takes significantly longer than the callback to the main kernel. For example, take

list={};
SetSharedVariable[list];
ParallelDo[AppendTo[list, f[i]], {i, 100}]

This is effective only if f[i] takes long to evaluate (say, 1 second or more), and it does not return a lot of data (say, it returns a number instead of an array). The subkernel evaluations should take significantly longer than the communication between kernels.


Because of this, the key to effective parallelization in Mathematica is to fully separate the tasks of subkernels and avoid any communication between them. If they need to access the same variable, things get much more difficult.

Functional programming is much more amenable to parallelization because it avoids mutable data structures and side effects. To put it in simple terms, a problem is well parallelizable if you can phrase it in terms of Map (ParallelMap) or ParallelCombine.

3 deleted 1 character in body
source | link

Do SetSharedVariable/SetSharedFunction ruin the benefits of ParallelTable?

Yes, they do. This has been discussed here many times, for example at:

Mathematica uses separate processes for parallelization. This means that the parallel threads cannot share any memory. What SetSharedVariable really does is that it causes that variablesvariable to always be evaluated an set on the main kernel. This involves a callback from the subkernel to the main kernel. Main kernel – subkernel communication is already a major bottleneck in the parallel tools. Forcing it for every single evaluation will typically kill all speed benefits. (Note that otherwise communication may happen only as few times as the number of subkernels. This is the case with Method -> "CoarsestGrained".)

The only exception is when the evaluation on the subkernel takes significantly longer than the callback to the main kernel. For example, take

list={};
SetSharedVariable[list];
ParallelDo[AppendTo[list, f[i]], {i, 100}]

This is effective only if f[i] takes very long to evaluate (say, 1 second or more), and it does not return a lot of data (say, it returns a number instead of an array). The subkernel evaluations should take significantly longer than the communication between kernels.


Because of this, the key to effective parallelization in Mathematica is to fully separate the tasks of subkernels and avoid any communication between them. If they need to access the same variable, things get much more difficult.

Functional programming is much more amenable to parallelization because it avoids mutable data structures and side effects. To put it in simple terms, a problem is well parallelizable if you can phrase it in terms of Map (ParallelMap) or ParallelCombine.

Yes, they do. This has been discussed here many times, for example at:

Mathematica uses separate processes for parallelization. This means that the parallel threads cannot share any memory. What SetSharedVariable really does is that it causes that variables to always be evaluated an set on the main kernel. This involves a callback from the subkernel to the main kernel. Main kernel – subkernel communication is already a major bottleneck in the parallel tools. Forcing it for every single evaluation will typically kill all speed benefits.

The only exception is when the evaluation on the subkernel takes significantly longer than the callback to the main kernel. For example, take

list={};
SetSharedVariable[list];
ParallelDo[AppendTo[list, f[i]], {i, 100}]

This is effective only if f[i] takes very long to evaluate (say, 1 second or more), and it does not return a lot of data (say, it returns a number instead of an array).


Because of this, the key to effective parallelization in Mathematica is to fully separate the tasks of subkernels and avoid any communication between them. If they need to access the same variable, things get much more difficult.

Functional programming is much more amenable to parallelization because it avoids mutable data structures and side effects. To put it in simple terms, a problem is well parallelizable if you can phrase it in terms of Map (ParallelMap) or ParallelCombine.

Do SetSharedVariable/SetSharedFunction ruin the benefits of ParallelTable?

Yes, they do. This has been discussed here many times, for example at:

Mathematica uses separate processes for parallelization. This means that the parallel threads cannot share any memory. What SetSharedVariable really does is that it causes that variable to always be evaluated an set on the main kernel. This involves a callback from the subkernel to the main kernel. Main kernel – subkernel communication is already a major bottleneck in the parallel tools. Forcing it for every single evaluation will typically kill all speed benefits. (Note that otherwise communication may happen only as few times as the number of subkernels. This is the case with Method -> "CoarsestGrained".)

The only exception is when the evaluation on the subkernel takes significantly longer than the callback to the main kernel. For example, take

list={};
SetSharedVariable[list];
ParallelDo[AppendTo[list, f[i]], {i, 100}]

This is effective only if f[i] takes long to evaluate (say, 1 second or more), and it does not return a lot of data (say, it returns a number instead of an array). The subkernel evaluations should take significantly longer than the communication between kernels.


Because of this, the key to effective parallelization in Mathematica is to fully separate the tasks of subkernels and avoid any communication between them. If they need to access the same variable, things get much more difficult.

Functional programming is much more amenable to parallelization because it avoids mutable data structures and side effects. To put it in simple terms, a problem is well parallelizable if you can phrase it in terms of Map (ParallelMap) or ParallelCombine.

2 added 1 character in body
source | link

Yes, they do. This has been discussed here many times, for example at:

Mathematica uses separate processes for parallelization. This means that the parallel threads cannot share any memory. What SetSharedVariable really does is that it causes that variables to always be evaluated an set on the main kernel. This involves a callback from the subkernel to the main kernel. Main kernel – subkernel communication is already a major bottleneck in the parallel tools. Forcing it for every single evaluation will typically kill all speed benefits.

The only exception is when the evaluation on the subkernel takes significantly longer than the callback to the main kernel. For example, take

list={};
SetSharedVariable[list];
ParallelDo[AppendTo[list, f[i]], {i, 100}]

This is effective only if f[i] takes very long to evaluate (say, 1 second or more), and it does not return a lot of data (say, it returnreturns a number instead of an array).


Because of this, the key to effective parallelization in Mathematica is to fully separate the tasks of subkernels and avoid any communication between them. If they need to access the same variable, things get much more difficult.

Functional programming is much more amenable to parallelization because it avoids mutable data structures and side effects. To put it in simple terms, a problem is well parallelizable if you can phrase it in terms of Map (ParallelMap) or ParallelCombine.

Yes, they do. This has been discussed here many times, for example at:

Mathematica uses separate processes for parallelization. This means that the parallel threads cannot share any memory. What SetSharedVariable really does is that it causes that variables to always be evaluated an set on the main kernel. This involves a callback from the subkernel to the main kernel. Main kernel – subkernel communication is already a major bottleneck in the parallel tools. Forcing it for every single evaluation will typically kill all speed benefits.

The only exception is when the evaluation on the subkernel takes significantly longer than the callback to the main kernel. For example, take

list={};
SetSharedVariable[list];
ParallelDo[AppendTo[list, f[i]], {i, 100}]

This is effective only if f[i] takes very long to evaluate (say, 1 second or more), and it does not return a lot of data (say, it return a number instead of an array).


Because of this, the key to effective parallelization in Mathematica is to fully separate the tasks of subkernels and avoid any communication between them. If they need to access the same variable, things get much more difficult.

Yes, they do. This has been discussed here many times, for example at:

Mathematica uses separate processes for parallelization. This means that the parallel threads cannot share any memory. What SetSharedVariable really does is that it causes that variables to always be evaluated an set on the main kernel. This involves a callback from the subkernel to the main kernel. Main kernel – subkernel communication is already a major bottleneck in the parallel tools. Forcing it for every single evaluation will typically kill all speed benefits.

The only exception is when the evaluation on the subkernel takes significantly longer than the callback to the main kernel. For example, take

list={};
SetSharedVariable[list];
ParallelDo[AppendTo[list, f[i]], {i, 100}]

This is effective only if f[i] takes very long to evaluate (say, 1 second or more), and it does not return a lot of data (say, it returns a number instead of an array).


Because of this, the key to effective parallelization in Mathematica is to fully separate the tasks of subkernels and avoid any communication between them. If they need to access the same variable, things get much more difficult.

Functional programming is much more amenable to parallelization because it avoids mutable data structures and side effects. To put it in simple terms, a problem is well parallelizable if you can phrase it in terms of Map (ParallelMap) or ParallelCombine.

1
source | link