parpool sorting out the default number of workers
43 Ansichten (letzte 30 Tage)
Ältere Kommentare anzeigen
Bruno Luong
am 5 Jan. 2023
Verschoben: Bruno Luong
am 31 Jan. 2023
I'm a little bit lost in the default number of workers when parpool() is invoked. My PC is standalone with Intel Processor and Windows-based with MATLAB R200B.
- In the Preferences Parallel Computing Toolbox window, both Porcesses and Threads profiles indicate the default value of number of workers is 12
- My processor has 14 cores; 6 performance, 6 Efficient, and 20 (hyper) threading according to Intel link
The command maxNumCompThreads returns 6
>> maxNumCompThreads('automatic')
ans =
6
The command parpool returns 14
>> delete(gcp('nocreate'))
>> p = parpool('Threads')
Starting parallel pool (parpool) using the 'Threads' profile ...
Connected to the parallel pool (number of workers: 14).
p =
ThreadPool with properties:
NumWorkers: 14
Busy: false
The questions are
- Why 14 and not 12 as setup by Preferences?
- How parpool and Preferences setup those numbers?
In general it's all over the place to me, if someone can shed the light it would be great.
0 Kommentare
Akzeptierte Antwort
Alison Eele
am 31 Jan. 2023
Verschoben: Bruno Luong
am 31 Jan. 2023
Thanks for the follow on questions Bruno!
Preferred Number of Workers in a Pool
For parpool('processes') the number of workers you will get will be the minimum of: the parallel preference; or the NumWorkers field in the 'processes' cluster profile. In your case I would expect it to open a parallel pool of 12 workers [min(12,14)].
The default value of 12 in the Parallel Preferences will only apply to non-thread pools. This stems from Thread pools historically following the value of maxNumCompThreads() thus this preference never applied. From R2022b you can now specify a size of thread pool and parpool('threads') defers to the same default number of workers as the 'processes' profile i.e. the number of physical cores detected.
maxNumCompThreads behaviour
The value returned by maxNumCompThreads('automatic') is counting just your performance cores (6) rather than performance + efficiency (14). This is because maxNumCompThreads primarily focuses on the implicit multi-threading of mathematical operations which should take place on the Performance cores of your processor. Adding additional threads would either cause resource contention on the Performance cores or cause them to run on some of the efficiency cores which could incur some slowdown on the overall operation.
Standalone Deployed Application
When you deploy onto another machine using the 'processes' or 'local' profile it by default will use a number of cores = to the number of physical cores detected on the machine. I would recommend finding out how many workers the cluster profile thinks it has by instantiating a cluster object then querying the number of workers:
c = parcluster('processes');
numcores = c.NumWorkers
This would be safer than using an undocumented feature command.
1 Kommentar
Weitere Antworten (1)
Raymond Norris
am 6 Jan. 2023
Bearbeitet: Edric Ellis
am 6 Jan. 2023
Hey @Bruno Luong, per your link, you have 8 Efficient cores, hence 14 (6+8) cores. For R2022b (which I think is the version you're using), the Threads profile doesn't allow for less than the number of cores you have. The Process profile uses the standard min(12,#cores).
For Performance vs Efficient, can you run the following and post the answer?
feature numcores
Siehe auch
Kategorien
Mehr zu Parallel Computing Fundamentals finden Sie in Help Center und File Exchange
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!