https://eclecticlight.co/2022/10/05/making-the-most-of-apple-silicon-power-2-core-capabilities/ Skip to content [eclecticlight] The Eclectic Light Company Macs, painting, and more Main navigation Menu * Downloads * M1 & M2 Macs * Mac Problems * Mac articles * Art * Macs * Painting hoakley October 5, 2022 Macs, Technology Making the most of Apple silicon power: 2 Core capabilities My first article in this series explained the history behind Apple's M-series chips, and how they use ARM's big.LITTLE architecture in heterogeneous multi-processing (HMP) with two types of CPU core. If you haven't yet watched my presentation for MacSysAdmin 2022, now is a good time to view it, so you're better prepared for the detail that follows. P cores The P cores in Apple's M1 and M2 series chips have six integer units and four floating-point/NEON units. While they use plenty of techniques such as out-of-order execution to optimise performance, as explored and documented by Dougall Johnson, Maynard Handley and others, those are well beyond the influence or control of mere users. Here I'll concentrate on features of more direct relevance to how macOS uses those cores. P cores idle at a frequency of 600 MHz, and have a maximum frequency of either 3204 MHz in the original M1 chip, or 3228 MHz in M1 Pro/Max /Ultra versions. In practice, under the management of macOS, P cores are normally run at steady frequencies of 600 or 3036 MHz and higher, but can run at intermediate frequencies when loads are changing. Once load is removed, they return almost immediately to idle frequency. Frequencies in both types of core are set by cluster, and don't differ within any given cluster. So when the first P cluster is loaded with one or more threads, macOS raises the frequency of all its four cores until those threads are complete, when they'll fall back very quickly to idle. Power measurements match frequency, with each P core typically drawing up to a maximum around 2.5 W for a cluster total of about 10 W, but using very little when idle. E cores In terms of functional units, each E core is roughly half a P core, sufficient to ensure that E cores have full support for floating-point and NEON features. This means that anything a P core can do, an E core can do too, if rather more slowly. E cores also idle at a frequency of 600 MHz, but have a maximum frequency of only 2064 MHz, which is the same across the whole M1 series of chips. macOS also controls the frequency of E cores slightly differently, in that they can be run at an intermediate frequency of 972 MHz, as well as idle and maximum. Although this might appear to be a minor detail, it turns out to be significant in their control and performance. If the relationship between performance and power were linear, you might then expect an E core to use a third of the power of a P core, thus a maximum of about 800 mW. When measured, each E core has a maximum power usage of less than half that, around 300 mW. Performance Taken together with the difference in functional units, you'd expect an E core running at maximum frequency and 100% active residency to have a throughput of about a third of a P core at its maximum frequency. In practice, running tight loops of code accessing only registers, E cores can achieve almost twice that expected, giving them nearly two thirds of the throughput of P cores. For example, a task running in two threads allocated to two P cores might complete in 32 seconds, and on two E cores in 52 seconds. Real-world task performance of E cores isn't as impressive, though. Compressing an IPSW image using two threads and two P cores takes 32 seconds, but on two E cores takes 134 seconds, for almost a quarter of the performance. Thus, whether code is allocated to the P or E cores can make a substantial difference to the time it takes to complete. Efficiency If the relationship between performance and power were linear, then there would be no efficiency benefit to running tasks more slowly on cores that used lower power. Because E cores use less power than that, substantial savings can be made by running tasks on the E cores alone, instead of P cores. One example, based again on file compression, required 10.3 J total energy when run on P cores, and only 3.1 J on the E cores, which is 30%. Thus, for this specific instance of compression, running its threads entirely on E cores takes four times as long as on P cores, but uses a total of less than a third of the energy. Core count In Apple's current designs, the number of P cores in any M1 chip is equal to or greater than the number of E cores, and in the faster chips P cores outnumber E cores 4:1. This works well when threads allocated to E cores need to be completed over a period of time, rather than at a moment in time, such as background services. Tasks the user is waiting for then need to use the greater and more immediate capacity of P cores. This is quite different from many Intel Alder Lake chips, which provide equal numbers of their core types. I/O throttling Task performance isn't just limited by core performance. A good example is making a Time Machine backup, which is heavily dependent on I/O with storage. By default, macOS throttles that I/O so that it doesn't impair the performance of user tasks. This means that running Time Machine's background backup service on P rather than E cores wouldn't be expected to alter performance significantly, unless its I /O throttling were also removed. Monitoring performance While Activity Monitor's CPU History window provides valuable qualitative information about core allocation and performance on Apple silicon chips, it has one major flaw which prevents it from being used for quantitative work: CPU %, whether given in its main window or shown by the height of columns in CPU History, takes no account whatsoever of the frequency at which cores are being run. There's a good example of this shown in my MacSysAdmin presentation, and I'll examine this in a future article in this series. You should also ignore the Energy values given, which are based entirely on CPU %, and take no account of core frequency or type. It's extraordinary that estimation of energy use makes no distinction between the P and E cores in Apple silicon chips. Sadly, the only way of getting reliable information about core frequency, energy and power is in the command tool powermetrics. Previous article Making the most of Apple silicon power: 1 M-series chips are different Share this: * Twitter * Facebook * Reddit * Pinterest * Email * Print * Like this: Like Loading... Related Posted in Macs, Technology and tagged Activity Monitor, Apple, Apple silicon, ARM, big.LITTLE, M1, M2. Bookmark the permalink. Quick Links * Downloads * Mac Troubleshooting Summary * M1 & M2 Macs * Mac problem-solving * Painting topics * Painting * Long Reads Search Search for: [ ] [Search] Monthly archives * July 2023 (56) * June 2023 (73) * May 2023 (79) * April 2023 (73) * March 2023 (76) * February 2023 (68) * January 2023 (74) * December 2022 (74) * November 2022 (72) * October 2022 (76) * September 2022 (72) * August 2022 (75) * July 2022 (76) * June 2022 (73) * May 2022 (76) * April 2022 (71) * March 2022 (77) * February 2022 (68) * January 2022 (77) * December 2021 (75) * November 2021 (72) * October 2021 (75) * September 2021 (76) * August 2021 (75) * July 2021 (75) * June 2021 (71) * May 2021 (80) * April 2021 (79) * March 2021 (77) * February 2021 (75) * January 2021 (75) * December 2020 (77) * November 2020 (84) * October 2020 (81) * September 2020 (79) * August 2020 (103) * July 2020 (81) * June 2020 (78) * May 2020 (78) * April 2020 (81) * March 2020 (86) * February 2020 (77) * January 2020 (86) * December 2019 (82) * November 2019 (74) * October 2019 (89) * September 2019 (80) * August 2019 (91) * July 2019 (95) * June 2019 (88) * May 2019 (91) * April 2019 (79) * March 2019 (78) * February 2019 (71) * January 2019 (69) * December 2018 (79) * November 2018 (71) * October 2018 (78) * September 2018 (76) * August 2018 (78) * July 2018 (76) * June 2018 (77) * May 2018 (71) * April 2018 (67) * March 2018 (73) * February 2018 (67) * January 2018 (83) * December 2017 (94) * November 2017 (73) * October 2017 (86) * September 2017 (92) * August 2017 (69) * July 2017 (81) * June 2017 (76) * May 2017 (90) * April 2017 (76) * March 2017 (79) * February 2017 (65) * January 2017 (76) * December 2016 (75) * November 2016 (68) * October 2016 (76) * September 2016 (78) * August 2016 (70) * July 2016 (74) * June 2016 (66) * May 2016 (71) * April 2016 (67) * March 2016 (71) * February 2016 (68) * January 2016 (90) * December 2015 (96) * November 2015 (103) * October 2015 (119) * September 2015 (115) * August 2015 (117) * July 2015 (117) * June 2015 (105) * May 2015 (111) * April 2015 (119) * March 2015 (69) * February 2015 (54) * January 2015 (39) Tags APFS Apple AppleScript Apple silicon backup Big Sur Blake bug Catalina Consolation Console Corinth diagnosis Disk Utility Dore El Capitan extended attributes Finder firmware Gatekeeper Gerome HFS+ High Sierra history of painting iCloud Impressionism iOS landscape LockRattler log logs M1 Mac Mac history macOS macOS 10.12 macOS 10.13 macOS 10.14 macOS 10.15 macOS 11 macOS 12 macOS 13 malware Mojave Monet Monterey Moreau MRT myth narrative OS X Ovid painting Pissarro Poussin privacy realism Renoir riddle Rubens Sargent scripting security Sierra SilentKnight SSD Swift Time Machine Turner update upgrade Ventura xattr Xcode XProtect Statistics * 15,023,478 hits Blog at WordPress.com. Footer navigation * About & Contact * Macs * Painting * Language * Tech * Life * General * Downloads * Mac problem-solving * Extended attributes (xattrs) * Painting topics * Hieronymus Bosch * English language * LockRattler: 10.12 Sierra * LockRattler: 10.13 High Sierra * LockRattler: 10.11 El Capitan * Updates: El Capitan * Updates: High Sierra and later * LockRattler: 10.14 Mojave * SilentKnight, silnite, LockRattler, SystHist & Scrub * DelightEd & Podofyllin * xattred, Metamer, Sandstrip & xattr tools * 32-bitCheck & ArchiChect * XProCheck, T2M2, Ulbow, Consolation and log utilities * Cirrus & Bailiff * Taccy, Signet, Precize, Alifix, UTIutility, Sparsity, alisma * Revisionist & DeepTools * Text Utilities: Nalaprop, Dystextia and others * PDF * Keychains & Permissions * LockRattler: 10.15 Catalina * Updates * Spundle, Cormorant, Stibium, Dintch, Fintch and cintch * Long Reads * Mac Troubleshooting Summary * LockRattler: 11.0 Big Sur * M1 & M2 Macs * Mints: a multifunction utility * LockRattler: 12.x Monterey * VisualLookUpTest * Virtualisation on Apple silicon * LockRattler: 13.x Ventura * System Updates Secondary navigation * Search Post navigation Paintings of William Shakespeare's Plays 19: Twelfth Night Sunrise on Impressionism: 11 Stanislas Lepine Search for: [ ] [Search] Begin typing your search above and press return to search. Press Esc to cancel. * Follow Following + [croppe] The Eclectic Light Company Join 3,264 other followers [ ] Sign me up + Already have a WordPress.com account? Log in now. * + [croppe] The Eclectic Light Company + Customize + Follow Following + Sign up + Log in + Copy shortlink + Report this content + View post in Reader + Manage subscriptions + Collapse this bar %d bloggers like this: [b]