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.
ARM
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…
For the great majority of Mac users, M1 series Macs are a big step forward. But some users want the impossible. What can’t M1 Macs do?
Some apps and other code doesn’t appear to run faster on M1 chips, and some even runs more slowly. Could this be a result of it not using the best acceleration for vectors and matrices?
What are the penalties in real-world use for running your code on Icestorm cores, using around 10% of the power used by Firestorms?
The Eclectic Light Company 