What triggers the Performance cores in M1 Max?

[Killerbob]

So I started looking at the CPU Core usage on my Mac Studio, and I am trying to gauge what uses the two Efficiency cores, and what uses the eight Performance cores?

Sitting right now with just Outlook, Music and Chrome running, the two Efficiency cores seem to be doing most of the work. Two of the Efficiency cores are doing a tiny amount of work, and the rest six Performance cores are doing nothing at all.

If I then start up Adobe Lightroom Classic, at least two of the Performace cores get busy, and another two start doing a bit. Four of the Performance cores are still not doing anything at all.

Even starting up Adobe Photoshop with a bunch of RAW images, Photomatix HDRing 9 of these, and FaceTime, still only awaken the rest of the Performance cores, but four of them barely register any activity other than starting up the applications, and then of course when I start doing some work - but still very little activity on these Performance cores.

What the heck does it take to put some pressure on this machine? I love it... On my 2013 Mac Pro, I would start seeing a slowdown at this point, and my 2019 Mac Pro would (perhaps) start spinning up its fans (my 2019 MP is all set up for video - it is a workhorse).

 

[ponzicoinbro]

Render something directly on CPU that doesn’t use the video encoders or GPU.

 

[Killerbob]

Fair enough, but that is an artificial way, as I would always utilize the GPU cores for that work, as they are better and faster at it.

 

[T'hain Esh Kelch]

Apps don't automagically use all cores. Software has to be written to support multithreading or multitasking so it can distribute the task across multiple cores, and depending on the software, that may not be possible.

A good test is video encoding, as that always uses up all the available cores you have, as they can work individually on each frame.

 

[ponzicoinbro]

Fair enough, but that is an artificial way, as I would always utilize the GPU cores for that work, as they are better and faster at it.

Not an artificial way. If apps were stressing all CPU cores during normal operations that would be horribly inefficient programming and app development. You only need to stress all cores or even a few cores for certain tasks.

The primary benefit of multicore processors is multitasking the apps and background processes. There are a lot of threads that have to be distributed across the CPU cores. Even just modern web browsing needs threads to be well distributed.

If a system is running nice and zippy and you don’t see the cores being maxed out that means the system is making great use of resources.

 

[Killerbob]

I see the two Efficiency cores busy, but not the eight Performance cores - and I wonder if it wouldn't be better if the more mundane applications also took advantage of the Performance cores, and not just the "heavier" applications.

 

[F-Train]

Arguably the biggest issue about the Silicon Macs is that developers have not yet caught up with their potential. As @T'hain Esh Kelch says above, "Software has to be written to support multithreading or multitasking so it can distribute the task across multiple cores". This issue probably underlies complaints about Ultra performance.

 

[OcelotWreak]

Unless the software is specifically written to make use of the CPU/GPU cores, you aren't going to see any impressive iStat charts showing your system humping all the available resources (which as noted above can be perfectly normal). Even then, simply adding more cores does not scale your results as expected. An exception I did note elsewhere (sorry - can't find author's name to give proper credit) one Studio Ultra user who was doing Fluid Dynamics simulations and saw totally jaw-dropping performance gains over previous Mac hardware options. See:

 

[Killerbob]

I found an application that absolutely takes advantage of all the cores in the M1 Max... Handbrake...

Run Handbrake converting video files, and all cores are maxed in the most beautiful way. The two Efficiency cores take care of all the other stuff, and the eight Performance cores are all focused on handling Handbrake.

Assuming that is good, all Performance cores were filled up with Green and very little Red, and the two Efficiency cores were just busy with Music, Chrome, Outlook, and macOS.

 

[Feek]

Handbrake

Ho, yah.

 

[Killerbob]

Actually the Adobe applications are pretty good as well, and combining RAW files in LightRoom will use all the cores as well.

 

[Krevnik]

I see the two Efficiency cores busy, but not the eight Performance cores - and I wonder if it wouldn't be better if the more mundane applications also took advantage of the Performance cores, and not just the "heavier" applications.

Not really. Everything you see on the efficiency cores are background tasks that don't need to complete on a specific timeframe. Spotlight indexing being an example of one of these tasks. Because they are always there, having a couple low-power cores gets efficiency by letting the performance cores rest when the user isn't actively using the machine to do work.

For something to run on the efficiency cores, one of two things has to be true:

1) The priority of the work is the lowest priority that a developer can set (background).
2) The performance cores are full, and even more work needs to be done.

For any sort of user-interactive thread (such as the main thread in nearly any app that isn't a background service), it's going to run on the performance cores. The default thread priority also runs on performance cores. Even if the performance cores are full, user-interactive threads will get priority on the performance cores to keep them responsive.

Unlike Intel's approach, Apple doesn't move threads between the two types of cores trying to get efficiency that way. The performance cores are already efficient. Even on iOS, the efficiency cores are there to support background tasks and threads to ensure that the foreground app can effectively be the only thing on the performance cores.

 

[chengengaun]

The priority of the work is the lowest priority that a developer can set (background).

Not sure if the following command still works to remove priority limitations, I used to run this when I want to speed up Time Machine backups:

sudo sysctl debug.lowpri_throttle_enabled=0

...then =1 when the backup is completed.

Separately, when I run parallel processing using R/Python on the M1 Max, I usually set the number of cores to 8. I don't think I can specify which cores to use, but so far all the jobs were run using performance cores.

 

[leman]

I see the two Efficiency cores busy, but not the eight Performance cores - and I wonder if it wouldn't be better if the more mundane applications also took advantage of the Performance cores, and not just the "heavier" applications.

“Better” for what? And I assure you that apps do use performance cores, it’s just that the basic priority stuff like UI rendering is done so quickly that it doesn’t register on activity monitor.

In other words, basic software operation only needs to do X amount of work and spends the rest of its time waiting for the user input. For most apps, the X is very small related to the time spent waiting.

 

[Krevnik]

Not sure if the following command still works to remove priority limitations, I used to run this when I want to speed up Time Machine backups:

sudo sysctl debug.lowpri_throttle_enabled=0

...then =1 when the backup is completed.

It depends on what that does. But if it changes the thread/task priority, it would move it off the efficiency cores (as I suggested). There's probably some throttling related to disk I/O in the case of Time Machine, but it's nothing something I've explored much.

Separately, when I run parallel processing using R/Python on the M1 Max, I usually set the number of cores to 8. I don't think I can specify which cores to use, but so far all the jobs were run using performance cores.

Developers can't specify which cores to use, just the priority. But the kernel does use the priority to pick what type of core to run the work on. As I've stated, the default priority level does not use the efficiency cores.

 

[Killerbob]

Not triggering Performance cores, but rather the Efficiency cores is the screen saver.

Whenever I check Performance Monitor right after the screen saver has been running, the two Efficiency cores were both maxed out for the entire time the screen saver was running.

 

[jdb8167]

Developers can't specify which cores to use, just the priority. But the kernel does use the priority to pick what type of core to run the work on. As I've stated, the default priority level does not use the efficiency cores.

I believe that the scheduler will use efficiency cores if all of the performance cores are currently in use. But in general, you are correct. The Apple silicon scheduler has 4 options (Quality of Service or QoS) for priority, background, utility, userInitiated, and userInteractive. Only background forces tasks to the efficiency cores. The others will use efficiency or performance cores as needed with utility favoring efficiency cores and the user QoS levels tending towards forcing tasks to the performance cores.

 

[darngooddesign]

I see the two Efficiency cores busy, but not the eight Performance cores - and I wonder if it wouldn't be better if the more mundane applications also took advantage of the Performance cores, and not just the "heavier" applications.

No one is going to write a MacStudio-specific app so that would be worse for people with MacBooks.

 

[satcomer]

No one is going to write a MacStudio-specific app so that would be worse for people with MacBooks.

Most audio makers haven't updated for the M1/m2 era tells me they have abandon Mac users! Right now for lie music at least Pro Tools is Universal now! Also Abelton Live is Universal too! Then of course Apple's Logic Pro X is also Universal!

Also Loopback is universal to and soon will only silicon one the Mac Pro goes away or is replaced!

 

[jdb8167]

No one is going to write a MacStudio-specific app so that would be worse for people with MacBooks.

It’s really mostly automatic. You can’t target particular cores. You just set the QoS and the scheduler figures out the rest. The front window gets userInteractive and anything else that needs performance is set to userInitiated.

 

[Krevnik]

I believe that the scheduler will use efficiency cores if all of the performance cores are currently in use. But in general, you are correct.

If you check my original post, I do mention this bit.

The others will use efficiency or performance cores as needed with utility favoring efficiency cores and the user QoS levels tending towards forcing tasks to the performance cores.

I haven't seen this behavior in practice. is there an example of utility favoring efficiency cores without manipulating the process using something like the taskpolicy tool? And my understanding from reading the XNU code is that high QoS levels wind up on the efficiency cores only if the performance cores are all full (via work stealing mechanisms and the like). And this carries forward to CPUs with more than one performance cluster. The first cluster fills first before the second cluster gets used so the second cluster can remain powered down if the work being done doesn't need it.

For folks who do want an explanation that isn't over-simplified, but can be a bit dense for non-developers, eclecticlight has a good in-depth detail on the scheduler: https://eclecticlight.co/2022/04/25/how-macos-manages-m1-cpu-cores/

 

[jdb8167]

If you check my original post, I do mention this bit.



I haven't seen this behavior in practice. is there an example of utility favoring efficiency cores without manipulating the process using something like the taskpolicy tool? And my understanding from reading the XNU code is that high QoS levels wind up on the efficiency cores only if the performance cores are all full (via work stealing mechanisms and the like). And this carries forward to CPUs with more than one performance cluster. The first cluster fills first before the second cluster gets used so the second cluster can remain powered down if the work being done doesn't need it.

For folks who do want an explanation that isn't over-simplified, but can be a bit dense for non-developers, eclecticlight has a good in-depth detail on the scheduler: https://eclecticlight.co/2022/04/25/how-macos-manages-m1-cpu-cores/

I was paraphrasing what that article explains in more detail. The utility QoS level will get dumped to efficiency cores first before the user activity levels if I understand correctly.

 

[satcomer]

Sense it's automatic then the application most usually has to be pure silicon!

 

[Krevnik]

I was paraphrasing what that article explains in more detail. The utility QoS level will get dumped to efficiency cores first before the user activity levels if I understand correctly.

Sort of? That's a likely side-effect of what's going on in enough cases, but it depends a lot on the load and isn't part of the scheduler's design. Priority once you get above background QoS operates much as it does with a SMP scheduler. Just that it is aware that there are multiple clusters, there are costs involved with moving threads between clusters, and that the clusters have a preferred order, where E clusters are always at the end of the list and least preferred.

But what you originally said was that utility favors efficiency cores, which I don't see how it does and what I was taking issue with.

 

[jdb8167]

Sort of? That's a likely side-effect of what's going on in enough cases, but it depends a lot on the load and isn't part of the scheduler's design. Priority once you get above background QoS operates much as it does with a SMP scheduler. Just that it is aware that there are multiple clusters, there are costs involved with moving threads between clusters, and that the clusters have a preferred order, where E clusters are always at the end of the list and least preferred.

But what you originally said was that utility favors efficiency cores, which I don't see how it does and what I was taking issue with.

I'm making assumptions. Probably a bad idea when I could go read the code. But slogging through a bunch os scheduler code would take a pretty major effort.

Thanks for the info. It's not clear what the levels beyond background and user are doing. Any insight on why Apple has 4 QoS levels? It seems weird that the scheduler doesn't make any use of them beyond sending threads to either efficiency cores or performance cores and waiting for high load. I don't have time this weekend but I might get a chance to look at the scheduler code next week.