https://eclecticlight.co/2023/11/22/what-has-changed-in-cpu-cores-in-m3-chips/ Skip to content [eclecticlight] The Eclectic Light Company Macs, painting, and more Main navigation Menu * Downloads * M-series Macs * Mac Problems * Mac articles * Art * Macs * Painting hoakley November 22, 2023 Macs, Technology What has changed in CPU cores in M3 chips? If you read the initial reviews of Apple's new M3-based Macs, you'd be forgiven for thinking little had changed in their CPU cores, apart from a rejigging of numbers and an increase in the maximum frequency of their P cores. As my MacBook Pro 16-inch M3 Pro arrived three days early, this article presents a tentative first look at what has changed in their CPU cores, and from that, how you might choose the right chip for your next Apple silicon Mac. Like Apple, I'm going to make comparison between M1 and M3 chips, as in most respects discussed here, M2 CPU cores didn't change as much from those in the M1, and I've had and tested four different M1 models. Cluster size The most obvious difference between M1/M2 CPU cores and those in M3 chips is in the size of their clusters. In M1 and M2 chips, CPU cores are grouped into clusters of 2 or 4, within which cores share L2 cache and run at the same frequency. In M3 chips (certainly the M3 Pro, and I understand the M3 Max as well) clusters are composed of 4 (M3 basic) or 6 (Pro and Max). This change has impact on chip selection. macOS tries to allocate threads running at higher priorities, as set by their Quality of Service (QoS), to P cores whenever possible. This is what we want, as it ensures that the apps we're running deliver best performance, albeit at higher power consumption. When the P cores are already fairly fully occupied, macOS may instead run high QoS threads on the E cores. While it has compensatory mechanisms for doing this (see below), it may mean that those threads run more slowly than we'd want. If you already have an Apple silicon Mac and are wondering whether to upgrade to an M3 model, then you can use this as a way of working out which chip you'll need. Load your current Mac up with the apps you normally use together when working, and watch their use in Activity Monitor's CPU History window. If its P cores are fully occupied much of the time, and that workload often spills over to the E cores, then you should aim for an M3 with more P cores; if there's always adequate spare capacity on the Mac's P cores, then you probably wouldn't get much added value from an M3 with more P cores. This changed cluster size in M3 chips is significant, as it could not only have effects on performance, but also on power use. When running at full pelt, all six P cores in an M3 Pro cluster can use as much as 5.5 W, while six in an M1 Pro will use about 5.8 W. E cores From my preliminary measurements, E cores in an M3 Pro differ little from those in an M1 Pro, except for their frequency management, which is determined by macOS. M1 E cores have a maximum frequency of 2064 MHz, while those in M3 chips reach 2748 MHz. But, when running low QoS threads in the M1 Pro chip, E core frequency is set to 972 MHz, and that in the M3 Pro is 744 MHz, giving a ratio of 1.3 for M1/M3. Integer, floating point, NEON and Accelerate performance at those frequencies matches the difference in frequency, at 1.3-1.4. That means the M3's E cores run background threads slightly more slowly than the M1 because macOS sets their frequency lower. That isn't true, though, when the E cores are being used to run high QoS threads that couldn't be accommodated on P cores. Those are run at maximum frequency, which favours the M3 Pro by a factor of 1.3. Replacing an M1 Pro with an M3 Pro thus slows background tasks, but accelerates high QoS tasks that have overflowed onto the E cores. P cores There are greater differences between the P cores in an M1 Pro and those in an M3 Pro. M1 P cores have a maximum frequency of 3228 MHz, while M3 P cores run up to a maximum of 4056 MHz, a ratio of 1.26 in favour of the M3. A similar ratio is seen for integer and floating point performance, at 1.30 and 1.28 respectively, but vector performance using NEON or Apple's Accelerate library is faster still on the M3 Pro P core, at ratios of 1.67 and 1.63. This suggests that improved integer and floating point performance is largely (if not completely) the result of increased core frequency, but that there are likely to be further improvements in vector processing. Perhaps Apple has improved the design of the NEON unit in M3 P cores. P v E Aside from any improvement in vector processing in M3 P cores, M1 and M3 cores show different patterns of performance under load. These are perhaps clearest in the two charts below. Loads were applied using AsmAttic, which here runs tight loops of floating point arithmetic that remains in-core, accessing only registers and not memory. These charts show the time taken to complete one or more threads, each running 200 million loops of assembly code. Each thread is run as if on a single core at 100% active residency, i.e. it's one core's worth of performance, so 6 threads will fully load a 6-core P cluster. m1m3psummary This chart shows the total time to complete running all the threads, by the number of threads (effectively the number of cores), for an M1 Pro in red, and an M3 Pro in black. These threads were all run at maximum QoS (33), so were run preferentially on P cores. Those run on the 8 P cores in an M1 Pro (red) show a near-perfect linear relationship, with each thread fully occupying one core for a period of 1.3 seconds. The lower black line shows equivalent results for the 6 P and 6 E cores in an M3 Pro. For 1-6 threads, these were all run on its P cores, then on an increasing number of its E cores as well. That is quite linear up to 6 threads, where the time taken is significantly less than that of the M1 Pro. By 6 threads, that difference is over 1 second; in the time the M1 Pro took to run 5 threads, the M3 Pro had almost completed 6. From 6-8 threads, the two lines run in parallel, indicating that the M3 E cores were delivering similar performance to the P cores in the M1 Pro. You wouldn't want to run more than 8 threads, though, on the 8P + 2E cores of the M1 Pro, as they would risk displacing background threads on the two E cores. On the M3 Pro, you can go safely up to a total of 10 threads, on 6 P and 4 E cores, without compromising background threads. Indeed, because the E cluster is running at maximum frequency, background tasks might even complete more quickly under that load. m1m3esummary Differences are reversed when running low QoS threads on the E cores, as shown here, again with the 2 E cores of the M1 Pro in red, and the 6 E cores of the M3 Pro in black. The frequency of the M1 Pro E cores is increased when they're running a second thread, which accounts for the small change in total time from 1-2 threads. However, with more than 2 threads, further threads are queued, and performance suffers as a result. The 6 E cores of the M3 Pro have three times the capacity for background threads, and although running them more slowly, they cope with up to 6 threads, beyond which those threads are queued, and the time required to complete them rises more rapidly. CPU History The most accessible window you have on core load and performance is CPU History in Activity Monitor. Although it can cast light on the use of different types of core, and help you decide whether your next Mac needs more cores, it's also seriously misleading, as shown in the screenshot below. m1m3cpuhist This shows what happened during two tests using my app AsmAttic: in the first, responsible for the large blocks of green in the E cores, I ran a load of 6 threads at low QoS; in the second, reflected in the much narrower blocks for the P cores below, I ran the same load of 6 threads on the P cores. When the E cores were fully loaded, their frequency was 744 MHz, that's only a little above their idle, but when the P cores were fully loaded, they were running at close to their maximum at just under 4000 MHz. This persistent failure in Activity Monitor to take core frequency into account gives seriously misleading impressions. Summary * There's much more to comparing CPU cores than multi-core benchmarks. * If you already have an Apple silicon Mac, observe patterns of use of P and E cores during normal use to determine whether you need a Mac with more cores. * CPU core cluster size has changed in M3 chips, from 2-4 to 4-6, which is likely to have extensive effects on performance and power use. * M3 E cores appear similar to those in the M1, but have a higher maximum frequency, and are run at lower frequency for background tasks. * M3 P cores appear to have improved performance in the vector (NEON) unit, and have a higher maximum frequency. * Increased E core count increases the capacity to accommodate overflow of high QoS threads from P cores. * macOS core management has also changed. I will post further analyses of the M3 Pro chip's CPU performance as I assess the data. Share this: * Twitter * Facebook * Reddit * Pinterest * Email * Print * Like this: Like Loading... Related Posted in Macs, Technology and tagged Apple silicon, cores, CPU, M1, M3, performance. Bookmark the permalink. 14Comments Add yours 1. 1 [0acf8c79121e] Enzo Vincenzo on November 22, 2023 at 8:21 am Reply Thank you! You were very helpful to me! Maybe I'll buy a new iMac M3 and this time I'll opt for a BTO purchase on the Apple Store in basic configuration, but with 16 GB of RAM and 2 TB of SSD. Considering the power of any M3 Mac, I prefer to save by choosing the cheapest model, but immediately equipped with RAM and a large SSD whose choice outweighs the advantages of having milliseconds or seconds of difference, depending on the applications. Obviously I'm speaking from my point of view and based on my needs. We've reached such a rapid level now that I think it's hard to notice any difference unless you're making heavy video or 3D applications. After all, my late 2013 27'' iMac CPU i7 (maximum RAM and video card upgrade during BTO purchase and to which I added a fast 2TB SSD) has become so fast and powerful, thanks to OCLP and Sonoma, which provides Geekbench results similar to the Catalina-supported 2020 iMac. OT note: I would like to point out that with Sonoma and OCLP 1.2.1 Continuity Camera still doesn't work and there are some small minor bugs. But with Ventura everything works (on the system and with every application) just as if my iMac were an officially supported Mac. I still remain in Sonoma, waiting for Team OCLP to fix everything, little by little, like they did with Ventura back then. If that's not possible, I will reinstall the Ventura to continue to enjoy the iMac which is perfect, fast, high-performance but which Apple proposes TO SCRAP if I try to include it in a possible trade-in proposal. LikeLiked by 1 person + 2 [87cc8acbb0b9] hoakley on November 22, 2023 at 9:33 am Reply Apple will recycle models traded in if they're unable to resell them - it's the only alternative. And there's no market for Apple to sell reconditioned models that are ten years old, no matter how well they might still work. Neither do they try to stock replacement parts for such old hardware, so even its logic board isn't going to be of any use. Sorry, that's the way it is - if you want your Mac to go to a good home, then sell it privately, or give it to a charity that re-uses old computers. I think you'll find an M3 iMac blows your socks off! Howard. LikeLiked by 1 person o 3 [0acf8c79121e] Enzo Vincenzo on November 22, 2023 at 1:40 pm Reply I agree with you, Howard, in justifying Apple if it doesn't (rightly) accept trade-ins of Macs that are more than a few years old. But I don't agree with Apple's invitation to scrap my Mac. For Office use and also for use in a doctor's office, in fact, my Mac is fast and snappy beyond any need. Even the vision of RX and CT scan in 3D is fluid, fast, has no lag and does not make you want to replace the Mac. Scrapping it, therefore, goes against the Planet... Even more so if you consider that thanks to OCLP and Ventura or Sonoma the Mac accepts security updates... So, if I buy the new iMac M3, I will do it to use it at home. LikeLiked by 1 person # 4 [87cc8acbb0b9] hoakley on November 22, 2023 at 5:32 pm I think that's an excellent way to reuse it. Apple doesn't scrap old Macs - they go for recycling, and these days almost everything in a Mac is fully recyclable. So it goes on to make more new Macs. Howard. LikeLike 2. 5 [8716b5fc9e67] tomsax on November 22, 2023 at 12:13 pm Reply I can confirm that the 16-core M3 Max has one E-Cluster of 4 cores and 2 P-Clusters of 6 cores each. LikeLiked by 1 person + 6 [87cc8acbb0b9] hoakley on November 22, 2023 at 12:39 pm Reply Thank you very much. There's just the Ultra to go then, when it's released. Howard. LikeLike 3. 7 [ecaef27b357d] Monica Benneton-Smith on November 22, 2023 at 3:11 pm Reply Apple graciously gives us miraculously powerful hardware, yet time and time again we see it held back by horribly inefficient software. In hindsight, Swift was a big mistake. Apple should have gone with Rust instead. Not only is Rust blazingly fast and memory-efficient, but it also has no runtime or garbage collector, and its rich type system and ownership model guarantee memory-safety and thread-safety, according to its web site. Like Firefox proved to the world, it is also possible to gradually rewrite portions of existing C and C++ software using Rust. It would have taken several years to do, obviously, but macOS, Cocoa, and the rest of Apple's software should have gradually been rewritten using Rust. Thanks to both the hardware and the software getting faster each year, Apple's computers would then continually be getting even more powerful and faster than they already are. Rust would have been a software performance multiplier in addition to the M* hardware performance multiplier. LikeLiked by 1 person + 8 [87cc8acbb0b9] hoakley on November 22, 2023 at 5:36 pm Reply Oh no - you're not going to turn this into a religious debate about programming languages. For a start, it has absolutely nothing to do with this article. And, as you should well know, it's not the language, but the compiler and the person coding with that language that determine the efficiency of the code run. And you're welcome to code in Rust for macOS if that's what you want. Now, can we please return to the topic of this article? Thank you for your understanding. Howard. (Over 35 years coding in almost everything from assembly language to APL.) LikeLike 4. 9 [18ceda4a866b] Manuel Garcia on November 22, 2023 at 4:47 pm Reply I received my 14'' MBPro with M3Pro early (last Thursday), too. Interestingly, and according to results from Geekbench 6, the CPU frequency was not 4.05 GHz; it was ~3.7 GHz (I don't recall the exact frequency). Is the frequency not always set the same, or was it a problem with my hardware or software (Geekbench)? I don't know and didn't try to find out. It was a custom configuration (36 instead of 18 GB of memory), and I ended up just returning it and getting an M3 Max with 36 GB (14'' again), not because I necessarily needed the Max, but rather just the 36 GB of memory and the M3 Max model was the only one in stock at the apple store with that amount of memory. Anyway, thanks for all your great columns and advice. I also really enjoyed reading your Don Quixote summaries and paintings. LikeLiked by 1 person + 10 [87cc8acbb0b9] hoakley on November 22, 2023 at 5:42 pm Reply Thank you. I don't know where Geekbench got that figure from, but I have taken it from powermetrics, running assembly code. macOS has great control over the frequency of both P and E cores. When P cores are given a substantial load at high QoS, they will normally be run at maximum frequency as much as possible, as that's what delivers the performance. The code used in my tests here is written in assembly language so that it run tight loops in each core, with only register access, not memory. It's carefully designed to measure maximum throughput in the core itself. I hope that you enjoy your M3 Max! Howard. LikeLike 5. 11 [2c27638b7fbb] Simon on November 22, 2023 at 8:05 pm Reply A very nice comparison, Howard. Thank you. If money is not an issue (pardon this somewhat academic question), would you consider any negative impact from over-spec'ing a MBP? Can we trust that the variable clock and macOS' excellent management of the Mx cores will ensure that even if we have purchased too many P cores for our typical workloads, that the system will still run cool and with long battery life? Or can you see cases where people would indeed get better battery life and cooler systems just because they chose a lighter spec'ed system. LikeLiked by 1 person + 12 [87cc8acbb0b9] hoakley on November 22, 2023 at 8:16 pm Reply Thank you. When not in use, a cluster is effectively shut down, either at 0 MHz or idle frequency, and draws almost no power. So if your M3 Max's second cluster of P cores never do anything except idle, they won't cost it any battery endurance. Where the M3 Pro might profit is when threads overflow its single cluster of P cores. With no second P cluster to light up, the additional threads will then be run on the E cluster, not quite so fast, but with significantly lower power use. On the M3 Max, the second P cluster would light up, and probably drain the battery slightly faster. Power and energy calculations are quite nuanced, so I want to look more carefully at the data before saying whether that would be significant, but it appears likely. This is but the start of a long journey of discovery. Howard. LikeLike 6. 13 [2c27638b7fbb] Simon on November 22, 2023 at 8:12 pm Reply > Although it can cast light on the use of different types of core, and > help you decide whether your next Mac needs more cores, it's also > seriously misleading, as shown in the screenshot below. > ... > This persistent failure in Activity Monitor to take core frequency into > account gives seriously misleading impressions. I do not disagree with this statement at all. But I am curious to hear more. In this case specifically there is an indication, right? You know the task you have initiated is identical in both cases, so the integral needs to be the same. Is not the fact that 6 P cores show a much broader block than the thin stripes for 6 E cores already an indication that the clock for the P cluster thus must be running much higher than for the E cluster? LikeLiked by 1 person + 14 [87cc8acbb0b9] hoakley on November 22, 2023 at 8:25 pm Reply As I have established before, what Activity Monitor's CPU History window shows is percent active residency. Not only does that fail to take into account differences between P and E cores, but it misleads within the same core. On an M3 Pro E core, low QoS threads will be run at 744 MHz, and quite possibly attain 100% active residency. That's around a third of the total core throughput capacity, not 100%. When that E core is running high QoS threads that have overflowed from the P cores, it might have a lower active residency of 50%, but run at a frequency of 2064 MHz. But there, CPU History will show its load at 50% even though its throughput is far greater than at low QoS. I have long argued that the figures shown in Activity Monitor should be expressed as percentages of full active residency at maximum core frequency, which would allow much better semi-quantitative comparisons. With all the power of Apple silicon, you might have thought that making that simple arithmetic adjustment would have been straightforward. Howard. LikeLike Leave a Reply Cancel reply [ ] [ ] [ ] [ ] [ ] [ ] [ ] D[ ] This site uses Akismet to reduce spam. Learn how your comment data is processed. Quick Links * Downloads * Mac Troubleshooting Summary * M-series Macs * Mac problem-solving * Painting topics * Painting * Long Reads Search Search for: [ ] [Search] Monthly archives * November 2023 (54) * October 2023 (77) * September 2023 (77) * August 2023 (72) * July 2023 (79) * 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,958,932 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, Spotcord, Metamer & 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 * LockRattler: 11.0 Big Sur * Mac Troubleshooting Summary * M-series Macs * Mints: a multifunction utility * LockRattler: 12.x Monterey * VisualLookUpTest * Virtualisation on Apple silicon * LockRattler: 13.x Ventura * System Updates * LockRattler: 14.x Sonoma * Saturday Mac Riddles * Last Week on My Mac Secondary navigation * Search Post navigation Reading visual art: 89 Oil lamps A Reading visual art: 90 Oil lamps B Search for: [ ] [Search] Begin typing your search above and press return to search. Press Esc to cancel. * Comment * Follow Following + [croppe] The Eclectic Light Company Join 3,503 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 Loading Comments... Write a Comment... [ ] Email (Required) [ ] Name (Required) [ ] Website [ ] [Post Comment] %d bloggers like this: [b]