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-devi...
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.
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
> 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?
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.
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.
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].
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?
> 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
>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.
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.
> 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