MATLAB: Execution time with or without parfor

Parallel Computing Toolboxparfor overhead; script vs function

I have a simple code for testing parfor in my local profile (with 4 cores)

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


%code 1
matlabpool open 4 % 2 or 1
tic;
parfor i = 1:30
   res = 0;
   for n = 1 : 3000000
      res = res + sin(n) + cos(n);
   end
   A(i) = res;
end
toc;
matlabpool close
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%code 2
tic;
for i = 1:30
  res = 0;
  for n = 1 : 3000000
    res = res + sin(n) + cos(n);
  end
  A(i) = res;
end
toc;
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

I have executed code 1 using 4 labs or 2 labs or 1 lab and executed code 2. the results is here:

code-1 - 8 labs(4 core with 4 hypthread) --> 15 sec
code-1 - 4 labs                          --> 22 sec
code-1 - 2 labs                          --> 35 sec
code-1 - 1 labs                          --> 65 sec
code-2 -                                 --> 18 sec

regards the results, it is better to use code-2 and releasing all other cores (you may also consider the time needed to run 'matlabpool open' and 'matlabpool close'). I have read this : http://www.mathworks.co.uk/matlabcentral/answers/44734-there-is-aproblem-in-parfor

but it seems in this case execution time is much longer than setup time of parallel mechanism.

if there is not any thing wrong with my results, main question is when its better to use parfor.

Best Answer

If I run the code as a function, I will get your results and If I run it as a script (without deceleration of function and name) I get bad results. and my new results (poolnum = 4) :

I think you're on to something! I was indeed running inside a function. When I repeated the test, but running it as a script instead, I get bad behavior similar to what you were reporting.

As can be seen here, PARFOR eventually does outperform a plain for-loop, but it takes a very large worker pool, and with very marginal benefits.

I'm just wondering now whether this is known/documented behavior, or a bug...

Related Solutions

MATLAB: Is batch() so slow

Firstly, if you're using the local cluster type, then the batch command absolutely does need to launch the worker MATLAB process - it is not already running - you can verify this using Task Manager or similar. (Clusters of type MJS keep the workers running). The time for the batch command is simply the time needed to create the parallel.Job and parallel.Task objects needed for running the batch job, and saving those to disk.

Roughly speaking, the time taken to execute submitting and waiting for the results can be broken down like this:

Time taken to create and submit the batch job to the scheduler
Time taken to launch the worker process (unless you're using MJS)
Time taken for the worker to load the job and task information
Time for the worker to actually run the task
Time for the worker to save the task results to disk (or database for MJS)

I suspect that the "missing" time is probably largely related to item 5 in the list above - as you've written it, the 512x512x1000 array is returned by your task function @load, and this result gets saved to disk.

How long does your save('a') command take? I suspect item 5 would take at least that long.

Note that there are several additional properties on the job object that can help you work out what's going on - see the reference page. In particular, note CreateTime, SubmitTime, StartTime, and FinishTime. The underlying task object has the same properties (except SubmitTime).

MATLAB: Does the parallel mode slow down the speed of each core/task

Does that mean that the vectorization is always contradict to the multi-core parallelization?

There appears to be a bit of a clash between vectorization and caching in MATLAB. This affects both serial and parallel for loops as the following plot shows. The code that generated these plots is further below. It basically repeats the same total computation with different relative amounts of looping and vectorization. The plot shows computation time vs. the chunk size of the vectorized data.

The plot establishes that optimal performance isn't necessarily achieved by doing the most vectorization possible. Some intermediate vector size and number of loop iterations turns out to be best for both for and parfor. Notice also that parfor achieves the best speed-up factor over for when the least amount of vectorization is done (data size = 1000). I imagine this is because parfor can then cache the data on the CPU and the workers fight less for access to RAM. However, the overall speed performance in this case is the worst because diminishing the amount of vectorization too much eventually causes the speed to suffer.

The trends in the plot are very likely platform-dependent and computation-dependent. I did this with a pool of 2 workers on an i7-2640M, 2.8GHz quadcore CPU, MATLAB version R2013b.

The bottom line, though, is that it may take some experimentation to find the optimal amount of vectorization for your problem.

N0=8; M0=1e7;
for j=0:4;            
   realloc=10^j;      
   N=realloc*N0;
   M=M0/realloc;
              tic;
              parfor i=1:N
                 A=rand(1,M);
                 polyval(1:5,A);
              end
              compTime_PARFOR(j+1)=toc;
              tic;
              for i=1:N
                 A=rand(1,M);
                 polyval(1:5,A);
              end
              compTime_FOR(j+1)=toc;       
end
semilogx(  M0./(10.^(0:4)) , compTime_FOR,'-*',...
           M0./(10.^(0:4)) , compTime_PARFOR,'--sr' );
legend('For','Parfor')
ylabel 'Time (sec)'
xlabel 'Data Size'

Related Question