Discover MakerZone

MATLAB and Simulink resources for Arduino, LEGO, and Raspberry Pi

Learn more

Discover what MATLAB® can do for your career.

Opportunities for recent engineering grads.

Apply Today

Thread Subject:
Usage of reduction variables in parfor loops

Subject: Usage of reduction variables in parfor loops

From: Matt J

Date: 22 Oct, 2010 19:08:03

Message: 1 of 9

Suppose I have code along these lines:

data=rand(1,1e5); xi=1; increm=rand(1);

for j=1:1e4
  xi=xi+increm; %Would this become a reduction variable under parfor
  c(j)=interp1(data,xi);
end


I know that if the line

  c(j)=interp1(data,xi);

where absent, then the above loop could be reimplemented using parfor and xi would be a reduction variable. But what about here, where xi is also input to code elsewhere in the loop?

I can see nothing in the PCT manual which says that a reduction variable cannot be used as input to other things in the parfor loop.

On the other hand, my understanding is that the value of a reduction variable can never be resolved until all labs have completed their portion of the parfor loop and the results are post-consolidated. Therefore, I can't see how a reduction variable would ever be allowed to serve as a valid input argument to code elsewhere in the loop.

Insights welcome.

Subject: Usage of reduction variables in parfor loops

From: Sean

Date: 22 Oct, 2010 19:22:03

Message: 2 of 9

"Matt J " <mattjacREMOVE@THISieee.spam> wrote in message <i9snej$28l$1@fred.mathworks.com>...
> Suppose I have code along these lines:
>
> data=rand(1,1e5); xi=1; increm=rand(1);
>
> for j=1:1e4
> xi=xi+increm; %Would this become a reduction variable under parfor
> c(j)=interp1(data,xi);
> end
>
>
> I know that if the line
>
> c(j)=interp1(data,xi);
>
> where absent, then the above loop could be reimplemented using parfor and xi would be a reduction variable. But what about here, where xi is also input to code elsewhere in the loop?
>
> I can see nothing in the PCT manual which says that a reduction variable cannot be used as input to other things in the parfor loop.
>
> On the other hand, my understanding is that the value of a reduction variable can never be resolved until all labs have completed their portion of the parfor loop and the results are post-consolidated. Therefore, I can't see how a reduction variable would ever be allowed to serve as a valid input argument to code elsewhere in the loop.
>
> Insights welcome.

Hi Matt,
This works:
%%%
xi=1; increm=rand(1);
parfor j=1:10000
    xi=xi+increm; %Would this become a reduction variable under parfor
end

%%%
M-LINT gave me beef about the 1e4 in the parfor loop initiation saying that it had to be integer. It didn't throw an error either way and produced the same results as
1+increm*10000

Subject: Usage of reduction variables in parfor loops

From: Sean

Date: 22 Oct, 2010 19:28:03

Message: 3 of 9

"Sean " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message <i9so8r$p7b$1@fred.mathworks.com>...
> "Matt J " <mattjacREMOVE@THISieee.spam> wrote in message <i9snej$28l$1@fred.mathworks.com>...
> > Suppose I have code along these lines:
> >
> > data=rand(1,1e5); xi=1; increm=rand(1);
> >
> > for j=1:1e4
> > xi=xi+increm; %Would this become a reduction variable under parfor
> > c(j)=interp1(data,xi);
> > end
> >
> >
> > I know that if the line
> >
> > c(j)=interp1(data,xi);
> >
> > where absent, then the above loop could be reimplemented using parfor and xi would be a reduction variable. But what about here, where xi is also input to code elsewhere in the loop?
> >
> > I can see nothing in the PCT manual which says that a reduction variable cannot be used as input to other things in the parfor loop.
> >
> > On the other hand, my understanding is that the value of a reduction variable can never be resolved until all labs have completed their portion of the parfor loop and the results are post-consolidated. Therefore, I can't see how a reduction variable would ever be allowed to serve as a valid input argument to code elsewhere in the loop.
> >
> > Insights welcome.
>
> Hi Matt,
> This works:
> %%%
> xi=1; increm=rand(1);
> parfor j=1:10000
> xi=xi+increm; %Would this become a reduction variable under parfor
> end
>
> %%%
> M-LINT gave me beef about the 1e4 in the parfor loop initiation saying that it had to be integer. It didn't throw an error either way and produced the same results as
> 1+increm*10000


I misread your above post:
It will not work.

Here is the MLINT error
"The PARFOR loop cannot run due to the way xi is used"

And the error when I run it:
??? Error: The variable xi is perhaps intended as a reduction variable, but is actually
an uninitialized temporary.
 See Parallel for Loops in MATLAB, "Temporary Variables Intended as Reduction
 Variables".

Subject: Usage of reduction variables in parfor loops

From: Matt J

Date: 22 Oct, 2010 19:30:06

Message: 4 of 9

"Sean " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message <i9so8r$p7b$1@fred.mathworks.com>...
>
> Hi Matt,
> This works:
> %%%
> xi=1; increm=rand(1);
> parfor j=1:10000
> xi=xi+increm; %Would this become a reduction variable under parfor
> end
====

Thanks, Sean. But like I said, I know this simpler case works. My question was whether including the line

c(j)=interp1(data,xi)


destroys things.

Subject: Usage of reduction variables in parfor loops

From: Matt J

Date: 22 Oct, 2010 19:51:03

Message: 5 of 9

"Sean " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message <i9sok3$i43$1@fred.mathworks.com>...
>
> See Parallel for Loops in MATLAB, "Temporary Variables Intended as Reduction
> Variables".
=======

Ah! That's what I was missing. Thanks.

Subject: Usage of reduction variables in parfor loops

From: Steven_Lord

Date: 22 Oct, 2010 20:23:57

Message: 6 of 9



"Matt J " <mattjacREMOVE@THISieee.spam> wrote in message
news:i9snej$28l$1@fred.mathworks.com...
> Suppose I have code along these lines:
>
> data=rand(1,1e5); xi=1; increm=rand(1);
>
> for j=1:1e4
> xi=xi+increm; %Would this become a reduction variable under parfor
> c(j)=interp1(data,xi);
> end
>
>
> I know that if the line
>
> c(j)=interp1(data,xi);
>
> where absent, then the above loop could be reimplemented using parfor and
> xi would be a reduction variable. But what about here, where xi is also
> input to code elsewhere in the loop?

I believe this code has an order dependency; the value at which you're
interpolating depends on how many iterations of the loop have been executed.
As written, therefore, I think you're stuck.

If you were to modify this to:

data = rand(1, 1e5);
increm = rand();
parfor k = 1:1e4
    xi = 1+k*increm;
    c(k) = interp1(data, xi);
end

then I believe you're okay.

>
> I can see nothing in the PCT manual which says that a reduction variable
> cannot be used as input to other things in the parfor loop.
> On the other hand, my understanding is that the value of a reduction
> variable can never be resolved until all labs have completed their portion
> of the parfor loop and the results are post-consolidated. Therefore, I
> can't see how a reduction variable would ever be allowed to serve as a
> valid input argument to code elsewhere in the loop.
>
> Insights welcome.

--
Steve Lord
slord@mathworks.com
comp.soft-sys.matlab (CSSM) FAQ: http://matlabwiki.mathworks.com/MATLAB_FAQ
To contact Technical Support use the Contact Us link on
http://www.mathworks.com

Subject: Usage of reduction variables in parfor loops

From: Matt J

Date: 22 Oct, 2010 20:32:05

Message: 7 of 9

"Steven_Lord" <slord@mathworks.com> wrote in message <i9srst$l3p$1@fred.mathworks.com>...
>
> If you were to modify this to:
>
> data = rand(1, 1e5);
> increm = rand();
> parfor k = 1:1e4
> xi = 1+k*increm;
> c(k) = interp1(data, xi);
> end
>
> then I believe you're okay.
===========

Thanks, that is my fallback plan. Incrementing the additive way was an effort to minimies multiplication ops. Of course, I don't know if adds are really still to be favoured over multiplies anymore in today's processors.

Subject: Usage of reduction variables in parfor loops

From: Sean

Date: 22 Oct, 2010 20:36:03

Message: 8 of 9


> If you were to modify this to:
>
> data = rand(1, 1e5);
> increm = rand();
> parfor k = 1:1e4
> xi = 1+k*increm;
> c(k) = interp1(data, xi);
> end
>
> then I believe you're okay.
>

%%%
data = rand(1, 1e5);
increm = rand();
parfor k = 1:1000
    xi = 1+k*increm;
    c(k) = interp1(data, xi);
end
%%%
This works!

Subject: Usage of reduction variables in parfor loops

From: Matt J

Date: 29 Oct, 2010 21:03:04

Message: 9 of 9

"Matt J " <mattjacREMOVE@THISieee.spam> wrote in message <i9ssc5$lm1$1@fred.mathworks.com>...
> "Steven_Lord" <slord@mathworks.com> wrote in message <i9srst$l3p$1@fred.mathworks.com>...
> >
> > If you were to modify this to:
> >
> > data = rand(1, 1e5);
> > increm = rand();
> > parfor k = 1:1e4
> > xi = 1+k*increm;
> > c(k) = interp1(data, xi);
> > end
> >
> > then I believe you're okay.
> ===========
>
> Thanks, that is my fallback plan. Incrementing the additive way was an effort to minimies multiplication ops. Of course, I don't know if adds are really still to be favoured over multiplies anymore in today's processors.
==========

I guess multiplies are still bad. After some quick experiments, this loop

for k = 1:500
    xi = xi0+(k-1)*increm; %increm,xi0 are 380x480
end

is about 3 times slower than this loop

xi=xi0;
for k = 1:500
    xi = xi + increm;
end

Tags for this Thread

What are tags?

A tag is like a keyword or category label associated with each thread. Tags make it easier for you to find threads of interest.

Anyone can tag a thread. Tags are public and visible to everyone.

Contact us