What triggers the Performance cores in M1 Max?

[gradi]

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.

I have read that Lightroom Classic used to use only 1 core, but over time little by little multithreading has been added so more cores are used. Also, over time the GPU is used more.

We might note that Intel has had multi-core CPUs since 2005: Pentium D. And Intel has had hyperthreading since 2002. One might think that developers have had time to catch up with all this newfangled stuff. And multitasking (not the same thing as multithreading) has been around for many decades.

 

[gradi]

You may find these interesting and instructive.

Optimize for Apple Silicon with performance and efficiency cores

Optimize for Apple Silicon with performance and efficiency cores - Discover - Apple Developer

Recent Apple Silicon like A13 Bionic has both high-performance cores (P cores) and high-efficiency cores (E cores). These different core types allow you to deliver apps that have both great performance and great battery life. To take full advantage of their performance and efficiency, you can...

developer.apple.com

Tuning Your Code’s Performance for Apple Silicon

Tuning Your Code’s Performance for Apple Silicon | Apple Developer Documentation

Improve your code to get the best performance from both Apple silicon and Intel-based Mac computers.

developer.apple.com

 

[handheldgames]

For performance considerations - this is the document https://developer.apple.com/documen...ing-your-code-s-performance-for-apple-silicon

from apple developer - prioritizing the task is essential

Energy Efficiency Guide for Mac Apps: Prioritize Work at the Task Level

Explains how app developers can reduce energy impact on computers running OS X.

developer.apple.com

as well as energy essentials.

Energy Efficiency Guide for Mac Apps: Energy Efficiency and the User Experience

Explains how app developers can reduce energy impact on computers running OS X.

developer.apple.com

With that being said, based on the task at hand, developers can identify the appropriate type of core used.

 

[Krevnik]

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.

Sorry, I'm not super active on this forum these days, so I missed this.

QoS levels are thread priority levels, fundamentally. So the scheduler does use them for prioritizing work similar to setting a thread priority in pthreads. The new bit is that you can set priority for a block scheduled in a GCD queue, so it's a bit more granular (just be careful of priority inversions in serial queues), and that the levels have clearer semantics that suggest how they should be used by a developer. So they are easier to adopt and use than traditional thread priorities.

The QoS levels are honestly one of Apple's branding wins. They took an underused tool in the CPU scheduling toolbox they already had (and to be honest have been around since at least the 90s), and then made it something that allows iOS and macOS to properly prioritize things like scrolling and window redraw, and deprioritize things like indexing your Lightroom library and get consistent results from both 1st and 3rd party apps with surprisingly little cost to developers.

The AMP scheduler adds surprisingly little on top of this framework, but what it does do is ensure that background work like spotlight indexing happens with less battery impact, and is unlikely to have to share a core with an event loop trying to scroll a complicated view hierarchy with image decoding/etc. Much like in the old world where putting the heap and stack at opposite ends of an address range limits the chances of the two colliding.

I'm more impressed by the scheduler because of how simple it is, while achieving some good results when it comes to maintaining UI responsiveness under load. It's a case of where clever simplicity pays dividends.