Have you encountered different results using "parfor" vs. "for" loop using Matlab 2019b

Hello,

I would like to ask if you have different output results using "parfor" vs. "for" loop especically using the random generator (rng command) with fix seed (both "parfor" and "for" have the same seed).

If so, why is that as I expect the same results for both methods.

Thank you,

Charles

[Edric Ellis]

Please can you post some simple code that reproduces the problem you're seeing. You might also find some insights in this doc page: https://uk.mathworks.com/help/parallel-computing/repeat-random-numbers-in-parfor-loops.html .

Answer 1

[Rik]

Put simply, each worker in the parallel pool inherits the workspace from before the loop.

So if you put your rng before the loop, you should expect different results. If you put the rng call inside the loop, you should expect the same results.

The reason is that each call to a random function influence the current seed. So if your loop contents use random generated data, that means that the iterations are not independent on their order. You should think of a parfor loop as doing this:

N=5;
SomeCode=@(n)disp(n);
v=1:N;
for n=v(randperm(end))
    SomeCode(n)
end

     4

     5

     3

     2

     1

If the results of this loop are stable, that means the iterations are independ, which is a requirement for a parfor loop.

With this example it easy why the results are not stable if you put rng outside the loop:

v=v(randperm(end));
old_seed = rng(0);
results=zeros(1,N);
for n=v
    results(n)=rand+n;
end
results

results = 1×5

1.9058 2.9134 3.8147 4.1270 5.6324

rng(old_seed)
v=v(randperm(end));
old_seed = rng(0);
results=zeros(1,N);
for n=v
    results(n)=rand+n;
end
results

results = 1×5

1.9058 2.1270 3.6324 4.8147 5.9134

Now with rng in the loop:

rng(old_seed)
results=zeros(1,N);
for n=v(randperm(end))
    rng(n)
    results(n)=rand+n;
end
results

results = 1×5

1.4170 2.4360 3.5508 4.9670 5.2220

results=zeros(1,N);
for n=v(randperm(end))
    rng(n)
    results(n)=rand+n;
end
results

results = 1×5

1.4170 2.4360 3.5508 4.9670 5.2220

[Charles Nguyen]

Hi Rik,

Can you please provide me an example(s) with the "parfor" as above examples only have "for"?

Thank you for your help!

Charles

[Edric Ellis]

While it's certainly true that each parallel worker in a parfor loop receives workspace values from the client, the workers do not share rng state in any way with the client. A call to rng on the client has no effect whatsoever on the parallel workers. So, your initial examples here don't completely demonstrate why discrepancies might arise. Setting rng inside the loop on each iteration guarantees consitency whether using for or parfor.

[Rik]

@Charles Nguyen

My point was that your code should assume such a randperm call. If it doesn't work if you do that, then your code will not have stable results. Did you try my examples with parfor n=1:N?

@Edric Ellis

Thank you for the correction/clarification. While my answer was technically incorrect, can you confirm my intuition that the random state not advancing continuously is likely the source of the issue of OP?

[Charles Nguyen]

@Rik,

Please see below

parfor n=1:N

rng(n)

results(n)=rand+n;

end

results

The results are below which is different than yours.

Starting parallel pool (parpool) using the 'local' profile ...

Connected to the parallel pool (number of workers: 4).

results =

1.1404 2.6097 3.8122 4.0277 5.3973