Will leftover CPU cores (not used by parfor workers) be used for built-in multithreading?

I have an 8-core CPU with 16 logical cores (hyper-threading). I’m aware that MATLAB’s built-in functions (e.g., min, max, sum, large matrix operations) can use multiple threads internally.

Right now, I need to run several time-consuming tasks in parallel using parfor with the "threads" profile. Typically, I’d start a pool with 8 workers (one per physical core). However, I’m considering creating a pool with only 6 workers, leaving 2 physical cores “free.” My hope is that these 2 leftover cores would be used by each worker’s built-in multithreading, potentially speeding up those internal functions.

My questions are:

1. If I create a 6-worker pool on an 8-core machine, will the built-in threaded functions inside each worker automatically use the remaining 2 cores?
2. Does the operating system or MATLAB’s runtime effectively allocate these leftover cores to those functions, or is that not how it works in practice?

The job for each worker does not depend on any other thing.

I’d appreciate any insights or suggestions on finding the right balance between the number of parfor workers and MATLAB’s internal multithreading. Thank you!

Answer 1

[Walter Roberson]

No, left-over cores will not be automatically used. They will be left for the operating system to run (whatever) on.

If you want more than one core for each worker then you need to use the Cluster Profile Manager to specify a higher "Number of computational threads to use on each worker NumThreads".

However, each worker will use the same number of cores, so the best you could do would be to allocate NumWorkers as 4 and NumThreads as 2.

[Lorenco Santos Vasconcelos]

Hi @Walter Roberson, thanks for the reply! I understand what you mean. But can this be done (NumWorkers as 4 and NumThreads as 2) in a threads environment (i mean, when I use parpool('threads',nWorkers)) or it can only be done in a Processes environment?

I'm asking because migrating to a Processes environment can make things slower than a Threads environment in my specific case. My code do not transfer large amount of data, it is just a time-consuming operation that I must perform several times, so I can get each worker to run them in parallel, but still making use of built-in multi-thread inside each worker.

It is a trade-off between using all workers in the parfor and all of them not using multi-thread in the min, max, sum functions or use for example 4 workers but each one having 2 threads to speed up the built-in functions.

What is your opinion on this please?

[Walter Roberson]

Editting the cluster profile does not have any effect on Threads pool.

I am not certain but I think that Threads pool allocates one core per thread. But possibly they do not explicitly allocate cores and simply leave it up to the operating system to schedule them... constrained to one core at a time.

[Lorenco Santos Vasconcelos]

@Walter Roberson, I was a bit puzzled by this because when I start p = parpool("Threads",6), once the parfor starts, all 16 logical cores go to 100%, so I thought that 12 logical cores were doing the parfor iterations and the 4 remaining logical cores were serving these 12 parallel jobs doing the multi-threaded functions.

Just for clarifying: when I call p = parpool("Threads",6), what does really happen? Does 6 physical cores are allocated to perform 6 tasks in parallel and beacuse of hyper-threading, each one has 2 threads?

Or does MATLAB gets 6 physical cores (12 logical cores) and starts doing 12 tasks in parallel?