Without peeping, when’s the last time that your Mac backed up, and how long did it take? I ask because backups are a prime example of the many dozens of background tasks undertaken by macOS. Although there was a time not long ago when those backups were only too obvious – the muffled rattle of a hard disk, occasional brief pauses in the human interface – most of what macOS does behind our backs is now almost imperceptible.
This is subjectively even more true with M1 Macs. The only real way to get any sense of what’s going on in the background there is to watch the CPU History in Activity Monitor. What you’ll see is startlingly different from anything you’ll observe on an Intel Mac. The top four Efficiency cores are busy pretty well all the time, while the bottom four Performance cores only cut in when you do something in an app you’re using. In effect, macOS is running on the Efficiency, or Icestorm, cores, and your apps then get the lion’s share of the Performance, or Firestorm, cores.
This is what’s termed Asymmetric Multiprocessing, or AMP, and Apple’s M1 Macs are probably the first mass-market computers to ship with it as standard. Although Apple’s iOS and iPadOS devices also have asymmetric cores, their approach to multiprocessing is more constrained in comparison to that in Macs.
AMP is also one of the most controversial features of the M1 chip. Many commentators consider it valuable for mobile systems, including the MacBook Air and MacBook Pro, where it can result in both power economy, hence prolonging endurance when running on the battery, and lower heat production, allowing laptops to run without power-consuming and noisy fans. But opinions are more divided when it comes to the use of AMP within desktop computer systems, like the iMac and Mac mini.
Last week I featured two articles which I hope contribute to this debate.
The first was about uninterruptible power supplies (UPS), an essential companion for every desktop computer, not a topic you normally associate with AMP. But UPS are relatively expensive peripherals, which rapidly become more costly as their capacity and power delivery rises. Currently Apple offers two fairly similar Mac mini models: an Intel version, which consumes almost 20 W when idle and 122 W maximum, and an M1 version, which idles at 6.8 W and maxes out at just under 40 W.
Ignoring for the sake of comparison the requirements of any external display, there’s a substantial difference between the cost of a UPS for them. Using APC UPS as an example, for around £/$/€ 100, I can get a 410 W UPS which will use only 10% of its battery capacity to run my M1 Mac mini for just under an hour at maximum power consumption. The equivalent UPS to do the same for an Intel Mac mini is a 1200 W unit costing £/$/€ 275.
If I wanted to mount multiple Mac minis in a rack for a server farm, the lower heat production of the M1 version makes that an easy task compared to working out how to cool an array of Intel models.
Moving to an even bigger picture, the destruction wreaked last week by Hurricane Ida should surely have reminded us all of the need to stop damaging the climate of our planet. It’s all very well pointing the finger at others, but if we don’t do all that we can, we’ll all suffer as a result of our profligacy. One significant step in that direction is to cut the power consumption and heat production of our computers. The threefold reduction in moving from an Intel Mac mini to an M1 is surely exactly the sort of measure which can be amplified across tens of millions of computers around the world.
The second article was a more technical look at the performance of the M1’s asymmetric cores. While Apple has been quite happy to run all the background processes in macOS on the Icestorm cores in the M1, third-party developers appear more reluctant to try to take advantage of them, and some seem to be hoping that the M1’s successor will reduce the number of Efficiency cores, if not do away with them altogether and adopt Symmetric Multiprocessing (SMP).
One prime candidate for the use of Icestorm cores is backing up, as already demonstrated by Apple with Time Machine. A recent feature added to Carbon Copy Cloner (CCC) now allows you to adjust the CPU priority of its file copier, which seems a promising start, except that this control is tucked away in the Advanced Settings of individual backup tasks, can’t be set globally, and (most telling of all) defaults to the fastest of the three levels on offer. I must confess here that, although my two daily CCC backup scripts run in the small hours of the morning, I haven’t changed those settings in either of them, although for the moment, as they run on an 8-core Intel Xeon W, I’m not sure whether changing them would be of any significant benefit.
One of the main reasons, I think, for the reluctance among developers to run tasks on the Efficiency cores is the fear of poor performance. If they only use around a tenth of the power of the Performance cores, surely they’re going to be ten times as slow? It turns out that, for some tasks at least, you can get around half the performance of the Firestorm. Choose the tasks wisely and test carefully, and using the Icestorms can make great sense. Porting your app to Apple Silicon is also about using its features optimally, which should include running those tasks whose performance isn’t critical at the lowest QoS level so that they are assigned to the Efficiency cores.
We naturally want all our code to run as quickly as possible. But offloading background tasks to Icestorms frees the Firestorms to run performance-critical code faster. It would also be good to think that all those busy Icestorms might stave off hurricanes.