I’ve never understood how engineers coped with the switch to email. So many engineering calculations in the past were accomplished on the backs of envelopes that I can’t imagine how they can cope with the loss of that fertile medium. One envelope I’d love to see is that from Apple’s M1 design team in which they decided the numbers of Firestorm and Icestorm cores. For, despite Apple having longer and greater experience of designing chips containing multiple types of CPU core, its M1 series chips are the first to be used in quantity for general purpose computing.

Let me repeat that: Apple’s M1 chips are the first such asymmetric design to be used in quantity for general purpose computing. That’s quite a milestone.

There’s some debate over whether M1 chips actually use asymmetric multiprocessing (AMP), or whether this should instead be termed heterogeneous computing. Apple prefers the former, but terminology shouldn’t obscure this milestone. Two of its most interesting questions are how Apple chose the number of cores for its first two M1 chips, and how macOS uses them. I suspect the answer to the first question is inspired guesswork, the truth behind the backs of many envelopes, and it’s the second I dwell on here.

Rather than requiring every process to express its preference for the core type it should be run on, Apple uses a more opaque system based on Quality of Service (QoS). For user processes, this comes in four levels, of which only one constrains threads to be run exclusively on the Efficiency (E) cores; for the other three, threads can be allocated to either Performance (P) or E cores, with a preference for the former.

Outside the process, there is also very limited control over which cores get which threads. One command, taskpolicy, and one API call, setpriority(), can demote processes so that their threads are confined to E cores, but there doesn’t appear to be any way to promote those already constrained to E cores so that they can enjoy a bite of the P core cherries.

General purpose computing on Macs is remarkably diverse. You’ll find Macs working in almost every role you could expect computers to work in, as servers, graphics workstations, hosting large databases, rendering movies, playing games, streaming media, and more. For some systems, Apple’s limited control over allocation to core types works very well, but for others it doesn’t. Not only that, there are times when users want to override what macOS sets for them.

One obvious example is performing the first Time Machine backup, a task which often takes more than an hour even when backups are stored on relatively fast disks. Most users want to get that backup out of the way as quickly as possible, but macOS decides for them that I/O will be throttled, and backupd’s threads will be run exclusively on E cores. Those are excellent choices for later, hourly backups, but far from ideal on the first occasion, but there’s no manual override available.

The defence is that the P cores are dedicated primarily to user interactive tasks, which is good for those circumstances in which the user decides to continue using their apps during that first backup. But if the user chooses to leave their Mac to get on with it, macOS will happily throttle I/O and run two E cores flat out while eight P cores sit idle for a couple of hours. That’s not being responsive.

An alternative approach, adopted by Asahi Linux, for example, is to leave the developer and user to determine which core types each process is run on. While that makes sense in Linux, I doubt that many Mac users would want to do that, and it risks unwise users making bad choices.

As Apple’s engineers move past this remarkable milestone, they must also be planning where to go next in terms of thread allocation. Most of the tools are already there, in the form of QoS, Grand Central Dispatch, and most recently RunningBoard and its associates. What users need is more flexible and sophisticated core allocation which responds to changes in core load, and gives the user options. At the moment, those options consist of just a brake, which isn’t a good way to control any device apart from a toboggan.

While many like to speculate on how many E and P cores we’ll see in Apple’s next chips, we should perhaps be paying more attention to all the envelopes that are evolving more advanced core allocation systems, which are likely to play a greater part in the Mac’s present and future.