10 ms·

Why E cores make Apple silicon fast

271 points by ingve 9mo ago

tyleo 9mo ago
These processors are good all around. The P cores kick butt too. I ran a performance test back in October comparing M4 laptops against high-end Windows desktops, and the results showed the M-series chips coming out on top. https://www.tyleo.com/blog/compiler-performance-on-2025-devices https://www.tyleo.com/blog/compiler-performance-on-2025-devi...
- murderfs 9mo ago
  This is likely more of a Windows filesystem benchmark than anything else: there are fundamental restrictions on how fast file access can be on Windows due to filesystem filter drivers. I would bet that if you tried again with Linux (or even in WSL2, as long as you stay in the WSL filesystem image), you'd see significantly improved results.
  - philistine 9mo ago
    Which still wouldn’t beat the Apple Silicon chips. Apple rules the roost.
    - Kuinox 9mo ago
      https://www.cpubenchmark.net/laptop.html https://www.cpubenchmark.net/laptop.html
      - philistine 9mo ago
        You click on laptop and somehow that's a gotcha, I click on single thread and the M5 is at the very top. What is that?
        Kuinox 9mo ago
        You are seeing basically the lithography node used to make the CPU. Since Apple books more capacity than anyone else, they have their chip 5-6 months ahead of the market, you'll see chips with similar performance by core.
        philistine 9mo ago
        And what about the M3 Ultra, that sits at number 3 and came out ten months ago? Why was it not beaten five months ago? Might I add that the M3 Ultra is on an older node than the M5. And what about the A19 Pro, which is better at single core than every desktop chip in the world, and happens to be inside a phone! Apple has the best silicon team in the world. They choose perf per watt over pure perf, which means they don't win on multi-core, but they're simply the best in the world in the most complicated, difficult, and impossible metric to game: single core perf.
        Kuinox 9mo ago
        It's bench score on single thread is 0.6% better than the Intel Core Ultra 9 285K, which have a lower TDP and was released 6 months before. Boths use the same lithography node. If you look at the chip by their lithography node, the Apple silicons are the same than the others...
        SR2Z 9mo ago
        Apple's M-series chips are fantastic, but I do agree with you that it's mostly a combination of newer process and lots of cache. Even when they were new, they competed with AMD's high end desktop chips. Many years later, they're still excellent in the laptop power range - but not in the desktop power range, where chips with a lot of cache match it in single core performance and obliterate it in multicore. https://www.cpu-monkey.com/en/compare_cpu-apple_m4-vs-amd_ryzen_7_9800x3d https://www.cpu-monkey.com/en/compare_cpu-apple_m4-vs-amd_ry...
        deleted 9mo ago
- cubefox 9mo ago
  Here is a more recent comparison with Intel's new Panther Lake chips: https://www.tomsguide.com/computing/cpus/panther-lake-is-intels-m1-moment-but-can-it-beat-apple-silicon-we-put-these-new-chips-to-the-test https://www.tomsguide.com/computing/cpus/panther-lake-is-int...
  - sys_64738 9mo ago
    Are the Intel systems plugged in when running those tests? Usually when Apple machines do the tests then the difference between battery/plugged in is small if any.
  - dagmx 9mo ago
    Which still come out behind other than multi core, while using substantially more power. Those panther lake comparisons are from the top end PTL to the base M series. If they were compared to their comparative SKUs they’d be even further behind.
    - cubefox 9mo ago
      The article said the M5 has significantly higher single core CPU performance, Panther Lake has significantly higher GPU performance. The Panther Lake devices had OLED screens, which consume significantly more power than LCDs, so they were at a disadvantage. This was all mentioned in the article.
      - PunchyHamster 9mo ago
        So useless for what most laptops are used - working
      - dagmx 9mo ago
        Again, the Panther Lake devices here are the top end of Panther lake comparing against the base level M5. See the chart here for what the intel SKUs are: https://www.pcworld.com/article/3023938/intels-core-ultra-series-3-cpu-names-are-different-now-heres-what-they-mean.html https://www.pcworld.com/article/3023938/intels-core-ultra-se... They consume more power at the chip level. You can see this in Intels spec sheets. The base recommended power envelope of the PTL is the maximum power envelope of the M5. They’re completely different tiers. You’re comparing a 25-85W tier chip to a 5W-25W chip. They also only win when it comes to multi core whether that’s CPU or GPU. If they were fairly compared to the correct SoC (an M4 Pro) they’d come out behind on both multicore CPU and GPU. This was all mentioned in my comment addressing the article. This is the trick that apples competitors are using, by comparing across SKU ranges to grab the headlines. PTL is a strong chip, no doubt, but it’s still behind Apple across all the metrics in a like for like comparison.
- etrvic 9mo ago
  From your article it seems like you benchmark compile times. I am not an expert on the subject, but I don't see the point in comparing ARM compilation times with Intel. There are probably different tricks involved in compilation and the instructions set are not the same.
  - tom_ 9mo ago
    I've often been suspicious of this too, having noticed that building one of my projects on Apple Silicon is way quicker than I'd expect relative to x64, given relative test suite run times and relative PassMark numbers. I don't know how to set up a proper cross compile setup on Apple Silicon, so I tried compiling the same code on 2 macOS systems and 1 Linux system, running the corresponding test suite, and getting some numbers. It's not exactly conclusive, and if I was doing this properly properly then I'd try a bit harder to make everything match up, but it does indeed look like using clang to build x64 code is more expensive - for whatever reason - than using it to build ARM code. Systems, including clang version and single-core PassMark: M4 Max Mac Studio, clang-1700.6.3.2 (PassMark: 5000) x64 i7-5557U Macbook Pro, clang-1500.1.0.2.5 (PassMark: 2290) x64 AMD 2990WX Linux desktop, clang-20 (PassMark: 2431) Single thread build times (in seconds). Code is a bunch of C++, plus some FOSS dependencies that are C, everything built with optimisation enabled: Mac Studio: 365 x64 Macbook Pro: 1705 x64 Linux: 1422 (Linux time excludes build times for some of the FOSS dependencies, which on Linux come prebuilt via the package manager.) Single thread test suite times (in seconds), an approximate indication of relative single thread performance: Mac Studio: 120 x64 Macbook Pro: 350 x64 Linux: 309 Build time/test time makes it look like ARM clang is an outlier: Mac Studio: 3.04 x64 Macbook Pro: 4.87 x64 Linux: 4.60 (The Linux value is flattered here, as it excludes dependency build times, as above. The C dependencies don't add much when building in parallel, but, looking at the above numbers, I wonder if they'd add up to enough when built in series to make the x64 figures the same.)
    - tom_ 8mo ago
      After tweaking the build process to build the same dependencies from source on Linux as on macOS: x64 Linux build: 1514 x64 Linux test: 307 x64 Linux build/test: 4.93 (Again, not a perfect test, as it still won't be exactly the same code, but the numbers are nevertheless pretty close!)
- wpm 9mo ago
  My M4 mini is probably the fastest computer/watt in my home. And it was the cheapest. Not even a bad little gaming machine on the rare occasion
roomey 9mo ago
Genuine question, when people talk about apple silicon being fast, is the comparison to windows intel laptops, or Mac intel architecture? Because, when running a Linux intel laptop, even with crowd strike and a LOT of corporate ware, there is no slowness. When blogs talk about "fast" like this I always assumed it was for heavy lifting, such as video editing or AI stuff, not just day to day regular stuff. I'm confused, is there a speed difference in day to day corporate work between new Macs and new Linux laptops? Thank you
- newsclues 9mo ago
  Power management with Mac’s is the big benefit, imo. It’s all about the perf per watt.
- cj 9mo ago
  For me it’s things like boot speed. How long does it take to restart the computer. To log out, and log back in with all my apps opening. Mac on intel feels like it was about 2x slower at these basic functions. (I don’t have real data points) Intel Mac had lag when opening apps. Silicon Mac is instant and always responsive. No idea how that compares to Linux.
  - nottorp 9mo ago
    Hmm? Why do you restart your computer often enough to notice? Even Windows (or at least my install that doesn't have any crap besides visual studio on it) can run for weeks these days...
    - maccard 9mo ago
      My work laptop decided probably once a week to not go to sleep and just run its battery to 0. My work PC will decide to not idle and will spin up fans arbitrarily in the evenings so I shut it down when I’m not using it.
      - nottorp 8mo ago
        > My work laptop decided probably once a week to not go to sleep and just run its battery to 0. That reminds me that if Apple annoys me enough to switch back to linux at my main OS it will hurt on laptops :(
ricardobeat 9mo ago
> The fact that an idle Mac has over 2,000 threads running in over 600 processes is good news Not when one of those decides to wreck havoc - spotlight indexing issues slowly eating away your disk space, icloud sync spinning over and over and hanging any app that tries to read your Documents folder, Photos sync pegging all cores at 100%… it feels like things might be getting a little out of hand. How can anyone model/predict system behaviour with so many moving parts?
- fragmede 9mo ago
  and if it paid off, that would almost be acceptable! But no. After spotlight has indexed my /Applications folder, when I hit command-spacebar and type "preview.app", it takes ~4 seconds on my M4 laptop to search the sqlite database for it and return that entry. grumble
  - admissionsguy 9mo ago
    TIL there is a search bar triggered by CMD+Space. After 15 long years.
    - rngfnby 9mo ago
      Too late. Apple has destroyed it. I just got my first ARM Mac to replace my work Win machine (what has MS done to Windows!?!? :'() Used to be I could type "display" and Id get right to display settings in settings. Now it shows thousands of useless links to who knows what. Instead I have to type "settings" and then, within settings, type "display" Still better than the Windows shit show. Honestly, a well setup Linux machine has better user experience than anything on the market today.
      - chaostheory 9mo ago
        > a well setup Linux machine has better user experience than anything on the market today We probably have to preface that with “for older people”. IMO Linux has changed less UX wise than either Windows or MacOS in recent years
amelius 9mo ago
That's just framing. A different wording could be: by moving more work to slow (but power efficient) cores, the other cores (let's call them performance cores) are free to do other stuff.
drob518 9mo ago
Does anyone have any insight into the MacOS scheduler and the algorithm it uses to place threads on E vs. P cores? Is it as simple as noting whether a thread was last suspended blocking on I/O or for a time slice timeout and mapping I/O blockers to E cores and time slice blockers to P cores? Or does the programmer indicate a static mapping at thread creation? I write code on a Mac all the time, but I use Clojure and all the low level OS decisions are opaque to me.
- sys_64738 9mo ago
  The article mentions P or E is generally decided by if it's a "background" process (whatever than means). Possible some (undocumented) designation in code or directive to the compiler of the binary decides this at compile time.
  - masklinn 9mo ago
    > whatever than means It’s a QoS level: https://developer.apple.com/documentation/dispatch/dispatchqos https://developer.apple.com/documentation/dispatch/dispatchq...
- detourdog 9mo ago
  https://developer.apple.com/videos/play/tech-talks/110147/ https://developer.apple.com/videos/play/tech-talks/110147/
  - drob518 9mo ago
    Excellent, thanks!
- masklinn 9mo ago
  The baseline is static: low QoS tasks are dispatched to the E cores, while high QoS tasks are dispatched to P cores. IIRC high QoS cores can migrate to the E cores if all P cores are loaded, but my understanding is that the lowest QoS tasks (background) never get promoted to P cores.
sys_64738 9mo ago
My M2 MBA doesn't have a fan but literally smokes the majority on Intel systems which are space heaters this time of year. Those legacy x86 apps don't really exist for the majority of people anymore.
- ProllyInfamous 9mo ago
  If you place 1mm thermal pads between the sinks and the case, the CPUs/GPUs won't throttle as readily. At least for my M3 MBA (check your actual clearance). I replaced a MacPro5,1 with an M2Pro — which uses soooooo much less energy performing similarly mundane tasks (~15x+). Idle is ~25W v. 160W
  - zozbot234 9mo ago
    Caution: don't put the laptop in your lap if you've done this. There's a reason it doesn't ship like that out of the box.
    - ProllyInfamous 8mo ago
      You already don't want notebooks sitting on your lap (safe radiation exposure limits from WiFi / Bluetooth), which is why they're no longer referred to as "laptops" (by OEMs). But if you're commenting about temperature / burns — the bottom of the MBP doesn't get noticeably warmer (at all), likely because the large metal case is such an efficient dissipator/sink.
      - zozbot234 8mo ago
        It's going to get hot if you peg the CPU/GPU at 100% for long enough. Just a matter of physics.
        ProllyInfamous 8mo ago
        The casebottom of my 15" MBAir has never exceeded 32°C — and that's sitting on a bed. Just a matter of physics: conductive case has orders of magnitude more thermal mass. It also helps that Apple Silicon processors consumer orders of magnitude less power than most competitor OEMs. Pegged out the entire machine uses less energy than my former notebook's GPU, alone.
ksec 9mo ago
>If you use an Apple silicon Mac I’m sure you have been impressed by its performance. This article couldn't have come at a better time. Because frankly speaking I am not that impressed after I tested Omarchy Linux. Everything was snappy. It is like back to DOS or Windows 3.11 era. ( Not quite but close ) It makes me wonder why Mac couldn't be like that. Apple Silicon is fast, no doubt about it. It isn't some benchmarks but even under emulation, compiling or other workload it is fast if not the fastest. So there are plenty of evidence it isn't benchmark specific which some people claims Apple is only fast on Geekbench. The problem is macOS is slow. And for whatever reason haven't improved much. I am hoping dropping support for x86 in next macOS meant they have time and excuses to do a lot of work on macOS under the hood. Especially with OOM and Paging.
- microtonal 9mo ago
  I have a ThinkPad besides my main MacBook. I recently switched to KDE, a full desktop environment, and it is just insane how much faster everything renders than on macOS. And that's on a relatively underpowered integrated Ryzen GPU. Window dragging is butter smooth on a 120Hz screen, which I cannot say of macOS (though it outright terrible with the recent Electron issue). Apple Silicon is awesome and was a game changer when it came out. Still very impressive that they have been able to keep the MacBook Air passively cooled since the first M1. But yeah, macOS is holding it back.
  - spockz 9mo ago
    Modern machines are so insanely fast, the UI should almost react before you do an action. My 5900X machine with relatively slow RAM running CachyOS actually almost feels as instant as DOS machines with incredible low latency. Instead, we get tons of layers of abstraction (Electron etc), combined with endpoint security software in the enterprise world that bring any machine to its knees by inspecting every I/O action. Zed is an awesome editor where every interaction is just “snappy”. I feel all the animations and transitions have been introduced to macOS just to paper over slowness. I’ve disabled them via the accessibility settings which helps in perceived snappiness a bit, but it also makes yank visible where performance is not up to par.
kgeist 9mo ago
Can't Windows/Linux pin background threads to specific cores on Intel too? So that your foreground app isn't slowed down by all the background activity going on? Or there's something else to it that I don't understand. I thought E cores' main advantage is that they use less power which is good for battery life on laptops. But the article makes it sound like main advantage of Apple Silicon is that it splits foreground/background workloads better. Isn't it something that can already be done without a P/E distinction?
- ctrlrsf 9mo ago
  Linux yes, of course.
- LtdJorge 9mo ago
  Yes, it's the job of the scheduler
- cosmic_cheese 9mo ago
  It’s both. Multithreading has been more ubiquitous in Mac apps for a long time thanks to Apple having offered mainstream multi-CPU machines very early on (circa 2000), predating even OS X itself, and has made a point of making multithreading easier in its SDK. By contrast multicore machines weren’t common in the Windows/x86 world until around the late 2000s with the boom of Intel’s Core series CPUs, but single core x86 CPUs persisted for several years following and Windows developer culture still hasn’t embraced multithreading as fully as its Mac counterpart has. This then made it dead simple for Mac developers to adopt task prioritization/QoS. Work was already cleanly split into threads, so it’s just a matter of specifying which are best suited for putting on e-cores and which to keep on P-cores. And overwhelmingly, Mac devs have done that. So the system scheduler is a good deal more effective than its Windows counterpart because third party devs have given it cues to guide it. The tasks most impactful to the user’s perception of snappiness remain on the P-cores, the E-cores stay busy with auxiliary work and keep the P-cores unblocked and able to sleep more quickly and often.
  - kgeist 9mo ago
    Windows has SetThreadPriority and SetThreadAffinityMask since at least Windows XP.
saagarjha 9mo ago
> 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% It’s about half, actually > The fact that an idle Mac has over 2,000 threads running in over 600 processes is good news I mean, only if they’re doing something useful
psanford 9mo ago
I'm curious how asahi linux manages scheduling across e cores and p cores. Has anyone done experiments with this? Edit: It looks like there was some discussion about this on the Asahi blog 2 years ago[0]. [0]: https://asahilinux.org/2024/01/fedora-asahi-new/ https://asahilinux.org/2024/01/fedora-asahi-new/
eviks 9mo ago
> 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 This doesn't make sense in a rather fundamental way - there is no way to design a real computer where doing some useless work is better than doing no work, just think about energy consumption and battery life since this is laptops. Or that's just resources your current app can't use Besides, they aren't that well engineered, bugs exist and last and come back, etc, so even when on average the impact isn't big, you can get a few photo analysis indexing going haywire for awhile and get stuck
- ahepp 9mo ago
  I think in the example the OP is making, the work is not useless. They're saying if you had a system doing the same work, with maybe 60 processes, you're better off splitting that into 600 processes and a couple thousand threads, since that will allow granular classification of tasks by their latency sensitivity
  - eviks 9mo ago
    But it is, he's talking about real systems with real processes in a generic way, not a singular hypothetical where suddenly all that work must be done, so you can also apply you general knowledge that some of those background processes aren't useful (but can't even be disabled due to system lockdown)
    - ua709 9mo ago
      I think you're right that the article didn't provide criteria for when this type of system is better or worse than another. For example, the cost of splitting a work into threads and switching between threads needs to be factored in. If that cost is very high, then the multi-thread system could very well be worse. And there are other factors too. However, given the trend in modern software engineering to break work into units and the fact that on modern hardware thread switches happen very quickly, being able to distribute that work across different compute clusters that make different optimization choices is a good thing and allows schedulers to get results closer to optimal. So really it boils down to if the gains in doing the work on different compute outweighs the cost splitting and distributing the work, then it's a win. And for most modern software on most modern hardware, the win is very significant. As always, YMMV
jwilliams 9mo ago
Although there is the consistent trap of tools that assign threads/workers based on the number of cores (e.g unit testing or bundling tools). This means the efficiency cores get dragged in and can absolutely tank the process. This was particularly pronounced on the M1 due to the 50/50 split. We reduced the number of workers on our test suite based on the CPU type and it sped up considerably.
Synaesthesia 9mo ago
I was quite impressed to learn that the E cores of the M1 are about as fast as an Intel i5 6600/i7 6700 CPU. And they've improved from there. That was literally my desktop CPU for a very long time.

271 points by ingve 9mo ago

tyleo 9mo ago

These processors are good all around. The P cores kick butt too. I ran a performance test back in October comparing M4 laptops against high-end Windows desktops, and the results showed the M-series chips coming out on top. https://www.tyleo.com/blog/compiler-performance-on-2025-devices https://www.tyleo.com/blog/compiler-performance-on-2025-devi...

murderfs 9mo ago
This is likely more of a Windows filesystem benchmark than anything else: there are fundamental restrictions on how fast file access can be on Windows due to filesystem filter drivers. I would bet that if you tried again with Linux (or even in WSL2, as long as you stay in the WSL filesystem image), you'd see significantly improved results.
- philistine 9mo ago
  Which still wouldn’t beat the Apple Silicon chips. Apple rules the roost.
  - Kuinox 9mo ago
    https://www.cpubenchmark.net/laptop.html https://www.cpubenchmark.net/laptop.html
    - philistine 9mo ago
      You click on laptop and somehow that's a gotcha, I click on single thread and the M5 is at the very top. What is that?
      - Kuinox 9mo ago
        You are seeing basically the lithography node used to make the CPU. Since Apple books more capacity than anyone else, they have their chip 5-6 months ahead of the market, you'll see chips with similar performance by core.
        philistine 9mo ago
        And what about the M3 Ultra, that sits at number 3 and came out ten months ago? Why was it not beaten five months ago? Might I add that the M3 Ultra is on an older node than the M5. And what about the A19 Pro, which is better at single core than every desktop chip in the world, and happens to be inside a phone! Apple has the best silicon team in the world. They choose perf per watt over pure perf, which means they don't win on multi-core, but they're simply the best in the world in the most complicated, difficult, and impossible metric to game: single core perf.
        Kuinox 9mo ago
        It's bench score on single thread is 0.6% better than the Intel Core Ultra 9 285K, which have a lower TDP and was released 6 months before. Boths use the same lithography node. If you look at the chip by their lithography node, the Apple silicons are the same than the others...
        SR2Z 9mo ago
        Apple's M-series chips are fantastic, but I do agree with you that it's mostly a combination of newer process and lots of cache. Even when they were new, they competed with AMD's high end desktop chips. Many years later, they're still excellent in the laptop power range - but not in the desktop power range, where chips with a lot of cache match it in single core performance and obliterate it in multicore. https://www.cpu-monkey.com/en/compare_cpu-apple_m4-vs-amd_ryzen_7_9800x3d https://www.cpu-monkey.com/en/compare_cpu-apple_m4-vs-amd_ry...
        deleted 9mo ago
cubefox 9mo ago
Here is a more recent comparison with Intel's new Panther Lake chips: https://www.tomsguide.com/computing/cpus/panther-lake-is-intels-m1-moment-but-can-it-beat-apple-silicon-we-put-these-new-chips-to-the-test https://www.tomsguide.com/computing/cpus/panther-lake-is-int...
- sys_64738 9mo ago
  Are the Intel systems plugged in when running those tests? Usually when Apple machines do the tests then the difference between battery/plugged in is small if any.
- dagmx 9mo ago
  Which still come out behind other than multi core, while using substantially more power. Those panther lake comparisons are from the top end PTL to the base M series. If they were compared to their comparative SKUs they’d be even further behind.
  - cubefox 9mo ago
    The article said the M5 has significantly higher single core CPU performance, Panther Lake has significantly higher GPU performance. The Panther Lake devices had OLED screens, which consume significantly more power than LCDs, so they were at a disadvantage. This was all mentioned in the article.
    - PunchyHamster 9mo ago
      So useless for what most laptops are used - working
    - dagmx 9mo ago
      Again, the Panther Lake devices here are the top end of Panther lake comparing against the base level M5. See the chart here for what the intel SKUs are: https://www.pcworld.com/article/3023938/intels-core-ultra-series-3-cpu-names-are-different-now-heres-what-they-mean.html https://www.pcworld.com/article/3023938/intels-core-ultra-se... They consume more power at the chip level. You can see this in Intels spec sheets. The base recommended power envelope of the PTL is the maximum power envelope of the M5. They’re completely different tiers. You’re comparing a 25-85W tier chip to a 5W-25W chip. They also only win when it comes to multi core whether that’s CPU or GPU. If they were fairly compared to the correct SoC (an M4 Pro) they’d come out behind on both multicore CPU and GPU. This was all mentioned in my comment addressing the article. This is the trick that apples competitors are using, by comparing across SKU ranges to grab the headlines. PTL is a strong chip, no doubt, but it’s still behind Apple across all the metrics in a like for like comparison.
etrvic 9mo ago
From your article it seems like you benchmark compile times. I am not an expert on the subject, but I don't see the point in comparing ARM compilation times with Intel. There are probably different tricks involved in compilation and the instructions set are not the same.
- tom_ 9mo ago
  I've often been suspicious of this too, having noticed that building one of my projects on Apple Silicon is way quicker than I'd expect relative to x64, given relative test suite run times and relative PassMark numbers. I don't know how to set up a proper cross compile setup on Apple Silicon, so I tried compiling the same code on 2 macOS systems and 1 Linux system, running the corresponding test suite, and getting some numbers. It's not exactly conclusive, and if I was doing this properly properly then I'd try a bit harder to make everything match up, but it does indeed look like using clang to build x64 code is more expensive - for whatever reason - than using it to build ARM code. Systems, including clang version and single-core PassMark: M4 Max Mac Studio, clang-1700.6.3.2 (PassMark: 5000) x64 i7-5557U Macbook Pro, clang-1500.1.0.2.5 (PassMark: 2290) x64 AMD 2990WX Linux desktop, clang-20 (PassMark: 2431) Single thread build times (in seconds). Code is a bunch of C++, plus some FOSS dependencies that are C, everything built with optimisation enabled: Mac Studio: 365 x64 Macbook Pro: 1705 x64 Linux: 1422 (Linux time excludes build times for some of the FOSS dependencies, which on Linux come prebuilt via the package manager.) Single thread test suite times (in seconds), an approximate indication of relative single thread performance: Mac Studio: 120 x64 Macbook Pro: 350 x64 Linux: 309 Build time/test time makes it look like ARM clang is an outlier: Mac Studio: 3.04 x64 Macbook Pro: 4.87 x64 Linux: 4.60 (The Linux value is flattered here, as it excludes dependency build times, as above. The C dependencies don't add much when building in parallel, but, looking at the above numbers, I wonder if they'd add up to enough when built in series to make the x64 figures the same.)
  - tom_ 8mo ago
    After tweaking the build process to build the same dependencies from source on Linux as on macOS: x64 Linux build: 1514 x64 Linux test: 307 x64 Linux build/test: 4.93 (Again, not a perfect test, as it still won't be exactly the same code, but the numbers are nevertheless pretty close!)
wpm 9mo ago
My M4 mini is probably the fastest computer/watt in my home. And it was the cheapest. Not even a bad little gaming machine on the rare occasion

roomey 9mo ago

Genuine question, when people talk about apple silicon being fast, is the comparison to windows intel laptops, or Mac intel architecture? Because, when running a Linux intel laptop, even with crowd strike and a LOT of corporate ware, there is no slowness. When blogs talk about "fast" like this I always assumed it was for heavy lifting, such as video editing or AI stuff, not just day to day regular stuff. I'm confused, is there a speed difference in day to day corporate work between new Macs and new Linux laptops? Thank you

newsclues 9mo ago
Power management with Mac’s is the big benefit, imo. It’s all about the perf per watt.
cj 9mo ago
For me it’s things like boot speed. How long does it take to restart the computer. To log out, and log back in with all my apps opening. Mac on intel feels like it was about 2x slower at these basic functions. (I don’t have real data points) Intel Mac had lag when opening apps. Silicon Mac is instant and always responsive. No idea how that compares to Linux.
- nottorp 9mo ago
  Hmm? Why do you restart your computer often enough to notice? Even Windows (or at least my install that doesn't have any crap besides visual studio on it) can run for weeks these days...
  - maccard 9mo ago
    My work laptop decided probably once a week to not go to sleep and just run its battery to 0. My work PC will decide to not idle and will spin up fans arbitrarily in the evenings so I shut it down when I’m not using it.
    - nottorp 8mo ago
      > My work laptop decided probably once a week to not go to sleep and just run its battery to 0. That reminds me that if Apple annoys me enough to switch back to linux at my main OS it will hurt on laptops :(

ricardobeat 9mo ago

> The fact that an idle Mac has over 2,000 threads running in over 600 processes is good news Not when one of those decides to wreck havoc - spotlight indexing issues slowly eating away your disk space, icloud sync spinning over and over and hanging any app that tries to read your Documents folder, Photos sync pegging all cores at 100%… it feels like things might be getting a little out of hand. How can anyone model/predict system behaviour with so many moving parts?

fragmede 9mo ago
and if it paid off, that would almost be acceptable! But no. After spotlight has indexed my /Applications folder, when I hit command-spacebar and type "preview.app", it takes ~4 seconds on my M4 laptop to search the sqlite database for it and return that entry. grumble
- admissionsguy 9mo ago
  TIL there is a search bar triggered by CMD+Space. After 15 long years.
  - rngfnby 9mo ago
    Too late. Apple has destroyed it. I just got my first ARM Mac to replace my work Win machine (what has MS done to Windows!?!? :'() Used to be I could type "display" and Id get right to display settings in settings. Now it shows thousands of useless links to who knows what. Instead I have to type "settings" and then, within settings, type "display" Still better than the Windows shit show. Honestly, a well setup Linux machine has better user experience than anything on the market today.
    - chaostheory 9mo ago
      > a well setup Linux machine has better user experience than anything on the market today We probably have to preface that with “for older people”. IMO Linux has changed less UX wise than either Windows or MacOS in recent years

amelius 9mo ago

That's just framing. A different wording could be: by moving more work to slow (but power efficient) cores, the other cores (let's call them performance cores) are free to do other stuff.

drob518 9mo ago

Does anyone have any insight into the MacOS scheduler and the algorithm it uses to place threads on E vs. P cores? Is it as simple as noting whether a thread was last suspended blocking on I/O or for a time slice timeout and mapping I/O blockers to E cores and time slice blockers to P cores? Or does the programmer indicate a static mapping at thread creation? I write code on a Mac all the time, but I use Clojure and all the low level OS decisions are opaque to me.

sys_64738 9mo ago
The article mentions P or E is generally decided by if it's a "background" process (whatever than means). Possible some (undocumented) designation in code or directive to the compiler of the binary decides this at compile time.
- masklinn 9mo ago
  > whatever than means It’s a QoS level: https://developer.apple.com/documentation/dispatch/dispatchqos https://developer.apple.com/documentation/dispatch/dispatchq...
detourdog 9mo ago
https://developer.apple.com/videos/play/tech-talks/110147/ https://developer.apple.com/videos/play/tech-talks/110147/
- drob518 9mo ago
  Excellent, thanks!
masklinn 9mo ago
The baseline is static: low QoS tasks are dispatched to the E cores, while high QoS tasks are dispatched to P cores. IIRC high QoS cores can migrate to the E cores if all P cores are loaded, but my understanding is that the lowest QoS tasks (background) never get promoted to P cores.

sys_64738 9mo ago

My M2 MBA doesn't have a fan but literally smokes the majority on Intel systems which are space heaters this time of year. Those legacy x86 apps don't really exist for the majority of people anymore.

ProllyInfamous 9mo ago
If you place 1mm thermal pads between the sinks and the case, the CPUs/GPUs won't throttle as readily. At least for my M3 MBA (check your actual clearance). I replaced a MacPro5,1 with an M2Pro — which uses soooooo much less energy performing similarly mundane tasks (~15x+). Idle is ~25W v. 160W
- zozbot234 9mo ago
  Caution: don't put the laptop in your lap if you've done this. There's a reason it doesn't ship like that out of the box.
  - ProllyInfamous 8mo ago
    You already don't want notebooks sitting on your lap (safe radiation exposure limits from WiFi / Bluetooth), which is why they're no longer referred to as "laptops" (by OEMs). But if you're commenting about temperature / burns — the bottom of the MBP doesn't get noticeably warmer (at all), likely because the large metal case is such an efficient dissipator/sink.
    - zozbot234 8mo ago
      It's going to get hot if you peg the CPU/GPU at 100% for long enough. Just a matter of physics.
      - ProllyInfamous 8mo ago
        The casebottom of my 15" MBAir has never exceeded 32°C — and that's sitting on a bed. Just a matter of physics: conductive case has orders of magnitude more thermal mass. It also helps that Apple Silicon processors consumer orders of magnitude less power than most competitor OEMs. Pegged out the entire machine uses less energy than my former notebook's GPU, alone.

ksec 9mo ago

>If you use an Apple silicon Mac I’m sure you have been impressed by its performance. This article couldn't have come at a better time. Because frankly speaking I am not that impressed after I tested Omarchy Linux. Everything was snappy. It is like back to DOS or Windows 3.11 era. ( Not quite but close ) It makes me wonder why Mac couldn't be like that. Apple Silicon is fast, no doubt about it. It isn't some benchmarks but even under emulation, compiling or other workload it is fast if not the fastest. So there are plenty of evidence it isn't benchmark specific which some people claims Apple is only fast on Geekbench. The problem is macOS is slow. And for whatever reason haven't improved much. I am hoping dropping support for x86 in next macOS meant they have time and excuses to do a lot of work on macOS under the hood. Especially with OOM and Paging.

microtonal 9mo ago
I have a ThinkPad besides my main MacBook. I recently switched to KDE, a full desktop environment, and it is just insane how much faster everything renders than on macOS. And that's on a relatively underpowered integrated Ryzen GPU. Window dragging is butter smooth on a 120Hz screen, which I cannot say of macOS (though it outright terrible with the recent Electron issue). Apple Silicon is awesome and was a game changer when it came out. Still very impressive that they have been able to keep the MacBook Air passively cooled since the first M1. But yeah, macOS is holding it back.
- spockz 9mo ago
  Modern machines are so insanely fast, the UI should almost react before you do an action. My 5900X machine with relatively slow RAM running CachyOS actually almost feels as instant as DOS machines with incredible low latency. Instead, we get tons of layers of abstraction (Electron etc), combined with endpoint security software in the enterprise world that bring any machine to its knees by inspecting every I/O action. Zed is an awesome editor where every interaction is just “snappy”. I feel all the animations and transitions have been introduced to macOS just to paper over slowness. I’ve disabled them via the accessibility settings which helps in perceived snappiness a bit, but it also makes yank visible where performance is not up to par.

kgeist 9mo ago

Can't Windows/Linux pin background threads to specific cores on Intel too? So that your foreground app isn't slowed down by all the background activity going on? Or there's something else to it that I don't understand. I thought E cores' main advantage is that they use less power which is good for battery life on laptops. But the article makes it sound like main advantage of Apple Silicon is that it splits foreground/background workloads better. Isn't it something that can already be done without a P/E distinction?

ctrlrsf 9mo ago
Linux yes, of course.
LtdJorge 9mo ago
Yes, it's the job of the scheduler
cosmic_cheese 9mo ago
It’s both. Multithreading has been more ubiquitous in Mac apps for a long time thanks to Apple having offered mainstream multi-CPU machines very early on (circa 2000), predating even OS X itself, and has made a point of making multithreading easier in its SDK. By contrast multicore machines weren’t common in the Windows/x86 world until around the late 2000s with the boom of Intel’s Core series CPUs, but single core x86 CPUs persisted for several years following and Windows developer culture still hasn’t embraced multithreading as fully as its Mac counterpart has. This then made it dead simple for Mac developers to adopt task prioritization/QoS. Work was already cleanly split into threads, so it’s just a matter of specifying which are best suited for putting on e-cores and which to keep on P-cores. And overwhelmingly, Mac devs have done that. So the system scheduler is a good deal more effective than its Windows counterpart because third party devs have given it cues to guide it. The tasks most impactful to the user’s perception of snappiness remain on the P-cores, the E-cores stay busy with auxiliary work and keep the P-cores unblocked and able to sleep more quickly and often.
- kgeist 9mo ago
  Windows has SetThreadPriority and SetThreadAffinityMask since at least Windows XP.

saagarjha 9mo ago

> 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% It’s about half, actually > The fact that an idle Mac has over 2,000 threads running in over 600 processes is good news I mean, only if they’re doing something useful

psanford 9mo ago

I'm curious how asahi linux manages scheduling across e cores and p cores. Has anyone done experiments with this? Edit: It looks like there was some discussion about this on the Asahi blog 2 years ago[0]. [0]: https://asahilinux.org/2024/01/fedora-asahi-new/ https://asahilinux.org/2024/01/fedora-asahi-new/

eviks 9mo ago

> 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 This doesn't make sense in a rather fundamental way - there is no way to design a real computer where doing some useless work is better than doing no work, just think about energy consumption and battery life since this is laptops. Or that's just resources your current app can't use Besides, they aren't that well engineered, bugs exist and last and come back, etc, so even when on average the impact isn't big, you can get a few photo analysis indexing going haywire for awhile and get stuck

ahepp 9mo ago
I think in the example the OP is making, the work is not useless. They're saying if you had a system doing the same work, with maybe 60 processes, you're better off splitting that into 600 processes and a couple thousand threads, since that will allow granular classification of tasks by their latency sensitivity
- eviks 9mo ago
  But it is, he's talking about real systems with real processes in a generic way, not a singular hypothetical where suddenly all that work must be done, so you can also apply you general knowledge that some of those background processes aren't useful (but can't even be disabled due to system lockdown)
  - ua709 9mo ago
    I think you're right that the article didn't provide criteria for when this type of system is better or worse than another. For example, the cost of splitting a work into threads and switching between threads needs to be factored in. If that cost is very high, then the multi-thread system could very well be worse. And there are other factors too. However, given the trend in modern software engineering to break work into units and the fact that on modern hardware thread switches happen very quickly, being able to distribute that work across different compute clusters that make different optimization choices is a good thing and allows schedulers to get results closer to optimal. So really it boils down to if the gains in doing the work on different compute outweighs the cost splitting and distributing the work, then it's a win. And for most modern software on most modern hardware, the win is very significant. As always, YMMV

jwilliams 9mo ago

Although there is the consistent trap of tools that assign threads/workers based on the number of cores (e.g unit testing or bundling tools). This means the efficiency cores get dragged in and can absolutely tank the process. This was particularly pronounced on the M1 due to the 50/50 split. We reduced the number of workers on our test suite based on the CPU type and it sped up considerably.

Synaesthesia 9mo ago

I was quite impressed to learn that the E cores of the M1 are about as fast as an Intel i5 6600/i7 6700 CPU. And they've improved from there. That was literally my desktop CPU for a very long time.