'parfor' slower than 'for'

Dear Matlab community,I'm just not quite clear why 'parfor' won't work, or what I can do to make my program faster. Here is the code.

for i=1:M
  parfor j=1:N
      [temp_node(i,j,:)]=node_automatron(node_table(i,j,:),i,j);
  end
end

parfor i=1:size(path_table,1)
    [temp_path_table(i,:),node_act_1,node_act_2]=path_automatron(path_table(i,:),node_table{path_table{i,2}(1),path_table{i,2}(2),7},node_table{path_table{i,3}(1),path_table{i,3}(2),7});         
    node_act(i,:)=[node_act_1,node_act_2];
end

Result time is about 6 seconds, 4seconds slower than when I use 'for' loop. I also tried to run other program, which 'parfor' loop is indeed faster than 'for' loop.

Thank you.

[Stephen23]

@Yutong Wu: why do you think that parfor should be faster than for ?

[Yutong Wu]

I want to know when dose parfor run faster？

[Adam]

Using a parfor loop involves an overhead of copying data to and from workers. It is hard to determine sometimes whether this overhead will be worthwhile, but it can easily make parfor slower than a for loop in many cases. Sometimes because the code is just too fast already and the copy overhead is greater than the runtime and sometimes because you get the conversion to parfor wrong and end up having full variables copied to all workers instead of slicing them or various other pitfalls you can fall into that cause far more communication between the main thread and the workers than should be needed.

Answer 1

[Cam Salzberger]

Hey Wu,

You may find this documentation page useful for helping decide if parfor is useful in your application, and how to best apply it.

The starting and stopping of a parallel pool of workers will also add to the overhead of using parfor. If you are planning on running parallel code multiple times in a row, you may wish to explicitly start and manage the parallel pool outside of the code you are running.

It's unclear to us what node_automatron and path_automatron do, or how big the node_table and path_table are. You may be better served by making those functions "vectorized" or otherwise able to operate on input arrays so that you can avoid loops entirely. Here is some basic information on vectorized code, though yours will probably be a more advanced maneuver due to the multi-dimensional arrays you are using.

Hope this helps!

-Cam

Answer 2

[OCDER]

When using parfor, Matlab must know if the variables can be processed independently of each other (sliced variable). In your 2nd parfor loop, we cannot determine if node_table is a sliced variable.

 parfor i=1:size(path_table,1)
     [temp_path_table(i,:),node_act_1,node_act_2]=path_automatron(path_table(i,:),node_table{path_table{i,2}(1),path_table{i,2}(2),7},node_table{path_table{i,3}(1),path_table{i,3}(2),7});         
                                                                                             ^ you can't access an index within another matrix of indices
     ...
 end

To simply what I mean, take a look at this.

 A = rand(10, 1); %Some sliced variable
 B = ones(10, 1); %Stores index of A to modify
 parfor j = 1:numel(A)   %the "j" is the parfor counter variable, which is what Matlab uses to determine sliced variables
    A(j) = A(j) + 1;     %OK! Two workers will never access the same jth element of A.
    A(j) = A(B(j)) + 1;  %Not okay! If B(j) = B(j+1) = 1, then >= 2 workers could potentially modify the same element in A! 
                         %This'll cause a conflict issue called Race Hazard.
                         %Even if B = [1:10], so no chance of Race Hazard, Matlab does not check for this.
 end

More about sliced variable is here:

https://www.mathworks.com/help/distcomp/sliced-variable.html

As what the others have explained, parfor does not guarantee your code will run faster. It depends on the computer of the person, the type of computation required, and the amount of data that must transferred between workers. You could run an "optimization" to determine how many iterations of a loop is required so that parfor becomes faster than for, but overall, it's a tedious task.

if iter > CritIterForParUsage %this must be determined via some optimization run
   parfor j = 1:iter
   end
else
   for j = 1:iter
   end
end

[Yutong Wu]

I modified the 2nd parfor loop several times until it works. There is no such problem that any variable cannot be classified. And my program need to iterate many times. I feel puzzled about how to make it run faster.

Thanks for your detailed explanation anyway.

[OCDER]

If parfor doesn't increase the speed to desired levels, perhaps you can improve the path_automatron and node_automatron functions instead.

There are many strategies, like using MEX routines, restructuring some code, etc.

You can try a new post asking something like "How to speed up the following code?" And show the code, and explain how parfor doesn't cut it.

https://www.mathworks.com/help/matlab/matlab_prog/techniques-for-improving-performance.html

[Yutong Wu]

OK, thank you.