Using symbolic subs call inside parfor loop

I have the following pieces of code where the symbolic expressions to be evaluated are quite heavy.

classdef T4
    properties (SetAccess = private)
        % symbolic properties
        xe % vector of symbolic variables
        ge % vector or matrix of symbolic expressions depending on xe
        
        % numeric properties
        se % numeric vector or matrix
        Xe % numeric values to be assigned
    end
    methods
        % all other methods
        function T = computeG(T);
            T.se = double(subs(T.ge,T.xe,T.Xe));
        end
    end
end

nT = 5;
Tv(nT,1) = T4;
for i=1:nT
    Tv(i) = computeG(Tv(i));
end

I do not get any gain, in fact it is worse if I use instead

parfor i=1:nT
    Tv(i) = computeG(Tv(i));
end

[Walter Roberson]

When you use parfor and the symbolic toolbox, does one MuPAD engine get allocated per worker, or do all of the workers end up talking to the same client?

The MuPAD engine is normally a seperate process that is communicated with by TCP/IP.

[Antonio Bilotta]

Thank you very much for your answer. I don't know how to check on this issue and how to allocate, if necessary, one MuPAD engine for each worker.

[Walter Roberson]

My tests show that one mupad kernel process is allocated for each worker. (The kernels use a lot less memory than I might have guessed. They also have about 39 megabytes of shared memory; I am not sure what that is used for.)

Answer 1

[Raymond Norris]

Hi Antonio,

You're just not giving each of the workers enough work to do. Maybe you only need to run nT=5, but see what happens when you set it to 100, 200, or 1000. You should then start to see improvements.

Thanks,

Raymond

[Antonio Bilotta]

Thank you very much for your answer. I will try what you propose also if the current development of my code cannot afford more than 100.

[Antonio Bilotta]

Hi Raymond,

I have to confirm that I obtain no gain from using parfor and it is also worse. My main suspect is that the use of symbolic functions do not go parallel.

[Raymond Norris]

In your case, what is "parallelized" is the for loop, not the symbolic functions. In order for the symbolic functions to be parallelized, the author would have needed to rewrite their code to use parfor/spmd, etc.

I'm not sure if the code you posted is what you're actually running or just a prototype. If it's the actual code, then I'd agree, there doesn't appear to be enough work to be done to warrent parallellizing the code. Can you give us some sense of how long it takes you to run your for loop, both as a single iteration and in totality?

[Walter Roberson]

My test showed that a separate mupad kernel is launched for each parfor worker, so there would be no need to rewrite the symbolic functions themselves: each worker gets its own (single-threaded) engine.

It is not possible to rewrite the internals of symbolic functions to use parfor / spmd, as the internals of symbolic functions live inside the MuPAD engine, either in the form of binary files are in the form of MuPAD code.

[Antonio Bilotta]

Maybe the situation is not so plain. I am performing some tests with nT=40. In my code the for loop is called several times and in the case of the normal for I get the following times which change only the first time but then they remain quite stable

In the case of the parfor I get the following times which increase as analysis proceeds (I performed only 3 steps but usually more steps are required).

To be more precise the exact code is not so much different (the class function contains 2 "subs" calls).

function T = computeG(T);
    T.se = double(subs(T.ge,T.xe,T.Xe)); % evaluation of a vector
    T.Ke = double(subs(T.Je,T.xe,T.Xe)); % evaluation of a matrix
end