Matlab not using all physical cores on Intel CPU?

I am running Matlab on different mobile Intel CPUs with different number of physical cores. I intend to compare execution speed of my scripts (numerical calculations, Curve Fitting Toolbox only). All laptops run under Windows 10, with 32GB RAM (DDR4), SSD HD and are fitted with the following CPU models:

• CPU1: i7-7600U, 2 cores / 4 threads (2 physical + 2 logical cores),
• CPU2: i7-6700HQ, 4 cores / 8 threads (4 physical + 4 logical cores),
• CPU3: i7-9850H, 6 cores / 12 threads (6 physical + 6 logical cores),

I have observed that Malab is not using all physical cores (NOT logical ones!), but its behaviour is different on these CPUs:

• CPU1: all 4 threads with +/- equal load, total load ~50% (which is clear - physical and logical cores share the same CPU resources)
• CPU2: all 8 threads with +/- equal load, total load ~50%
• CPU3: one (physical?) core with almost 100% load and the rest with minimal load, total load < 20%

Multithreading & co options are enabled in BIOS in all laptops.

I had hoped to speedup execution with the 6/12 core CPU, but so far I have not seen any significant "boost" effect.

Is there any reason behind this phenomenon / asymmetry? Could the thread distribution onto multiple cores depend on the Windows version (all three the same), Matlab version (I haven't noticed any significant difference between 2023a / 2024a / 2024b), or on CPU itselt?

Would switching to an 8/16 AMD Ryzen CPU, or an Intel CPU (with "clever" balance between P/E cores) improve performance?

By the way, I do understand that Matlab cannot (easily) use all available cores if code (script) cannot be parallelised (e.g. while loop) and has to be executed sequentially. However, why can the same code make all cores (apparently) "busy" on a 2+2 CPU, but not on a CPU with more physical cores?

Thank you in advance!

Answer 1

[Harald]

Hi,

it sounds that your code can only benefit from "built-in multithreading" as described here: https://www.mathworks.com/discovery/matlab-multicore.html

If your goal is to efficiently use multiple cores for curve fitting, I would recommend looking into parallel gradient evaluation. A number of solvers in Optimization Toolbox and Global Optimization Toolbox let you set UseParallel to true via optimoptions.

It would be great if you could share more details about your problem (number of parameters, type of model you try to fit), ideally some reproducible code.

Best wishes,

Harald

[Marek]

Hi Harald,

Thank you very much for your reply. The described CPU behaviour seems now to be "logical" to me. My code cannot run on more than one core in parallel, as it needs to be executed sequentialy. I will follow your suggestions, but I believe my code can be split into sub-tasks, which can be executed independently of each other. In particular the main part of the (curve fitting) code, after some initialisation part, consists of a "for" loop, which cycles through selected curves, processing them one by one, indepenedently of each other. There are a few variables, which are common to the fiting results, but I can easily assign them to individual curves and thus make independent.

I guess this fits very well to the "parfit" scenario. Execution of the inner loop code could be then delegated to individual "workers".

My observation of overall performance, varying with the number of physical CPU cores, could be possibly attributed to the differences in individual single-core performance of the CPUs used, rather than to the number of cores.

Thank you for your support.

Best regards

Marek

[Harald]

Hi Marek,

if you are fitting multiple curves in an automated manner (and are not somehow using results of one fit for another, e.g., as starting values), this could be nicely parallelized and may well be a better choice than the UseParallel I initially suggested.

If your code involves somewhat large matrices, it is very possible that multiple cores are already used. This may however not be as efficient as an explicit parallelization, e.g. using parfor.

MathWorks offers a training course Accelerating and Parallelizing MATLAB Code which you may find interesting. I will lead the next session of it (March 13-14 in German).

Best wishes,

Harald

[Marek]

Hi Harald,

"parfor" approach ist not easy and is still work-in-progress.

As an intermediate solution we have implemented kind of a workaround: subdivided the set of all curves into smaller groups and run multiple instances of Matlab, each processing different group of curves. This seems to work well, the CPU (Intel) usage is pushed and more cores are involved in processing.

This implementation rises the following question:

Intel CPUs are equipped with (unequal) P and E cores. AMD CPUs contain P-cores only. Let's say we are running 8 ML instances in parallel. Which scenario shall be (possibly) more efficient, in case of intensive numerical calculations, when running the code on:

AMD with 8P cores, or

Intel with 6P + 4E cores?

There are always other OS activities, which "steal" CPU time. In AMD case cores would need to share their load with other OS activities. in Intel case 6 ML instances could (theoretically) run at full speed on P-cores, two remaining ML instances on E-cores and there would be 2 E-cores available to other tasks.

Is there any "golden rule", or a recommended "rule of thumb" for optimising the number of instances (or workers - in case of true parallel execution with the Toolbox), given a particular number of cores (P resp. P+E) available?

By the way: does Matlab provide any tool for assigning "workers" to either P or E Intel core, or is it random, resp. dispatched through the OS?

Best regards, Marek

[Harald]

Hi Marek,

if you have managed to do the subdividing, parfor (or parfeval) should be feasible and would have the benefit of being able to process the results in an automated way.

The question of P and E cores is a different one, and I can't say too much about that. You may find this and other answers on the topic helpful:

https://www.mathworks.com/matlabcentral/answers/2062522-how-does-parallel-computing-toolbox-handle-performance-and-efficiency-core-usage

If the answers you find that way are not sufficient, I recommend asking a new question.

Best wishes,

Harald