Path: news.mathworks.com!not-for-mail
From: Mike Karr <mkarr@mathworks.com>
Newsgroups: comp.soft-sys.matlab
Subject: Re: Parfor counts backward?
Date: Fri, 16 Oct 2009 07:41:16 -0400
Organization: The MathWorks, Inc.
Lines: 46
Message-ID: <hb9m4u$gan$1@fred.mathworks.com>
References: <haich2$38a$1@fred.mathworks.com> <haidi0$9qa$1@fred.mathworks.com>
NNTP-Posting-Host: mkarr-deb5-64.dhcp.mathworks.com
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: fred.mathworks.com 1255693278 16727 172.31.45.219 (16 Oct 2009 11:41:18 GMT)
X-Complaints-To: news@mathworks.com
NNTP-Posting-Date: Fri, 16 Oct 2009 11:41:18 +0000 (UTC)
User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)
In-Reply-To: <haidi0$9qa$1@fred.mathworks.com>
Xref: news.mathworks.com comp.soft-sys.matlab:577794


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