Thread Subject: Parfor counts backward?

Hi,

When using a parfor loop without the matlabpool open it is supposed to default to a regular for loop (see documentation). This works fine but it seems to be counting from the END of the numbering array to the beginning. For example, run the following code without opening a matlab pool:

parfor x = 1:10
    disp(x);
end

And instead of seeing 1, 2, 3...10 (as you would with a for loop) you see 10, 9, 8... 1.

Any idea why it happens this way? It shouldn't matter much for results collection but still a curious behaviour.

Cheers,

Yoav

"Yoav" <yoav.farkash@utoronto.ca> wrote in message
news:haich2$38a$1@fred.mathworks.com...
> Hi,
>
> When using a parfor loop without the matlabpool open it is supposed to
> default to a regular for loop (see documentation). This works fine but it
> seems to be counting from the END of the numbering array to the beginning.
> For example, run the following code without opening a matlab pool:
>
> parfor x = 1:10
> disp(x);
> end
>
> And instead of seeing 1, 2, 3...10 (as you would with a for loop) you see
> 10, 9, 8... 1.
>
> Any idea why it happens this way? It shouldn't matter much for results
> collection but still a curious behaviour.

http://www.mathworks.com/access/helpdesk/help/toolbox/distcomp/brb2x2l-1.html#brb2x57

You should not depend on the order in which the iterations in your PARFOR
loop are executed; each iteration of the loop body must be independent of
the others.

http://www.mathworks.com/access/helpdesk/help/toolbox/distcomp/brb2x2l-1.html#brdew7t-1

I believe this is designed to encourage that, but you shouldn't assume that
it will always be the case that the loop runs in this particular order.

--
Steve Lord
slord@mathworks.com
comp.soft-sys.matlab (CSSM) FAQ: http://matlabwiki.mathworks.com/MATLAB_FAQ

Steven Lord wrote:
> "Yoav" <yoav.farkash@utoronto.ca> wrote in message
> news:haich2$38a$1@fred.mathworks.com...
>> Hi,
>>
>> When using a parfor loop without the matlabpool open it is supposed to
>> default to a regular for loop (see documentation). This works fine but it
>> seems to be counting from the END of the numbering array to the beginning.
>> For example, run the following code without opening a matlab pool:
>>
>> parfor x = 1:10
>> disp(x);
>> end
>>
>> And instead of seeing 1, 2, 3...10 (as you would with a for loop) you see
>> 10, 9, 8... 1.
>>
>> Any idea why it happens this way? It shouldn't matter much for results
>> collection but still a curious behaviour.
>
> http://www.mathworks.com/access/helpdesk/help/toolbox/distcomp/brb2x2l-1.html#brb2x57
>
> You should not depend on the order in which the iterations in your PARFOR
> loop are executed; each iteration of the loop body must be independent of
> the others.
>
> http://www.mathworks.com/access/helpdesk/help/toolbox/distcomp/brb2x2l-1.html#brdew7t-1
>
> I believe this is designed to encourage that, but you shouldn't assume that
> it will always be the case that the loop runs in this particular order.

Steve is absolutely right that you should not depend on the order. But
running the loop backward was not designed to encourage that. A more
complete story is that when parfor goes truly parallel, it in fact sends
"chunks" to workers in increasing e.g., for 1:10 the chunks might be
1:3, 4:6, 7:8, 9:10. But then in each worker, the loops are run
backward, achieving the effect of a pre-allocation (which I won't
discuss here; there are many references to it in this newsgroup).

In other words, the parfor implementation does not merely encourage
order-independence, it _relies_ on it. When parfor is run on a single
processor, the fact that the serial loop there goes backward is fallout
from the general case.

fyi,
mike