Why is not my parfor-loop any faster than a for-loop?

Hi guys, would be extremely happy for any insight regarding this issue. With this code I'm looping through a big array. It feels like an optimal case to use parfor as no value is dependent on any other in the array. However the parfor is not making my code go any faster, it takes around 20 secs, regardless if I use parfor or simply for. Does anyone know why?

    A = zeros(1000, 500, 1);
    sum = 0;
    d=size(A);
    % Looping through grid
    parfor i = 1:numel(A)
        % Get subscript indices
        [a, b, c] = ind2sub(d, i);
        a = a - 500;
        b = -b;
        sum=0;  
        % Iterating through all RX pairs for this point
        for k = 1:numStations-1
            for l = k+1:numStations
                P_kl = powerRX(k) - powerRX(l);

                logArgNumer = ((a - realCoord(l, 1))^2 + (b - realCoord(l, 2))^2 + (c - realCoord(l, 3))^2);
                logArgDenom = ((a - realCoord(k, 1))^2 + (b - realCoord(k, 2))^2 + (c - realCoord(k, 3))^2);
                val = (P_kl - (5*alpha*log10(logArgNumer/logArgDenom)))^2;
                %Q(x,y)=sum            
                sum = sum + val;
            end
        end
        % Set matrix value
        A(i) = sum;

Answer 1

[Walter Roberson]

Vectorize! For example,

    A = zeros(1000, 500, 1);
    sum = 0;
    d=size(A);
    % Looping through grid
    parfor i = 1:numel(A)
        % Get subscript indices
        [a, b, c] = ind2sub(d, i);
        a = a - 500;
        b = -b;
        total = 0;  
        % Iterating through all RX pairs for this point
        for k = 1:numStations-1
            logArgDenom = ((a - realCoord(k, 1))^2 + (b - realCoord(k, 2))^2 + (c - realCoord(k, 3))^2);
            L = k+1 : numStations
            P_kl = powerRX(k) - powerRX(L);
            logArgNumer = (a - realCoord(L, 1)).^2 + (b - realCoord(L, 2)).^2 + (c - realCoord(L, 3)).^2;

             val = (P_kl(:) - (5*alpha*log10(logArgNumer/logArgDenom))).^2;
             total = total + sum(val);
        end
        % Set matrix value
        A(i) = total;
     end

I am pretty sure you could eliminate the "for k" loop as well.

[Max Nyström]

Hey man thanks a bunch! Didn't go any faster I am afraid, 19.5 secs. How would I remove the "for k" loop though? Is my parfor even working? Isn't weird that it takes exactly as long as with a for loop? there's like no difference at all :-/

[Walter Roberson]

If you have do not have the parallel computing toolbox installed or licensed then parfor is treated as plain for

[Max Nyström]

Yeah, good point! But parfor does work for me in other cases, like if I do two test functions one with and without parfor (made a pastebin for you: https://pastebin.com/66piruMa ) then parfor works.

Do you have any other idea of what could be wrong? What happens if you run the code or similiar?

[Walter Roberson]

You left out information needed to run the code, so I had to invent some things. I have attached the code I used.

If you are timing in parallel mode, be sure to start parpool before running this code, or else you will end up timing how long it takes the pool to be created.

To run in non-parallel mode, change the parfor to for.

In my testing, parallel mode took about 27 seconds and non-parallel took about 108, indicating that parallel is indeed faster for the code.

[Max Nyström]

Thanks for your code, it provided some insight as the for loop is quicker on my computer than the parfor loop. The for loop takes about 150 secons and the parfor takes about 220. This is defintely weird right? Do you have any idea as to why?

[Walter Roberson]

I do not seem to be able to replicate your results. Which MATLAB version are you using, and which operating system are you using?

[Stephen23]

"This is defintely weird right? Do you have any idea as to why?"

This is not weird at all: running a parfor is a much more complicated thing than running a simple for loop because the data needs to be partitioned and the results grouped again afterwards, so it is entirely possible that a parfor might be slower. This is clearly explained in the documentation: "There is overhead in calling parfor instead of for. If function evaluations are fast, this overhead could become appreciable. In particular, solving a problem in parallel can be slower than solving the problem serially."

source: https://www.mathworks.com/help/optim/ug/improving-performance-with-parallel-computing.html

The only time when it is worth using parfor is when the time saved running the operations inside the loop is greater than that of the extra time running the parfor. This is computing, and nothing comes for free (something that beginners seem to forget when they expect infinitely fast computers with infinite memory, infinite-precision numerics, and overhead operations that take no time at all).

[Walter Roberson]

Oh yes, also how many workers are in your pool?

Is it possible that you edited your "local" profile so that you are getting one worker per hyperthread instead of one worker per physical core? If that were done, then parfor can take longer than regular for.

hyperthreading is a method of fast switching of processes when one process does not need control of the CPU for a moment (e.g., because it is waiting for disk I/O or waiting for something to be brought in from cache.) hyperthreading does not add any computation resources: it just gives a way to switch attention between two processes that do not need 100% of a CPUs attention. But your code is simple enough and small enough that the CPUs would not have any reason to give up control, so the effect of hyperthreading would be to run all of one worker and then run the second worker, instead of running both of them simultaneously.