Basic Parallel Processing

I have code like below, without parallel processing, it is like

for n=1: 100

out1(n,:)=function1(var1(n,:)); 
out2(n,:)=function2(var2(n,:)); 
out3(n,:)=function3(var3(n,:));

out(n,:)=function4(out1(n,:),out2(n,:),out3(n,:));
end

To speed up the process, I would like to parallel process function calls of function1, function2, function 3 and wait for all this job finished and execute the function4.

Is is possible to rewrite this using parallel processing toolbox? By the way, function1, function2, fucntion3 uses persistent variables and also global variables.

[Daniel Shub]

Are the global variables used in function1, function2, etc independent from each or non changing?

Answer 1

[Jason Ross]

I would take a look at the "job and task" programming model. You could do it something akin to the following pattern:

for n=1:100
  job = createJob
  out1 = job.createTask(function1)
  out2 = job.createTask(function2)
  out3 = job.createTask(function3)
  submit(job)
  waitForState(job,'finished')
  results = getAllOutputArguments(job)
  destroy(job)
  job1 = createJob
  out4 = job1.createTask(results)
  submit(job1)
  waitForState(job1,'finished')
  results = getAllOutputArguments(job1)
  destroy(job1)
end

Note that the above example is just to show a rough example ... it might answer your question.

It also matters what version of the software you are using. In 2012a, the API changed, although the concepts of the "communicating" and "independent" jobs still existed. I'd suggest digging into the doc for the jobs and tasks and running a few examples to see if they get you where you need to go.

[Jason Ross]

And I agree with Walter's comment on the global / persistent variables.

[Walter Roberson]

I shudder when I look at that outline: it has the look of being designed to accidentally maximize overhead!

[Jason Ross]

There's not much design in there, it's a strawman put together with bubblegum, designed to be tossed at a whiteboard to see if it sticks or falls apart.

Can this problem be programmed in parallel? Maybe. Will it outperform the serial version? It depends. :)

[Daniel Shub]

With the Sun Grid Engine it is possible to submit a job to the queue that will wait until other jobs have finished. This has the advantage that all your jobs get submitted quickly and start working their way up the queue. In your outline you don't submit the final job to the queue until the entire program is almost complete. This means you spend a lot of time waiting at the end of the queue. Is there a way to submit all the jobs at the outset with the MATLAB scheduler?

[Jason Ross]

I spent a little time looking into your question. I tried a scheme where I'd create a couple of jobs, then try and use waitForState to start execution when the previous one went finished. Unfortunately, you can't do that.

It doesn't mean it can't be done -- I'm by no means the end of knowledge on this so it's possible someone has an alternate means.

I specifically did not look into callbacks or notifiers, the solution may be in there.

Of course, if you wanted to build your own, you could fall back on the time-honored "drop a file somewhere" option where the first job would say "I'm done" and then the second one would be polling the filesystem waiting on the "I'm done" file to show up, although it would be "running". These waters are filled with sharks, rocks and a lot of rope, though.

But like I said, it's possible someone has a better way.

Answer 2

[Rick Rosson]

I do not think it is possible to do what you are asking, but I am not 100 percent sure.

As an alternative, you might try the following:

   parfor n = 1:100
       out1(n,:)=function1(var1(n,:)); 
       out2(n,:)=function2(var2(n,:)); 
       out3(n,:)=function3(var3(n,:));
   end

   parfor n = 1:100
       out(n,:)=function4(out1(n,:),out2(n,:),out3(n,:));
   end

Depending on the number of cores you have on your machine, and the number of workers you launch in the matlabpool, you should see a pretty good speed improvement.

HTH.

Rick

[Daniel Shub]

The persistent and global variables in use in function* will probably cause problems for parfor.

[Thomas]

The golbal variable in the Parfor will not be synchronized and might cause problems..

Answer 3

[Walter Roberson]

With the persistent variables and the global variables, we do not have enough information to assess whether this can be done in parallel. We do not know the conditions under which your persistent variables get initialized or updated, and the same for the global variables. Unless they are all effectively read-only by the time you call the first function for the first iteration, you risk race conditions.

parfor generally schedules the iterations in the reverse order of "for". If your routines have any order dependencies, then parfor is not probably not suitable.

You might be better off putting your global and persistent variables into a structure, with the structure being returned from any routine that might update the variables. This would make order dependencies clearer.