MATLAB Answers

parfor does not uns parallel pool when a parfeval process is still running

6 views (last 30 days)
Andre Zeug
Andre Zeug on 1 May 2020
Commented: Edric Ellis on 6 May 2020
Dear all,
in my code I use parallel pool on a local machine and execute a longer function with 'parfeval'. In the main code I shortly later want to use 'parfor', but checking CPU work load, 'parfor' does not use any worker since 'parfeval' still uses one worker when executing 'parfor'.
Is this behaviour expected?
How to check, if there are still running processes at the parallel pool?
How to wait until all processes at the parallel pool are finished?
Thanks in advance
I am using Win10 64bit, Matlab R2020a, Parallel Computing Toolbox 7.2.

  2 Comments

Andre Zeug
Andre Zeug on 1 May 2020
@Matt Thanks for immediat reply.
But how to find the future object F? So far I execute parfeval in a subfunction and do not handle return values from parfeval.

Sign in to comment.

Accepted Answer

Edric Ellis
Edric Ellis on 1 May 2020
Yes, this behaviour is expected - the different parallel language features parfor, parfeval, and spmd do not share the pool. You can wait for all parfeval requests like so:
p = gcp('nocreate');
if ~isempty(p)
q = p.FevalQueue;
% First wait for any queued futures
wait(q.QueuedFutures);
% Then wait for any running futures
wait(q.RunningFutures);
end
(The calls to wait need to be in that order - in the other order, any queued futures will start running after the first wait).

  8 Comments

Show 5 older comments
Edric Ellis
Edric Ellis on 5 May 2020
The statement parcluster('local2') creates a cluster object, but does not launch any worker processes. Worker processes are launched only when you submit work to the cluster using batch or parpool.
The slightly confusing situation I was trying to explain is that even when you have two cluster profiles for the local cluster, there is still only a single underlying local cluster mechanism shared by all cluster objects. That means that if you have two "local" cluster profiles called local and local2, they both share the same pool of workers.
This means that any time you modify the NumWorkers property of any local cluster instance, all others get the same value. (Creating a cluster instance using parcluster where the profile has a specific value for NumWorkers also counts as "modifying NumWorkers").
So, I constructed two cluster profiles on my machine. local2 specifies NumWorkers = 2, and local specifies NumWorkers = 6. You can see the effect of this like so:
>> l2 = parcluster('local2'); l2.NumWorkers
ans =
2
>> l = parcluster('local'); l.NumWorkers
ans =
6
% Because 'local' specifies NumWorkers = 6, l2 reflects this value!
>> l2.NumWorkers
ans =
6
Andre Zeug
Andre Zeug on 5 May 2020
Interesting, but look at this:
l2 = parcluster('local2'); l2.NumWorkers
ans =
2
p = parpool('local', 6); p.NumWorkers
>> Starting parallel pool (parpool) using the 'local' profile ...
>> Connected to the parallel pool (number of workers: 6).
ans =
6
>> l2.NumWorkers
ans =
8
so 'parpool' is a subset of 'parcluster'? But when creating it extends 'parcluster'.
Edric Ellis
Edric Ellis on 6 May 2020
parpool consumes workers from the appropriate cluster. When you say parpool('local', 6), this effectively does the following:
clus = parcluster('local');
parpool(clus, 6);
So, in your case, the 'local' cluster defines NumWorkers to be 8. Your parpool explicitly asks for only 6 of them. As I showed above, all local clusters are linked to a single mechanism behind the scenes. Therefore, (and I admit somewhat surprisingly), calling parpool('local',6) has the side-effect of changing the value of l2.NumWorkers to whatever NumWorkers is specified in your 'local' cluster.

Sign in to comment.

More Answers (0)

Products


Release

R2020a

Translated by