Can continue make parfor ineffective?

Allocation of workers are assigned by the compiler at the begining of the parfor cycles? Or is it decided on-line during the cycles? So is it possible that one worker do nothing ineffectively, because always getting 'countinue' and finish the job much earlier than the others?

[Rik]

If this were the case, I think this would warrant a mention in the doc for parfor. As I understand it, the workers just pop another iteration from the queue when they are done with their current one, so using continue frequently shouldn't have a lot of impact on the effectiveness.

But I would like someone to confirm this.

Answer 1

[Walter Roberson]

"Allocation of workers are assigned by the compiler at the begining of the parfor cycles? "

2/3 of the iterations are pre-determined. The other 1/3 of the iterations are held in reserve and are given in smaller chunks as workers finish their tasks.

"So is it possible that one worker do nothing ineffectively, because always getting 'countinue' and finish the job much earlier than the others?"

Yes, it is possible. Once a worker has been given a chunk of iterations, it is responsible for finishing all of the chunk. If one of the iterations is taking a long time and other workers have nothing to do but there are remaining iterations, then those iterations are not handed over to the other workers.

parfor assumes that each chunk of iterations will take more or less the same time, on average -- that even if one particular iteration takes longer, that "probably" the chunk also got some shorter iterations. If it is possible in your situation that there is a "run" of longer iterations that might happen to all get allocated to the same worker with the other workers mostly getting much shorter tasks, then instead of using parfor(), you should use batch() or parfeval() for the iterations.