▲ 271 points
back
259 comments
> 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
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
> (...) where doing some useless work is better than doing no work (...)
This take expresses a fundamental misunderstanding of the whole problem domain. There is a workload comprised of hundreds of processes, some of which multithreaded, that need to be processed. That does not change nor go away. You have absolutely no suggestion that any of those hundreds of processes is "useless". What you will certainly have are processes that will be waiting for IO, but waiting for a request to return a response is not useless.
> This doesn't make sense in a rather fundamental way - there is no way to design a real compute
Hmm I guess the apple silicon laptops don't exist? Did I dream that I bought one year? Maybe I did - it has been a confusing year.
I would say a good number of those processes/cores are something you don't want running. And you can't turn them off unless you can modify the boot partition to disable the launch configs.
sigh.
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...
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.
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.
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
Here is a more recent comparison with Intel's new Panther Lake chips: https://www.tomsguide.com/computing/cpus/panther-lake-is-int...
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.
Check out the scheduler documentation that Apple has in the xnu repo. https://github.com/apple-oss-distributions/xnu/blob/main/doc...
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.
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.
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
I use pretty much all platforms and architectures as my "daily drivers" - x64, Apple Silicon, and ARM Cortex, with various mixtures of Linux/Mac/Windows.
When Apple released Apple Silicon, it was a huge breath of fresh air - suddenly the web became snappy again! And the battery lasted forever! Software has bloated to slow down MacBooks again, RAM can often be a major limiting factor in performance, and battery life is more variable now.
Intel is finally catching up to Apple for the first time since 2020. Panther Lake is very competitive on everything except single-core performance (including battery life). Panther Lake CPU's arguably have better features as well - Intel QSV is great if you compile ffmpeg to use it for encoding, and it's easier to use local AI models with OpenVINO than it is to figure out how to use the Apple NPU's. Intel has better tools for sampling/tracing performance analysis, and you can actually see you're loading the iGPU (which is quite performant) and how much VRAM you're using. Last I looked, there was still no way to actually check if an AI model was running on Apple's CPU, GPU, or NPU. The iGPU's can also be configured to use varying amounts of system RAM - I'm not sure how that compares to Apple's unified memory for effective VRAM, and Apple has higher memory bandwidth/lower latency.
I'm not saying that Intel has matched Apple, but it's competitive in the latest generation.
Apple silicon is very fast per size/watt. The mind blowing thing is the macbook air that has weighs very little, doesn't have a fan, and feels competitive with top of the line desktop pcs.
First of all, Apple CPUs are not the fastest. In fact top 20 fastest CPUs right now is probably an AMD and Intel only affair.
Apples CPUs are most powerful efficient however, due to a bunch of design and manufacturing choices.
But to answer your question, yes Windows 11 with modern security crap feels 2-3 slower than vanilla Linux on the same hardware.
New Mac arm user here.
Replaced a good Windows machine (Ryzen 5? 32 Gb) and I have a late intel Mac and a Linux workstation (6 core Ryzen 5, 32 Gb).
Obviously the Mac is newer. But wow. It's faster even on things that CPU shouldn't matter, like going through a remote samba mount through our corporate VPN.
- Much faster than my intel Mac
- Faster than my Windows
- Haven't noticed any improvements over my Linux machines, but with my current job I no longer get to use them much for desktop (unfortunately).
Of course, while I love my Debian setup, boot up is long on my workstation; screensaver/sleep/wake up is a nightmare on my entertainment box (my fault, but common!). The Mac just sleeps/wakes up with no problems.
The Mac (smallest air) is also by far the best laptop Ive ever had from a mobility POV. Immediate start up, long battery, decent enough keyboard (but If rather sacrifice for a longer keypress)
I've used Linux as a daily driver for 6 months and I am now back to my M1 Max for the past month.
I didn't find any reply mentioning the easy of use, benefits and handy things the mac does and Linux won't. Spotlight, Photos app with all the face recognition and general image index, contact sync, etc. Takes ages to setup those on Linux and with macs everything just works with an Apple account. So I wonder if Linux had to do all this background stuff, if it would be able to run smoothly as Macs run this days.
For context: I was running Linux for 6 months for the first time in 10 years (which I was daily driving macs). My M1 Max still beats my full tower gaming PC, which I was using linux at. I've used Windows and Linux before, and Windows for gaming too. My Linux setup was very snappy without any corporate stuff. But my office was getting warm because of the PC. My M1 barely turn on the fans, even with large DB migrations and other heavy operation during software development.
I think you should spend some time looking at actual laptop review coverage before asking questions like this.
There are dozens of outlets out there that run synthetic and real world benchmarks that answer these questions.
Apple’s chips are very strong on creative tasks like video transcoding, they have the best single core performance as well as strong multi-core performance. They also have top tier power efficiency, battery life, and quiet operation, which is a lot of what people look for when doing corporate tasks.
Depending on the chip model, the graphics performance is impressive for the power draw, but you can get better integrated graphics from Intel Panther Lake, and you can get better dedicated class graphics from Nvidia.
Some outlets like Just Josh tech on YouTube are good at demonstrating these differences.
I haven’t used a laptop other than a mac in 10 years. I remember being extremely frustrated with the Intel macs. What I hated most was getting into video meetings, which would make the Intel CPU sound like a 747 taxiing.
The switch from a top spec, new Intel Mac to a base model M1 Macbook Air was like a breath of fresh air. I still use that 5 year old laptop happily because it was such a leap forward in performance. I dont recall ever being happy with a 5 year old device.
I think you're bringing up a great question here. If you ask a random person on the street "is your laptop fast", the answer probably has more to do with what software that person is running, than what hardware.
My Apple silicon laptop feels super fast because I just open the lid and it's running. That's not because the CPU ran instructions super fast, it's because I can just close the lid and the battery lasts forever.
Somehow my 2011 MacBook Pro was the fastest laptop I had ever used.
After I put an SSD in it, that is.
I wonder what my Apple silicon laptop is even doing sometimes.
Power management with Mac’s is the big benefit, imo.
It’s all about the perf per watt.
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.
You can notice that memory bandwidth advantage even in workloads like photo editing and code compilation. That and the performance cores reserved for foreground compute, on top of the usual "Linux sucks at swap" (was it fixed? I haven't enabled swap on my Linux machines for ages by now), does make a day-to-day difference in my usage.
I love apple and mainly use one for personal use, but apple users consistently overrate how fast their machines are. I used to see sentiment like "how will nvidia ever catch up with apples unified silicon approach" a few years ago. But if you just try nvidia vs apple and compare on a per dollar level, nvidia is so obviously the winner.
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].
> 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?
My pet peeve with the modern macOS architecture & its 600 coordinating processes & Grand Central Dispatch work queues is debugability.
Fifteen years ago, if an application started spinning or mail stopped coming in, you could open up Console.app and have reasonable confidence the app in question would have logged an easy to tag error diagnostic. This was how the plague of mysterious DNS resolution issues got tied to the half-baked discoveryd so quickly.
Now, those 600 processes and 2000 threads are blasting thousands of log entries per second, with dozens of errors happening in unrecognizable daemons doing thrice-delegated work.
It's slowly approaching what SRE has been dealing with for distributed systems... You just have to accept things won't be fully understood and whip out your statistical tooling, it's ok. And if they get the engineering right, you might still keep your low latency corner where only an understandable set of things are allowed.
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
for me it’s iMessage, it gets out of sync way too often and then it eats the CPU away
I wonder if that explains my intermittent keyboard lockups on MacOS? The keyboard just failing to work for a few minutes. The keyboard, a logitec one with a dongle, never has problems under windows or linux. M1 mac mini, not upgraded to Tahoe yet.
Sounds like typical Windows experience
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.
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
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?
One thing that distinguishes macOS here is that the mach kernel has the concept of “vouchers” which helps the scheduler understand logical calls across IPC boundaries. So if you have a high-priority (UserInitiated) process, and it makes an IPC call out to a daemon that is usually a low-priority background daemon, the high-priority process passes a voucher to the low-priority one, which allows the daemon’s ipc handling thread to run high-priority (and thus access P-cores) so long as it’s holding the voucher.
This lets Apple architect things as small, single-responsibility processes, but make their priority dynamic, such that they’re usually low-priority unless a foreground user process is blocked on their work. I’m not sure the Linux kernel has this.
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.
It's the combination of the two that yields the best of both worlds.
Android SoCs have adopted heterogenous CPU architectures ("big.LITTLE" in the ARM sphere) years before Apple, and as a result, there have been multiple attempts to tackle this in Linux. The latest, upstream, and perhaps the most widely deployed way of efficiently using such processors involves using Energy-Aware Scheduling [1]. This allows the kernel to differentiate between performant and efficient cores, and schedule work accordingly, avoiding situations in which brief workloads are put on P cores and the demanding ones start hogging E cores. Thanks to this, P cores can also be put to sleep when their extra power is not needed, saving power.
One advantage macOS still has over Linux is that its kernel can tell performance-critical and background workloads apart without taking guesses. This is beneficial on all sorts of systems, but particularly shines on those heterogenous ones, allowing unimportant workloads to always occupy E cores, and freeing P cores for loads that would benefit from them, or simply letting them sleep for longer. Apple solved this problem by defining a standard interface for the user-space to communicate such information down [2]. As far as I'm aware, Linux currently lacks an equivalent [3].
Technically, your application can still pin its threads to individual cores, but to know which core is which, it would have to parse information internal to the scheduler. I haven't seen any Linux application that does this.
[1] https://www.kernel.org/doc/html/latest/scheduler/sched-energ...
[2] https://developer.apple.com/library/archive/documentation/Pe...
[3] https://github.com/swiftlang/swift-corelibs-libdispatch?tab=...
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.
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.
> 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.