Thread Subject:

Indexing of PARFOR reduction variables

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?

"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.

"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.

"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.

"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

"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.