https://eclecticlight.co/2026/02/08/last-week-on-my-mac-why-e-cores-make-apple-silicon-fast/ Skip to content [eclecticlight] The Eclectic Light Company Macs & painting - No AI content Main navigation Menu * Downloads * Freeware * M-series Macs * Mac Problems * Mac articles * Macs * Art hoakley February 8, 2026 Macs, Technology Last Week on My Mac: Why E cores make Apple silicon fast If you use an Apple silicon Mac I'm sure you have been impressed by its performance. Whether you're working with images, audio, video or building software, we've enjoyed a new turn of speed since the M1 on day 1. While most attribute this to their Performance cores, as it goes with the name, much is in truth the result of the unsung Efficiency cores, and how they keep background tasks where they should be. To see what I mean, start your Apple silicon Mac up from the cold, and open Activity Monitor in its CPU view, with its CPU History window open as well. For the first five to ten minutes you'll see its E cores are a wall of red and green with Spotlight's indexing services, CGPDFService, mediaanalysisd, BackgroundShortcutRunner, Siri components, its initial Time Machine backup, and often an XProtect Remediator scan. Meanwhile its P cores are largely idle, and if you were to dive straight into using your working apps, there's plenty of capacity for them to run unaffected by all that background mayhem. handecpuhistory It's this stage that scares those who are still accustomed to using Intel Macs. Seeing processes using more than 100% CPU is terrifying, because they know that Intel cores can struggle under so much load, affecting user apps. But on an Apple silicon Mac, who notices or cares that there's over a dozen mdworker processes each taking a good 50% CPU simultaneously? After all, this is what the Apple silicon architecture is designed for. Admittedly the impression isn't helped by a dreadful piece of psychology, as those E cores at 100% are probably running at a frequency a quarter of those of P cores shown at the same 100%, making visual comparison completely false.* This is nothing new. Apple brought it to the iPhone 7 in 2016, in its first SoC with separate P and E cores. That's an implementation of Arm's big.LITTLE announced in 2011, and development work at Cray and elsewhere in the previous decade. What makes the difference in Apple silicon Macs is how threads are allocated to the two different CPU core types on the basis of a metric known as Quality of Service, or QoS. As with so much in today's Macs, QoS has been around since OS X 10.10 Yosemite, six years before it became so central in performance. When all CPU cores are the same, it has limited usefulness over more traditional controls like Posix's nice scheduling priority. All those background tasks still have to be completed, and giving them a lower priority only prolongs the time they take on the CPU cores, and the period in which the user's apps are competing with them for CPU cycles. With the experience gained from its iPhones and other devices, Apple's engineers had a better solution for future Macs. In addition to providing priority-based queues, QoS makes a fundamental distinction between those threads run in the foreground, and those of the background. While foreground threads will be run on P cores when they're available, they can also be scheduled on E cores when necessary. But background threads aren't normally allowed to run on P cores, even if they're delayed by the load on the E cores they're restricted to. We know this from our inability to promote existing background threads to run on P cores using St. Clair Software's App Tamer and the command tool taskpolicy. This is why, even if you sit and watch all those background processes loading the E cores immediately after starting up, leaving the P cores mostly idle, macOS won't try running them on its P cores. If it did, even if you wanted it to, the distinction between foreground and background, P and E cores would start to fall apart, our apps would suffer as a consequence, and battery endurance would decline. Gone are the days of crashing mdworker processes bringing our Macs to their knees with a spinning beachball every few seconds. If seeing all those processes using high % CPU can look scary, the inevitable consequence in terms of software architecture might seem terrifying. Rather than building monolithic apps, many of their tasks are now broken out into discrete processes run in the background on demand, on the E cores when appropriate. The fact that an idle Mac has over 2,000 threads running in over 600 processes is good news, and the more of those that are run on the E cores, the faster our apps will be. The first and last M-series chips to have only two E cores were the M1 Pro and Max, since when every one has had at least four E cores, and some as many as six or eight. Because Efficiency cores get the background threads off the cores we need for performance. * For the record, I have measured those frequencies using powermetrics. For an M4 Pro, for example, high QoS threads running on the P cores benefit from frequencies close to the P core max of 4,512 MHz. Low QoS threads running on the E cores are run at frequencies close to idle, typically around 1,050 MHz. However, when the E cores run high QoS threads that have overflowed from the P cores, the E cores are normally run at around their maximum of 2,592 MHz. By my arithmetic, 1,050 divided by 4,512 is 0.233, which is slightly less than a quarter. Other M-series chips are similar. Share this: * Share on X (Opens in new window) X * Share on Facebook (Opens in new window) Facebook * Share on Reddit (Opens in new window) Reddit * Share on Pinterest (Opens in new window) Pinterest * Share on Threads (Opens in new window) Threads * Share on Mastodon (Opens in new window) Mastodon * Share on Bluesky (Opens in new window) Bluesky * Email a link to a friend (Opens in new window) Email * Print (Opens in new window) Print * Like Loading... Related Posted in Macs, Technology and tagged Activity Monitor, Apple silicon , M1, performance, QoS, taskpolicy. Bookmark the permalink. 14Comments Add yours 1. 1 Duncan's avatar Duncan on February 8, 2026 at 3:58 pm Reply "Admittedly the impression isn't helped by a dreadful piece of psychology, as those E cores at 100% are probably running at a frequency a quarter of those of P cores shown at the same 100%, making visual comparison completely false." The principle way to view core utilization is with the CPU History window, as shown at the top of this article. Since the CPU History window is simply to aid visualization - as there are no calibration marks to measure against - I think Apple could 'cheat' the vertical scale by making the Efficiency Core blocks half the height of the Performance Core blocks. That way, when you glance at the window, the E-cores would appear to be depicting less of the overall CPU resources by virtue of their graphs being smaller. (It's sort of like how large aircraft might have an Auxiliary Power Unit (a separate on-board generator) to run the electrical systems independent of the main engines; The APU might be running near full capacity on the ground, but that doesn't mean the plane is consuming fuel at the same rate as when the main engines are running.) LikeLiked by 1 person + 2 hoakley's avatar hoakley on February 8, 2026 at 4:15 pm Reply Thank you, Duncan, but even that's completely misleading. When running low QoS threads, the E cores run at a frequency close to idle, often around 1 GHz (depending on chip). When those same cores are used to run overflowing high QoS threads, they run at close to their maximum frequency, of 3+ GHz, which is less than the normal active frequency of the P cores. I have proposed a simple way to incorporate frequency into a % CPU that is comparable between E and P cores, and with different frequencies within the same core. However, Apple has done nothing in over 5 years to rectify this deception. Howard. LikeLike o 3 Duncan's avatar Duncan on February 8, 2026 at 4:24 pm Reply "I have proposed a simple way to incorporate frequency into a % CPU that is comparable between E and P cores, and with different frequencies within the same core." Would that be visible graphically, like with the CPU History window? I'm curious how that would look, if you have an example. LikeLiked by 1 person # 4 hoakley's avatar hoakley on February 8, 2026 at 4:34 pm It's just a different way or working out the % CPU. Currently, Activity Monitor gives the percentage active residency, the % of cycles that are doing work rather than idling. All you need do is incorporate the frequency, say by multiplying that by the ratio of the actual frequency to the maximum of the P cores. Then when a P core is at 100% active residency and max frequency, it's at 100%. When an E core is at 100% active residency and a quarter of the P core max, it's at 25%. There is a lesser argument that E cores have about half the compute capacity of P cores, so you could have those percentages for E cores, but I don't think that's a important as correcting for frequency. Howard. LikeLike 2. 5 Duncan's avatar Duncan on February 8, 2026 at 4:05 pm Reply Incidentally, if one ever wishes to see a wall of red and green in their CPU History window, run the Handbrake app to convert a video from one format to another. That will use every ounce of available CPU resources, including the efficiency cores, yet still yields when any higher-priority tasks request them. For a completely free app, the code controlling CPU utilization is outstanding, in my opinion. Larger app vendors (I'm looking at you, Adobe, Microsoft, and most web browsers) would do well to follow Handbrake's programming practices. LikeLiked by 1 person + 6 hoakley's avatar hoakley on February 8, 2026 at 4:17 pm Reply I hate to disappoint you, but no app running in macOS controls its CPU utilisation - that's all done by macOS. Your description of Handbrake is exactly what macOS sets out to do. It's perfectly possible for a developer to screw that up, of course, but it's actually quite hard/stupid to do so. Howard. LikeLike o 7 Duncan's avatar Duncan on February 8, 2026 at 4:35 pm Reply Perhaps it's the nature of video encoding that allows an app (such as Handbrake) to use almost all system resources, including E-cores, so abruptly when it runs? And yet it can be dialed back as soon as the user initiates some other intensive task. On an otherwise idle machine, I can have Handbrake running full-tilt during an encode process, yet the user interface still remains responsive. Other times, with just a web browser running with 'heavy' web pages, I'll notice a lag when switching to a different task. I might be fooling myself with such a subjective experience, but it certainly feels like some apps bog down the machine in different ways than others. (I guess one difference might be that Handbrake doesn't push the WindowServer much during its operation, unlike with other apps.) LikeLiked by 1 person # 8 hoakley's avatar hoakley on February 8, 2026 at 5:38 pm It's easier with threads that can be run in the background. You ensure you have ample threads to fill all the cores, then assign then a middling QoS that ensures they're run on the P cores when available. But they will give way to threads at higher QoS, as used by the main thread in apps. So when all the cores are lightly loaded, the threads will be run on them all, but the moment the main thread of an app wants core, it should be given that on the P cores, so run at normal speed. The common error is to give those threads all the default, or higher, QoS, which can block other threads from the P cores. Unfortunately, some code has to be run in the app main thread, and that can be a problem. Howard. LikeLike # 9 Duncan's avatar Duncan on February 8, 2026 at 6:47 pm Thank you for the explanation. I know you've written about this countless times in the past, but with this concrete example (namely Handbrake) I have a better comprehension of how it fits together. LikeLiked by 1 person # 10 hoakley's avatar hoakley on February 8, 2026 at 9:13 pm It's wonderful to see it work so well - and I agree kudos to the developer of Handbrake, and opprobrium to those who aren't as caring of the user. Howard. LikeLike 3. 11 Jim Derry's avatar Jim Derry on February 8, 2026 at 9:16 pm Reply Forgive me if this seems like a naive question, but if all cores were equal and one didn't care about energy consumption, then the same effect would be had by simply sequestering these same background tasks to some specified four cores, correct? LikeLiked by 1 person + 12 hoakley's avatar hoakley on February 8, 2026 at 9:26 pm Reply Only when the other cores are busy. If they're lightly loaded or idle, then there's no advantage, and the sequestered threads will be delayed without any benefit. Most CPU manufacturers also prefer not to do that, but to spread the load evenly, because of thermal effects. If you've got 4 cores that are always running hot because of their constant load, it's not good news in a CPU. Howard. LikeLike 4. 13 PowerCubed's avatar PowerCubed on February 8, 2026 at 10:20 pm Reply Something I didn't see mentioned is the reduction in context switching by limiting the vast majority of active processes to the E cores. Run Xcode's Instruments with the System Trace template and you can see how the vast majority of processes are fighting for E core time, leaving the user's app free to consume one or more P cores in its entirety, sans the infrequent interrupt. This is in contrast to Intel, where the OS has to constantly switch to different threads to handle "background" tasks or activate other cores and risk frequency downscaling. As an aside, it's apparently possible to manipulate the E-core into running at a higher frequency. I use SoundSource, which allows me to have per-app volume control and use AUs, and doing so I see the E-core frequency scale up between 1.8-2.2 GHz, depending on usage. I would assume this is due to the realtime nature of audio handling. It also appears that if you saturate E-cores, it will run on the P-cores: scaling them up to maximum frequency as well. It appears that both coreaudiod and SoundSource operate on both core types, at least to some extent. As a final note, with Instruments you can see that the QoS priority is not the final priority, there is kernel-level thread priority assigned to each thread, with values form 0 to at least 97 (this is what I'm seeing for audio threads). LikeLiked by 1 person + 14 hoakley's avatar hoakley on February 8, 2026 at 10:41 pm Reply Thank you. That's a good point on context switching. I have described an easy way the user can boost E core frequency, by ensuring a higher QoS thread is spilled over onto the E cluster. As all cores in a cluster run at the same frequency, macOS boosts their frequency to run the higher QoS thread more quickly, and all the low QoS threads run on that cluster complete more quickly. As I haven't looked at how macOS allocates core types and frequencies for audio, I can't comment on that, but I don't believe it's any different from other threads. It's more likely that the QoS is manipulated instead. QoS allocated by the coder isn't the QoS used internally in macOS - it's modulated by several other factors, and can either be expressed as a floating point number or a larger integer. And I suspect that's how you're seeing these effects on core type allocation. Having repeatedly tried to get low QoS thread run on P cores and never been successful, and seeing what happens after starting a Mac up, I have never seen any low QoS thread run on a P core. A lot of effort has been wasted trying to do that. Howard. LikeLike Leave a comment Cancel reply [ ] [ ] [ ] [ ] [ ] [ ] [ ] D[ ] Quick Links * Free Software Menu * System Updates * M-series Macs * Mac Troubleshooting Summary * Mac problem-solving * Painting topics * Painting * Long Reads Search Search for: [ ] [Search] Monthly archives * February 2026 (20) * January 2026 (72) * December 2025 (75) * November 2025 (74) * October 2025 (75) * September 2025 (78) * August 2025 (76) * July 2025 (77) * June 2025 (74) * May 2025 (76) * April 2025 (73) * March 2025 (78) * February 2025 (67) * January 2025 (75) * December 2024 (74) * November 2024 (73) * October 2024 (78) * September 2024 (77) * August 2024 (75) * July 2024 (77) * June 2024 (71) * May 2024 (79) * April 2024 (75) * March 2024 (81) * February 2024 (72) * January 2024 (78) * December 2023 (79) * November 2023 (74) * 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 Apple silicon backup Big Sur Blake Bonnard bug Catalina Consolation Console Corinth Delacroix Disk Utility Dore El Capitan extended attributes Finder firmware Gatekeeper Gerome High Sierra history of painting iCloud Impressionism landscape LockRattler log M1 Mac Mac history macOS macOS 10.12 macOS 10.13 macOS 10.14 macOS 10.15 macOS 11 macOS 12 macOS 13 macOS 14 macOS 15 malware Metamorphoses Mojave Monet Monterey Moreau myth narrative OS X Ovid painting performance Pissarro Poussin privacy Renoir riddle Rubens Sargent security Sierra SilentKnight Sonoma SSD Swift Time Machine Tintoretto Turner update upgrade Ventura xattr Xcode XProtect Statistics * 21,399,160 hits Blog at WordPress.com. Footer navigation * Free Software Menu * About & Contact * Macs * Painting * Downloads * Mac problem-solving * Extended attributes (xattrs) * Painting topics * SilentKnight, Skint, SystHist, silnite, LockRattler & Scrub * DelightEd & Podofyllin * xattred, SpotTest, Providable, Spotcord, Metamer & xattr tools * 32-bitCheck & ArchiChect * XProCheck, T2M2, LogUI, Ulbow, blowhole and log utilities * Cirrus & Bailiff * Precize, Alifix, UTIutility, Sparsity, alisma, Taccy, Signet * Versatility & Revisionist * Text Utilities: Textovert, Disclipper, Nalaprop, Dystextia and others * PDF * Keychains & Permissions * Updates * Spundle, Cormorant, Stibium, DropSum, Dintch, Fintch and cintch * Long Reads * Mac Troubleshooting Summary * M-series Macs * Mints: a multifunction utility * VisualLookUpTest * Virtualisation on Apple silicon * System Updates * Saturday Mac Riddles * Last Week on My Mac * sysctl information Secondary navigation * Search Post navigation Japonisme in painting: 1863-1888 Japonisme in painting: 1889-1918 Search for: [ ] [Search] Begin typing your search above and press return to search. Press Esc to cancel. * Comment * Reblog * Subscribe Subscribed + [croppe] The Eclectic Light Company Join 8,989 other subscribers [ ] Sign me up + Already have a WordPress.com account? Log in now. * + [croppe] The Eclectic Light Company + Subscribe Subscribed + 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 [b]