Unexpected differences between parfor and spmd

When I replace

parpool(n, 'AttachedFiles', ...)
parfor k = 1:n
   res(k) = func(A(k));
end

which works, by

parpool(n, 'AttachedFiles', ...)
spmd
   res = func(A(labindex));
end

my machine's physical memory fills up and then my machine freezes, before I get any output.

(There's about 20kB of code behind func, and I have no idea which bit is causing the problem, which is why I'm putting this query in very general terms).

My query is: what sort of thing can cause this?

(The reason why I want to make the change is that I want my progress indicating output to be labelled by worker.)

I'm using R2016b, and I've set AutoAttachedFiles to false (I set AttachedFiles appropriately with parpool).

Garry

[Edric Ellis]

Hm, those two pieces of code ought to behave the same, as you expected. What happens if you try

spmd(1)
  res = func(A(1));
end

Does that still show the problem? (This forces the spmd block to use only a single worker).

Answer 1

[Walter Roberson]

http://www.mathworks.com/help/distcomp/labindex.html

"id = labindex returns the index of the worker currently executing the function. labindex is assigned to each worker when a job begins execution, and applies only for the duration of that job. The value of labindex spans from 1 to n, where n is the number of workers running the current job, defined by numlabs."

labindex is not a counter of the iteration number: it is the worker number.

If you had used

parpool(n)

to try to get n workers so that each task would have its own worker, then that would fail if n exceeds the pool size (which typically defaults to the number of physical cores.)

Yes, if you know that there are exactly the same number of workers as you need iterations then it could work in place of a parfor.

[Garry Hollier]

Walter

I should have said that I ensure that n workers are running in both cases. I will edit the question.

But thanks for the response.

Garry