Since the first Intel Macs fifteen years ago, every new Mac has come with at least two processor cores,* and Apple has actively encouraged all developers to write their software to take advantage of all the cores that it can. As Apple replaces Intel models with two or more identical cores, with its M1 SoC containing eight cores of two different types, what does this mean for the user?

Apart from the sheer number of cores in the M1, an important difference is that half of them are designed to deliver high performance, and the rest are primarily aimed at efficiency, in terms of power usage and heat production. These are known respectively as Firestorm and Icestorm. According to Apple, the Icestorm cores use about a tenth of the power used by Firestorm cores. When you’re running on battery, that should be a huge difference, but what does it mean in practice?

If you keep Activity Monitor open and an eye on core activity, you’ll be aware that Intel cores are often used asymmetrically, but because they all share the same specification, it makes no real difference. An M1 behaves quite differently. I happened to watch both architectures at work recently when rebuilding Spotlight indexes, a prime task to be run in the background.

The eight real cores in this iMac Pro shared the indexing task fairly evenly.

But on an M1 Mac the burden was taken by the four high-efficiency Icestorm cores alone, with hardly any involvement of the high-performance Firestorm cores.

That’s all very well for Apple’s own software, but what about third party products?

That depends on how they handle their processes, and set their Quality of Service (QoS), which determines the priority they’re given by macOS. With identical cores on Intel systems, there hasn’t been much advantage to be gained there. If an app runs processes at lower QoS, other apps are likely to take priority if they expect a higher QoS; when there’s no such competition, there’s little benefit either.

To assess how this might play out with an app which can already be distributed into as many as eight processes, each running on a separate core, I’ve updated my compression-decompression utility Cormorant to work with different QoS levels.

Running on an Intel 8-core Xeon W, compressing a Big Sur full installer typically takes 23.3 seconds when the QoS is userInteractive, the highest. Dropping the QoS to background extends the time taken for that task to 26.0 seconds. Core use is fairly even, with the app’s processes busy on each of the eight cores. These are shown in order in the following two screenshots, in which I’ve repeated the same compression task three times in rapid succession.

When the QoS is userInteractive on an M1, Cormorant uses all eight cores to out-perform the eight cores in the Intel Xeon, compressing my test files in just 14.1 seconds, that’s 60% of the time of the Intel processor. As shown in the chart below, much of this is accomplished by the four performance cores.

When the QoS is set at background, compression takes a lot longer: 101.1 seconds, over four times slower than the Xeon. But, like Spotlight re-indexing, this is confined to the Icestorm efficiency cores.

This demonstrates the programmer’s dilemma: when performing tasks which can take some time, do you opt for speed at any cost, or make the user wait while the task is completed with lower power consumption and impact on other processes? Usually it isn’t difficult to let the user make that choice, as I have done in this new version of Cormorant. When you’re in no hurry but would rather eke out the most of your MacBook Air/Pro’s battery, put your compression and decompression tasks into the background. When that’s the task that is holding you up, uncheck the box and run with a QoS of userInteractive. But it’s only on the asymmetric cores of the M1 that you can realise those benefits.

If you’re looking for even more persuasive evidence of the value of asymmetric cores in your processor, look at Intel, which has announced its Alder Lake processors for the latter half of this year. They are promised to have high-performance Golden Cove and high-efficiency Gracemont cores. By the time that we start seeing them in retail computers, Apple will have moved on to its next generation, successor to the M1.

Cormorant version 1.2 is now available from here: cormorant12
from Downloads above, from its Product Page, and through its auto-update mechanism. Have fun!

* thanks to josehill who has pointed out below that between February and September 2006, Apple did ship one version of the Mac mini (Early 2006) with an Intel Core Solo processor, which had just one core. I think that was the first and last, and since then every new Mac model has had at least two cores.