PCT: Parfor vs For with one core

We are writing an application in which some parts are meant to be in parallel. Nevertheless, we want to tune the app so that it uses the optimal number of cores (even if the number of cores = 1)

My question is: what happens with the speed of execution for these two blocs

parfor i = 1:X
  executeY
end

for i = 1:X
  executeY
end

when only one core is being used, keeping everything else constant? Is the parfor slower because it checks if a matlabpool is open? Is the speed of execution the same for both?

Answer 1

[Sean de Wolski]

Try it!

But I can let you know that parfor will be slower due to overhead;

    function test

    [t1, t2] = deal(0);    
    a = 1;
    b = 2;
    x = 3;

    %Sum their times over 1000 function calls:
    for ii = 1:1000
        tic
        for jj = 1:1000
            y = a*x+b;
        end
        t1 = t1+toc;
        tic
        parfor kk = 1:1000        
            yp = a*x+b;
        end
        t2 = t2+toc;
    end
        %Display results:
    fprintf(1,'\nFOR: %fs\nPARFOR: %fs\n',t1,t2);
    fprintf(2,'\nSlowdown: %f\n\n', t2./t1);

I'm seeing a slowdown in the high 80x

[gire]

Oh crap. It means that the app must have branches of code for the case of cores ~= 1 and the serial case. I was hoping this case could be avoided because it would lead to repetition of code, etc etc etc.

[Sean de Wolski]

Yeah, this is how I've always done it:

UseParallel = flag_for_parallel_use;
if UseParallel:
   function_with_parfor_loop;
else
   function_with_for_loop;
end

Answer 2

[Jan]

I do not have experiences with the parallel toolbox. Can you open a pool with 2 threads on a single core node? A process with alternating file access and computations, e.g. reading a movie file, could profit from multiple threads on a single core. Another example is a compression software, e.g. 7zip runs faster with two threads even on a single core processor.

[gire]

As far as I know, it is not possible to use threads with the PCT. Instead, it treats each core as if it was a completely different instance (cluster type).

Answer 3

[Jason Ross]

This special-casing may not be strictly necessary, as "parfor" reverts to serial behavior if there is no matlabpool available, as follows:

"If the parfor-loop cannot run on workers in a MATLAB pool, MATLAB executes the loop on the client in a serial manner. In this situation, the parfor semantics are preserved in that the loop iterations can execute in any order."

In regards to the thread question, each MATLAB worker process is it's own process -- you can see the number of MATLAB instances increase as a matlabpool is started. And to be extra pedantic, core count is independent of the number of worker MATLABs started -- the placement of the worker is left to the operating system entirely, and the "one core per worker" is merely a "best guess default". There are situations where you would want different ratios, depending on a number of factors.

Reference: http://www.mathworks.com/help/distcomp/parfor.html

[gire]

Hi Jason: It is clear that the parfor will run serially when no pool is found. My real concern is the execution time. Is parfor-loop as efficient as a for-loop when the pool is closed? It seems it is not :(

[Jason Ross]

Using Sean's code I was able to see the difference. I couldn't come up with a way to do it better, unfortunately.