Got Questions? Get Answers.
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:
Indexing of PARFOR reduction variables

Subject: Indexing of PARFOR reduction variables

From: Matt J

Date: 17 Nov, 2010 20:42:04

Message: 1 of 6

I've just discovered that reduction assignments inside PARFOR loops cannot involve indexing. For example, the following two parfor loops attempt equivalent computations, but only the first one runs error-free

parfor ii=1:3 %First Version
 x=x+1;
end


parfor ii=1:3 %Second version
    for jj=1:5
      x(jj)=x(jj)+1;
    end
end


The second loop invokes the error

??? Error: File: test.m Line: 14 Column: 7
The variable x in a parfor cannot be classified.
 See Parallel for Loops in MATLAB, "Overview".

This is a problem for me because I have a larger application with a nested loop of the form

parfor i=1:M

   %i-dependent computations here

    for j=1:N

     %Compute Slab_j here, j-dependent

      Image3D(:,:,j)=Image3D(:,:,j)+Slab_j;

    end
end

where Image3D is large (e.g. 500x500x300). The only way I can see around this is to generate a 2nd array containing all the Slab_j, which is unattractive memory-wise.

Any suggested workarounds?

Subject: Indexing of PARFOR reduction variables

From: Sean de

Date: 17 Nov, 2010 21:05:05

Message: 2 of 6

"Matt J "
> This is a problem for me because I have a larger application with a nested loop of the form
>
> parfor i=1:M
>
> %i-dependent computations here
>
> for j=1:N
>
> %Compute Slab_j here, j-dependent
>
> Image3D(:,:,j)=Image3D(:,:,j)+Slab_j;
>
> end
> end
>
> where Image3D is large (e.g. 500x500x300). The only way I can see around this is to generate a 2nd array containing all the Slab_j, which is unattractive memory-wise.
>
> Any suggested workarounds?

Could you just do two parfor loops? The first one calculates your i-dependencies and stores them. The second uses those for the j-depedencies if necessary? You haven't indicated any reason why the j-loop has to be inside the i-loop.

Subject: Indexing of PARFOR reduction variables

From: Matt J

Date: 17 Nov, 2010 21:30:25

Message: 3 of 6

"Sean de " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message <ic1g21$q1m$1@fred.mathworks.com>...
>
> You haven't indicated any reason why the j-loop has to be inside the i-loop.
=====

Apologies, Slab_j is also-i-dependent. I shoudl have notated it Slab_ij

> Could you just do two parfor loops? The first one calculates your i-dependencies and stores them. The second uses those for the j-depedencies if necessary?
====

You can't nest parfor loops.

Subject: Indexing of PARFOR reduction variables

From: Sean de

Date: 17 Nov, 2010 21:49:27

Message: 4 of 6

"Matt J " <mattjacREMOVE@THISieee.spam> wrote in message <ic1hhg$4ro$1@fred.mathworks.com>...
> "Sean de " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message <ic1g21$q1m$1@fred.mathworks.com>...
> >
> > You haven't indicated any reason why the j-loop has to be inside the i-loop.
> =====
>
> Apologies, Slab_j is also-i-dependent. I shoudl have notated it Slab_ij
>
> > Could you just do two parfor loops? The first one calculates your i-dependencies and stores them. The second uses those for the j-depedencies if necessary?
> ====
>
> You can't nest parfor loops.

I meant have them be subsequent, but that won't work if Slab_ij is i-dependent.

Subject: Indexing of PARFOR reduction variables

From: Sean de

Date: 17 Nov, 2010 22:08:03

Message: 5 of 6

"Sean de " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message <ic1il7$ia1$1@fred.mathworks.com>...
> "Matt J " <mattjacREMOVE@THISieee.spam> wrote in message <ic1hhg$4ro$1@fred.mathworks.com>...
> > "Sean de " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message <ic1g21$q1m$1@fred.mathworks.com>...
> > >
> > > You haven't indicated any reason why the j-loop has to be inside the i-loop.
> > =====
> >
> > Apologies, Slab_j is also-i-dependent. I shoudl have notated it Slab_ij
> >
> > > Could you just do two parfor loops? The first one calculates your i-dependencies and stores them. The second uses those for the j-depedencies if necessary?
> > ====
> >
> > You can't nest parfor loops.
>
> I meant have them be subsequent, but that won't work if Slab_ij is i-dependent.

You could make the inner loop a PARFOR. At least that works on my simple test case:
Image3D = zeros(1,1,2);
for i=1:5

   %i-dependent computations here
    k=i*2;
    parfor j=1:2
      L = j*3;
     %Compute Slab_j here, j-dependent
        
      Slab_j = k+L;
      Image3D(:,:,j)=Image3D(:,:,j)+Slab_j;

    end
end

Subject: Indexing of PARFOR reduction variables

From: Matt J

Date: 17 Nov, 2010 23:14:05

Message: 6 of 6

"Sean de " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message <ic1jo3$4u2$1@fred.mathworks.com>...
>
> You could make the inner loop a PARFOR. At least that works on my simple test case:
=======

Yes and in fact that was the approach I initially implemented, since that way Image3D gets sliced, which presumably is a good thing. However, this turns out to be slower even than a regular serial for-loop.

So, I was thinking back to what you were saying in other posts about parfor efficiency depending on the balance between memory transfer operations and on-chip calculations. I was hoping that maybe moving the parfor to the outer loop would improve this balance. I'm starting to doubt it though.

I'm now wondering whether moving PARFOR to the inner loop would be more efficient if I co-distributed Image3D in a prior step outside the loop. That way, hopefully, there wouldn't be a need to re-slice Image3D each time i is incremented in the outer-loop.

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