I'd add proper thread and process management to the list of things that Apple does well (and Microsoft/Intel doesn't). This is something that is not captured by most benchmarks (as they are run at full power on all threads, which shouldn't be too difficult to schedule), but it's noticeable in normal use.
Apple’s QoS system is well suited for this particular goal. Add in GCD which makes thread pools easier to manage than anything I did in .NET land ages ago (keep in mind it was in the .NET 4 era) and it’s not hard for a developer to mark their work appropriately for the system. The new Swift concurrency system seems to be taking this system and making it even more performant by addressing weaknesses in current thread pool designs, while also taking notes on what worked well.
Yes! It's almost unbelievable that Apple shipped GCD in 2009. It's made the transition to heterogeneous cores much simpler than on other platforms.
I haven't looked that much into Swift concurrency yet, as it's been iOS 15-only (until very recently) and at work we are required to support at least two major iOS versions, so I don't know the impact it has in multithread performance. My impression from what I saw at the WWDC was that it made multithreaded code much easier to write. This may compel software companies to start refactoring monolithic single-threaded code to offload some work to other threads. This was already technically possible, but by making it much easier to write, it may cause developers to actually do it, which I think was the ultimate goal of the whole concurrency feature.
I wonder how big of an effect the naming scheme of Apple's QoS had in this. While I haven't really written many multiplatform simulations, I believe the alternatives would be using OpenMP (where you can't set a priority as far as I can tell) or POSIX threads. The API to get the min/max values of pthread priorities seems to rely on calling sched_get_priority_max(), so I think it'd be far more common to carelessly set a thread priority to max using the value returned by that function than setting a GCD queue priority to .userInteractive, since the semantics are much more clear. You wouldn't explicitly set a queue priority to .userInteractive for anything that wasn't actually user-interactive, it just looks wrong. But setting a pthread priority to the maximum value doesn't 'look' wrong.
This is actually a great point. Names in interfaces are important! Heck, names in code are important. Whenever I write some RTL, I try to do a variable name revision pass right after I first get it working. This isn't just about making the code clear for future maintainers, it also gets present-me to rethink stuff I just did. The act of changing names to be more meaningful often leads me to bugfixes and even substantial optimizations.
Interesting. I have a side project where I'm learning to use async/await, but I'm only using it for the network calls, I still plan to manage everything else using GCD queues. So far it hasn't made the code as good looking as in the WWDC sample videos, I haven't found a way around wrapping a lot of it in Task {...} and DispatchQueue.main.async{...} blocks. Where I think it would immensely simplify the code is in the project I develop at work (iOS app for a major fashion brand). The whole project is littered with completion handlers everywhere and sometimes it's very difficult to follow the control flow of the app. Async/await would make everything much more readable.
That's a very good point. Hadn't thought of it that way.
Noob question, but could it be that their efficiency is maximized at their 100% load? So they are designed to run 100% all the time for the ubiquitous tasks that keep the system “alive”?
Hm. If there's spillover to the P-cores.
You have to be careful about measuring this - under low loads I've seen CPU cores reported at high utilization just because Apple's power control loops aren't detecting enough demand to ramp frequencies up all the way.
This inspired me to enable the CPU History window on my M1 Mini. So far, it has been rare for the four E-cores to be utilized more than 50%.
Me too, but with only one screen, I needed to set it so it's not always on top. I'm mostly just using the efficiency cores.
I don’t think it’s an area issue. Those things are tiny. About the same size as the extra neural stuff that isn’t even used.I've also wondered why they chose to drop to two E cores. It seems like there's often enough work for them to do, they're so profoundly efficient compared to P cores, and they're so tiny.
The topic comes up at about 24:25 in this interview with Tim Millet and Tom Boger (Apple VPs), and they mention something interesting:
Upgrade #379: They Feed on Memory Bandwidth - Relay FM
We're joined by Apple VPs Tom Boger and Tim Millet to discuss Apple's chip-design philosophy and how it factored into the company's first high-end Mac chips, the M1 Pro and M1 Max.www.relay.fm
According to Tim, the top end of the E core's perf/Watt curve (max performance and power) has some overlap with the bottom end of the P core's curve, so spilling some "E" type tasks to P cores isn't so bad. (unstated: as long as the P core stays at the bottom end of its clock range!)
I don't think this is the whole story. Everyone Apple sends out to do post-launch interviews has clearly been put through a lot of interview prep; they're very slick about funneling the conversation towards positive things which promote the product while avoiding saying anything in negative terms. But this does help explain why E cores ended up on the chopping block. Perhaps there was a desperate need to reclaim a bit of area because some other block was over budget and they didn't want to grow the total die size. It's simple triage at that point: find something which users won't miss a lot, and remove it.
I'd still rather have four E cores and a (very) slightly larger die. They're cool! Literally and figuratively.
