While I agree in principle, there's a couple gotchas that make me think Apple realized that they don't need to be so aggressive on the efficiency cores:
- Only threads/queues of "background" QoS currently get assigned to the E cores. While the docs suggest “utility” threads/queues could get put on either, there’s not really good evidence that’s the case yet. Everything that is user-initiated or user-interactive will always run on a performance core. An app will never be handling user input on an E core.
- Tasks at this QoS level aren’t exactly time dependent. Does it really matter if a background e-mail fetch or spotlight indexing takes a second or two longer? If I do halve the throughput of the E cores, it just means these sort of things might take a little longer. But considering my M1 mini sits with these cores at ~10% load each, two E cores can handle the load just fine.
Here’s the crux of it: macOS doesn’t use the E cores for user work. It uses the E cores to get system tasks out of the way of user work. So at the end of the day, even on the M1, the power benefits don’t come from putting user work on those cores. 3rd party apps can take advantage of this by marking their work with QoS levels, meaning that things like a background “DB cleanup“ in an app like Lightroom is kept out of the way of the things a user opened Lightroom to do.
What this does is let the performance cores “race to sleep” without as many small tasks keeping them awake to handle the growing myriad of things that need attention for the system. It also means there are fewer context switches on the performance cores away from user-initiated work, meaning less overhead to get them done, further improving “race to sleep” and responsiveness of the system as a whole.
When people talk about how snappy the M1 is, I’m suspecting this QoS management is a major contributor to that experience.
On iOS there are APIs for background processing, handing off data fetching to the OS, and more. There’s more opportunities for iOS to mark things as background and be more aggressive about keeping stuff off the performance cores that are available, so there’s very likely a larger benefit for 4 E cores on the iPhone and iPad. On macOS though, the benefit is more limited, but the M1 is fundamentally an iPad chip in origin, and carries the 4 E cores because the iPad Pro needed them and they knew the M1 was going to be used for it, or because they simply wanted to focus on the changes required to bootstrap Apple Silicon on the Mac in the first iteration and dropping to 2 E cores is the result of the data collected from M1.
