## Documentation Center |

On this page… |
---|

Differences Between for-Loops and parfor-Loops |

The basic concept of a `parfor`-loop
in MATLAB^{®} software is the same as the standard MATLAB `for`-loop: MATLAB executes a series
of statements (the loop body) over a range of values. Part of the `parfor` body
is executed on the MATLAB client (where the `parfor` is
issued) and part is executed in parallel on MATLAB workers working
together as a *parallel pool*. The necessary data
on which `parfor` operates is sent from the client
to workers, where most of the computation happens, and the results
are sent back to the client and pieced together.

Because several MATLAB workers can be computing concurrently
on the same loop, a `parfor`-loop can provide significantly
better performance than its analogous `for`-loop.

Each execution of the body of a `parfor`-loop
is an *iteration*. MATLAB workers evaluate
iterations in no particular order, and independently of each other.
Because each iteration is independent, there is no guarantee that
the iterations are synchronized in any way, nor is there any need
for this. If the number of workers is equal to the number of loop
iterations, each worker performs one iteration of the loop. If there
are more iterations than workers, some workers perform more than one
loop iteration; in this case, a worker might receive multiple iterations
at once to reduce communication time.

A `parfor`-loop is useful
in situations where you need many loop iterations of a simple calculation,
such as a Monte Carlo simulation. `parfor` divides
the loop iterations into groups so that each worker executes some
portion of the total number of iterations. `parfor`-loops
are also useful when you have loop iterations that take a long time
to execute, because the workers can execute iterations simultaneously.

You
cannot use a `parfor`-loop when an iteration in your
loop depends on the results of other iterations. Each iteration must
be independent of all others. Since there is a communications cost
involved in a `parfor`-loop, there might be no advantage
to using one when you have only a small number of simple calculations.
The examples of this section are only to illustrate the behavior of `parfor`-loops,
not necessarily to show the applications best suited to them.

The safest assumption about a `parfor`-loop
is that each iteration of the loop is evaluated by a different MATLAB worker.
If you have a `for`-loop in which all iterations
are completely independent of each other, this loop is a good candidate
for a `parfor`-loop. Basically, if one iteration
depends on the results of another iteration, these iterations are
not independent and cannot be evaluated in parallel, so the loop does
not lend itself easily to conversion to a `parfor`-loop.

The
following examples produce equivalent results, with a `for`-loop
on the left, and a `parfor`-loop on the right. Try
typing each in your MATLAB Command Window:

clear A for i = 1:8 A(i) = i; end A | clear A parfor i = 1:8 A(i) = i; end A |

Notice that each element
of `A` is equal to its index. The `parfor`-loop
works because each element depends only upon its iteration of the
loop, and upon no other iterations. `for`-loops that
merely repeat such independent tasks are ideally suited candidates
for `parfor`-loops.

Because `parfor`-loops
are not quite the same as `for`-loops, there are
special behaviors to be aware of. As seen from the preceding example,
when you assign to an array variable (such as `A` in
that example) inside the loop by indexing with the loop variable,
the elements of that array are available to you after the loop, much
the same as with a `for`-loop.

However,
suppose you use a nonindexed variable inside the loop, or a variable
whose indexing does not depend on the loop variable `i`.
Try these examples and notice the values of `d` and `i` afterward:

clear A d = 0; i = 0; for i = 1:4 d = i*2; A(i) = d; end A d i | clear A d = 0; i = 0; parfor i = 1:4 d = i*2; A(i) = d; end A d i |

Although the elements
of `A` come out the same in both of these examples,
the value of `d` does not. In the `for`-loop
above on the left, the iterations execute in sequence, so afterward `d` has
the value it held in the last iteration of the loop. In the `parfor`-loop
on the right, the iterations execute in parallel, not in sequence,
so it would be impossible to assign `d` a definitive
value at the end of the loop. This also applies to the loop variable, `i`.
Therefore, `parfor`-loop behavior is defined so that
it does not affect the values `d` and `i` outside
the loop at all, and their values remain the same before and after
the loop. So, a `parfor`-loop requires that each
iteration be independent of the other iterations, and that all code
that follows the `parfor`-loop not depend on the
loop iteration sequence.

The next two examples show `parfor`-loops
using reduction assignments. A reduction is an accumulation across
iterations of a loop. The example on the left uses `x` to
accumulate a sum across 10 iterations of the loop. The example on
the right generates a concatenated array, `1:10`.
In both of these examples, the execution order of the iterations on
the workers does not matter: while the workers calculate individual
results, the client properly accumulates or assembles the final loop
result.

x = 0; parfor i = 1:10 x = x + i; end x | x2 = []; n = 10; parfor i = 1:n x2 = [x2, i]; end x2 |

If the loop iterations operate in random sequence, you might expect the concatenation sequence in the example on the right to be nonconsecutive. However, MATLAB recognizes the concatenation operation and yields deterministic results.

The
next example, which attempts to compute Fibonacci numbers, is not
a valid `parfor`-loop because the value of an element
of `f` in one iteration depends on the values of
other elements of `f` calculated in other iterations.

f = zeros(1,50); f(1) = 1; f(2) = 2; parfor n = 3:50 f(n) = f(n-1) + f(n-2); end

When you are finished with your loop examples, clear your workspace and delete your parallel pool of workers:

clear delete(gcp)

The following sections provide further
information regarding programming considerations and limitations for `parfor`-loops.

When running a `parfor`-loop on a parallel
pool, all command-line output from the workers displays in the client
Command Window, except output from variable assignments. Because the
workers are MATLAB sessions without displays, any graphical output
(for example, figure windows) from the pool does not display at all.

Was this topic helpful?