A first attempt to describe how macOS decides for a thread which type of core, which cluster, which core, what frequency, and how mobile it should be.
big.LITTLE
How macOS controls CPU P core cluster frequency according to the cluster total active residency, in synthetic in-core tests, compression and when running virtual machines.
Power use in two in-core performance tests, by number of threads run, leading to estimates of total energy used by P and E cores running the same code, at high frequencies. How efficient are the CPU cores in the M4?
Virtual CPU cores are of one type, and QoS has no effect in virtualised macOS. This has consequences for both the host and guest macOS.
Many apps could benefit users of Apple silicon Macs by giving them controls over core use by their threads. Here’s how that can be done simply and effectively.
How you can use the taskpolicy command to confine all the threads of a process to the E cores, as a brake, but there’s no accelerator in macOS.
How can the two E cores in an M1 Pro or Max equal performance of the four in the original M1? Why does running two threads complete in half the time taken to run one?
Threads, GCD and core allocation in Apple silicon explained. How thread priority is baked into code, and how important it is to performance.
P cores are conventional in that they can deliver excellent performance at maximum frequency, but with high power use. E cores may take 4 times as long for a task, but use less than a third of the energy.
An accessible account of how Apple silicon chips use cores of two different types to do their work, and how to get the best from them as a user. The start…
The Eclectic Light Company 