Out of curiosity, how many workers do you have in your pool? Is it a reasonable multiple of the total number of iterations in your parfor?
When assigning parfor iterations to workers in the pool, your client MATLAB session first sends small chunks of tasks to get started, sends larger chunks in the middle of the processing time, then finally sends smaller chunks to try to have tasks finish reasonably close to one another. However, this automatic process may sometimes result in certain workers wrapping up early and waiting for others to finish. You can see an extemely simplified version in the code below. Since neither 17 or 19 are even multiples of the 4 workers in the pool, the overall execution time will be the same for both loops.
if isempty(gcp('nocreate'))
parpool('Processes', 4);
end
% Start the first timer for parallel execution
tic
nIterations = 17;
parfor i = 1:nIterations
% Simulate some work with a pause
pause(0.50);
end
toc
% Start the second timer for parallel execution
tic
nIterations = 19;
parfor i = 1:nIterations
% Simulate some work with a pause
pause(0.50);
end
toc
One potential workaround would be to use parforOptions to manually control the range partitioning. To quote the doc:
You can control how parfor divides iterations into subranges for the workers with parforOptions. Controlling the range partitioning can optimize performance of a parfor-loop. For best performance, try to split into subranges that are:
- Large enough that the computation time is large compared to the overhead of scheduling the subrange
- Small enough that there are enough subranges to keep all workers busy
This would allow you to manually choose how many iterations are being sent to each worker, potentially leveling out execution time at the end of your loop. If you do give it a try, let us know how it goes!
