7 ms·
Amazing article, here's the synopsis at the bottom of the article: Summary of findings and conclusions drawn * macOS 12.1 manages the four E cores in the orig
by gigatexal 5y ago
Amazing article, here's the synopsis at the bottom of the article:
Summary of findings and conclusions drawn
* macOS 12.1 manages the four E cores in the original M1 chip, and the two in the new M1 Pro, differently.
* In response to a high load of low QoS processes, frequency of E cores in the original M1 chip remains about 1000 MHz.
In response to a high load of low QoS processes, frequency of E cores in the M1 Pro is doubled to about 2000 MHz.
* This management policy ensures that demanding background processes with low QoS can complete in similar times on the original M1 and M1 Pro chips. Had M1 Pro chips followed the same policy as the original M1, those processes could have taken twice as long.
* In response to a spillover load of high QoS processes from the P cores, frequency of E cores in the M1 Pro is increased to the maximum of 2064 MHz.
When running at 100% active residency and maximum frequency, the cluster of 2 E cores in the M1 Pro consumes 210 mW of power.
* When running at 100% active residency and maximum frequency, each cluster of 4 P cores in the M1 Pro consumes 4 W of power.
* Although there’s insufficient evidence here to conclude that all cores within a cluster are run at exactly the same frequency, their frequencies don’t appear to differ by much. Within a cluster, active residencies normally remain broadly similar but aren’t as closely correlated as frequencies.
In tight loops of predominantly floating-point code, accessing only registers as used here, performance measured by timing correlates closely with that measured by powermetrics as instructions retired.
* The two E cores in an M1 Pro, when at 100% active residency and maximum frequency can outperform a single P core at 100% active residency and maximum frequency, while using one fifth of the power.
- NL807 5y ago4 W of power is nuts. Less than most LED light bulbs we have in the house.
- gigatexal 5y agoImagine a laptop that was just E-Cores but 1.5x the IPC, a la some future M-revision but with defects where they only shipped it with say 8 E-Cores ... that'd be perfect for me and even better if it was in the 12-inch MacBook form factor just with an edge-to-edge screen.
- marcan_42 5y agoAnd the entire M1 SoC uses about 100 mW with the OS ~idle, screen on, writing this HN comment: ANE Power: 0 mW DRAM Power: 32 mW CPU Power: 85 mW GPU Power: 18 mW Package Power: 103 mW I've left an M1 Air powered on, screen off, WiFi connected, SSH session active and running a shell loop printing the date every minute from another machine. After 3 hours, the battery was still at 100%, and the system finally went to sleep and killed the session. Waking it up, after another 3 hours, it had dropped to 98%. That is how you do power management.
- gigatexal 5y agomarcan eh? are you by chance https://twitter.com/marcan42 https://twitter.com/marcan42 ;-)? I can not wait for proper linux -- installable by a noob like me on an m1 -- to be available. Thank you for the 100x time again for your efforts here
- marcan_42 5y agoYes, that's me :-) Easily installable Linux shouldn't take much longer, for those adventurous enough to be happy with a bunch of missing hardware support (but still a usable machine for a subset of use cases). We're pretty much tying up loose ends to get to that point now, I have a quickly shrinking list of TODOs. Of course, "proper" support for everything will take longer :-)
- Aeolos 5y agoIs there something we can do to help, short off diving into reverse engineering?
- marcan_42 5y agoReverse engineering isn't that scary! Seriously though, a big part of my role in the first year has been building tooling to make that part of the process efficient and enjoyable for everyone. We have a Python REPL for interacting with the bare metal hardware, scaffolding for building prototypes of hardware drivers in it (e.g. register and register map definitions), things like the ability to run functions on another CPU core for SMP tests, hardware exception handling so it's actually hard to crash and have to reboot, and even a hypervisor that can run full macOS and inspect all of its hardware accesses, with a rich event tracing framework that goes from raw register maps to coprocessor message passing to decoding remote procedure calls with C++ argument unmarshaling between firmware and the OS, in both directions. All controlled from any host machine running Linux or macOS, over a simple USB connection with the target.