Mysterious behavior in parfor (I know, sounds basic, but...)

This truly seems odd to me. I've tested on a couple of Ubuntu x86-64 machines with 2010b. I use "matlabpool 8" to open up 8 workers, then run the following function (simplified from useful code):

parfor ij=1:100
  ijp = ij-1;  % ijp in [0, 99]
  j = mod(ijp,10);
  i = floor(ijp/10);
  nlabs = numlabs;
  labid = labindex;
  if i == 0 || j == 0
    disp([ijp,labid,nlabs]);
    pause(10);
  else
    pause(0.01);
  end

The first round, I see 8 outputs at once meaning everything runs in parallel (the i ==0 or j == 0 entries). Soon though, there will be 10 seconds between each output from disp, meaning that for some reason the workers are no longer getting long (10 second) workloads.

If I remove the conditional (in my real case I do this when I want to do a very large simulation for all entries and not just the entries where i or j is 0) everything runs in parallel just fine.

Also, numlabs and labindex always returns 1 (not sure if that is normal).

Answer 1

[Sarah Wait Zaranek]

There were a couple questions in your quesiton, so let me go through them individually.

1. numlabs and labindex alway return 1.

This is expected behavior, numlabs and labindex are used in functions that do communications between the workers. Since this communication is not allowed in parfor loops, numlabs and labindex are set to 1 in each worker process.

2. I think you are asking how which worker gets which iteration - and why the loops aren't running in the expected numerical order

A couple things to keep in mind. parfor does automatic load balancing. This means that parfor breaks the total iterations into chunks. It sends each worker a chunk of iterations, when that worker is done with its chunk - it gets another one. This means that some workers may be chugging through the short iterations while another is stuck with the long one. Within each chunk, the iterations are actually run backwards (although your data is returned in the right order) to ensure iteration independence.

Hope this helps. I am happy to expand on this answer if I misunderstood your issue.

[Brandon Barker]

Thank you. I see that the allocation to workers is somewhat static now At least from my perspective, since having a chunk size larger than a single iteration could cause this kind of problem to occur. I believe I can fix this with a different loop.

Is there any way to control the chunk size?