Parfor variable slicing and assignment

Hello,

I am wondering why the following behavior is not allowed in Matlab. This is some code that just fills a random matrix in parallel and calls size().

% test loop
m=5; n=10;
A = zeros(m,n);
parfor i=1:m,
  A(i,:) = rand(1,n);
  sizenow = size(A);
end

The error is "The parfor cannot run due to the way A is used." The reason it should work is that sliced variables in a parfor loop cannot change size; if they could, then the loop iterations would be dependent on each other (each would get a different size of A to work with). So shouldn't Matlab know that the size of A is fixed? If so, why can't the size of A be distributed to each processor?

In fact, if the code reads

parfor i=1:m,
  ncol = randi(n,1);
  A(i,:) = rand(1,ncol);
end

so that now the size of A changes at each loop iteration, Matlab throws a "subscripted assignment dimension mismatch" error. Matlab (or some part of it) knows what the size of A needs to be in the loop.

Isaac

Answer 1

[Edric Ellis]

MATLAB uses a language analysis to work out what's going on the body of your PARFOR loop. In this case, you would like A to be a "sliced output" - that is, each worker is writing to independent slices of A, and the whole value of A is not available. The language analysis sees the call size(A) and concludes that each worker needs to access the whole value of A inside the loop to make that call - and that is not allowed for a sliced output. In this case, we know that size(A) is constant and doesn't need the values inside the array - but the language analysis cannot prove that (for example, size might be an overloaded method).

In this case the workaround is simple - make the call to size outside the loop and pass the constant size into the loop. In your case you can simply use m and n inside the loop.

[Isaac]

In response to Edric and Matt -- I don't see how any statement like "tmp = func(A)" could ever change the size of A. In a parfor loop, the size of A must be constant, or else you couldn't slice it and put it back together at the end.

I agree that in general a parfor loop with "tmp = func(A)" is illegal because the iterations could be dependent. However, I think the Matlab language analysis should understand certain functions that are invariant in a parfor loop (e.g. size, class, isnumeric, etc). These functions must be invariant in order for the reduction at the end of the parfor to work correctly (i.e. gathering the pieces from each parallel job together).

Of course, I moved the size() statement outside of the loop and everything works fine.

[Matt J]

However, I think the Matlab language analysis should understand certain functions that are invariant in a parfor loop

As Edric said, though, the size() function is overloadable. If the variable you are slicing is not a native MATLAB object, but rather an object of a user-defined class with its own size() method, parfor has no way of verifying that that size() method has the same invariant behavior as the native one.

Possibly, parfor could be engineered to detect when A is a native MATLAB object, and treat that as a special case. But again, why would the software developers go to such lengths when it only serves to support inefficient coding? If size() is returning the same result every time, it shouldn't be in the loop.

[Isaac]

Again, I agree that the right way to do this is just to call size() before the loop.

I'd like to point out, though, that Matlab gives special meaning to the operators +,min(),max(),union(),intersect(), and some others in the parfor context; they can operate as reductions. Of course, +,min(), etc could be overloaded with non-associative operators, and then the reduction with parfor would not work. In the same way that calling

A = min(A,val);

triggers a parallel-reduction, it makes sense to me that calling

sz = size(A);

could trigger a broadcast.

Answer 2

[Thorsten]

Probably Matlab simply is not smart enough to figure out that in your particular example the size of A is fixed. Without having preallocated A outside the loop the size cannot determined within the parfor. So it would boil down to check that 1. A is defined before parfor 2. All changes of A in loop do not affect it's size

2. is easy in your example, but could be much harder in general. May be that's why it is not implemented at all.

Answer 3

[Matt J]

If so, why can't the size of A be distributed to each processor?

My guess is they could, but don't expect you to require it. After all, why would you repeatedly compute the size of a matrix in a loop when its size never changes? The more efficient thing would always be to compute it once prior to the loop and broadcast that result to the workers.