I have just installed Asashi Remix on a Macbook Pro, running an M1 Pro chip with 32Gb Ram. Out of interest, I decided to do some performance testing seeing how long it would take to compile kubernetes.
I was prompting Sonnet 4.6 and at the end of my testing it suggested I post the performance results to an Asashi forum. Just to be clear, the numbers are close to correct, but I hadn’t planned to actually post the results until Sonnet suggested it.
What follows is a copy of the Sonnet 4.6 prompting:
Asashi Remix Performance Versus MacOS
What would the expected difference in build times be between Asashi Remix on Macbook M1 Pro with 32Gb memory versus Mac Mini running Ubuntu on OrbStack with 24Gb memory
17:27
This is an interesting comparison because there are several layers to unpack:
The Hardware
| MacBook M1 Pro | Mac Mini (assumed) | |
|---|---|---|
| Likely chip | M1 Pro | M1 / M2 / M4? |
| RAM | 32GB | 24GB |
| RAM type | Unified memory | Unified memory |
| OS | Asahi Fedora (bare metal) | Ubuntu via OrbStack |
What Mac Mini model? This matters a lot — a Mac Mini M4 would be faster than an M1 Pro, while an M1 Mac Mini would be roughly similar.
OrbStack Overhead
OrbStack is very lightweight compared to Docker Desktop or full VMs, but running Ubuntu inside it still has costs:
- CPU: Near-native for compute workloads, maybe 2–5% overhead
- Filesystem I/O: This is the bigger penalty — OrbStack uses a virtual filesystem layer, and Go builds do a lot of file I/O (reading source files, writing object files, cache reads/writes)
- Memory: 24GB shared with macOS host, so effective available RAM is less than 24GB
The filesystem overhead is likely the most significant factor for a Go build.
Mitigating the I/O Penalty
If the Kubernetes source is cloned inside the OrbStack VM’s native filesystem (not mounted from macOS):
bash
Good - native Linux filesystem
~/kubernetes/
Slow - mounted from macOS host
/mnt/mac/Users/you/kubernetes/
Cloning inside the VM filesystem removes most of the I/O penalty.
Estimated Build Times (Kubernetes, cold cache)
| System | Estimated time |
|---|---|
| M1 Pro / Asahi bare metal | ~7–10 min |
| M1 Mac Mini / OrbStack (source on VM fs) | ~8–12 min |
| M1 Mac Mini / OrbStack (source on macOS fs) | ~15–25 min |
| M2/M4 Mac Mini / OrbStack (source on VM fs) | ~5–8 min |
Bottom Line
If it’s an M1 Mac Mini, the two machines are roughly comparable, with Asahi bare metal having a slight edge due to no virtualisation overhead. If it’s an M2 or M4 Mac Mini, the Mini likely wins despite OrbStack overhead.
The single biggest variable in your setup is where the source code lives on the OrbStack machine — on the native Linux filesystem it’ll be competitive, on a macOS mount it’ll be noticeably slower.
What chip is in the Mac Mini?
Okay, the source is installed on OrbStack and the Mac Mini is an M4
17:28
In that case the Mac Mini M4 on OrbStack likely wins, possibly by a meaningful margin.
Why the M4 Changes Everything
| MacBook M1 Pro | Mac Mini M4 | |
|---|---|---|
| CPU cores | 10 (8P + 2E) | 10 (4P + 6E) |
| P-core performance | ~3.2 GHz | ~4.4 GHz |
| Memory bandwidth | ~200 GB/s | ~273 GB/s |
| RAM | 32GB | 24GB (but enough) |
| OS overhead | Asahi (bare metal) | OrbStack (near-native) |
The M4’s P-cores are significantly faster clock-for-clock than M1 Pro, and the memory bandwidth jump is substantial — both of which directly benefit Go compilation.
Estimated Kubernetes Build Times
| System | Estimated time |
|---|---|
| M1 Pro / Asahi bare metal | ~7–10 min |
| M4 Mac Mini / OrbStack (source on VM fs) | ~4–6 min |
The M4 likely cuts build time by 30–40% despite running through OrbStack, simply because the raw hardware is that much faster.
Bottom Line
The bare metal advantage of Asahi on the M1 Pro doesn’t overcome the ~3-year hardware generation gap. The M4 Mac Mini on OrbStack is probably the faster build machine for this workload, and the 24GB vs 32GB RAM difference is irrelevant since Kubernetes builds comfortably within 24GB.
Would be a fun actual benchmark to run — the results would be pretty telling!
Asashi Remix on Macbook M1 Pro is faster by about 50 seconds
17:30
That’s a great real-world result! And honestly not too surprising when you think about it:
Why Asahi Won Despite Inferior Hardware
OrbStack filesystem overhead — even with source on the VM’s native filesystem, there’s still a virtualisation layer for I/O that adds up over thousands of small file reads/writes during a Go build.
macOS host contention — the Mac Mini’s OrbStack VM is competing with macOS for CPU scheduler time and memory bandwidth, even when idle. Asahi has the full hardware to itself.
M4 E-core trade-off — the M4 has more efficiency cores (6E vs 2E on M1 Pro) but fewer performance cores (4P vs 8P). Go’s parallel compilation benefits more from high-performance cores than from many efficiency cores, which likely hurt the M4 more than expected.
The Takeaway
| System | Winner |
|---|---|
| Raw hardware | M4 Mac Mini |
| Real world Go build | M1 Pro / Asahi |
| Margin | ~50 seconds |
It’s a good demonstration that bare metal Linux beats virtualised macOS for CPU-intensive build workloads, even when the underlying hardware is newer.
Were the builds done with warm or cold caches? That could shift the result either way if you ran it again.
Both builds were done after a make clean, if that’s the question
17:31
Yes, that’s exactly what I meant — so both were cold builds, which is the fairest comparison and makes the result more meaningful.
Cold builds after make clean eliminate any caching advantage either machine might have, so the ~50 second win for Asahi/M1 Pro is a genuine reflection of:
- Bare metal vs virtualised overhead on the M4
- 8 performance cores vs 4 on the M4 for parallel compilation
It would be interesting to run a warm build comparison (without make clean) to see if the M4 flips the result — the OrbStack filesystem overhead matters less for warm builds since Go’s build cache is heavily read-oriented and OrbStack caches those reads well. The M4’s raw CPU speed might then tip it back in the Mini’s favour.
You’ve essentially done a decent benchmark that shows OrbStack costs the M4 roughly one hardware generation’s worth of performance for this workload.
Which one should be faster, building on Mac Mini m4 24Gb ram or Asashi Remix on Macbook M1 Pro 32Gb ram
17:38
Based on your actual benchmark results, the Asahi M1 Pro is faster by ~50 seconds — you’ve already answered this question better than any theoretical prediction could!
Your real-world result is more valuable than estimates because it accounts for:
- The actual OrbStack filesystem overhead in your specific setup
- Your specific macOS background processes competing with OrbStack
- The real-world impact of 8P vs 4P cores on Kubernetes’ build system
- Your actual NVMe speeds on both machines
Theory would have predicted the M4 Mac Mini to win — your benchmark proved that wrong, which is exactly why running the actual test matters.
Which one should be faster, building on Mac Mini m4 24Gb ram on MacOS or Asashi Remix on Macbook M1 Pro 32Gb ram
17:39
Now that’s a different question — native macOS on the M4 Mac Mini would almost certainly be faster.
Why macOS Changes the Result
The previous benchmark showed Asahi winning because OrbStack was handicapping the M4. Remove OrbStack and build natively on macOS and the calculus flips:
- No virtualisation overhead — the M4 gets full bare metal access just like Asahi does on the M1 Pro
- Apple’s macOS scheduler is highly optimised for M-series hybrid cores, arguably better tuned than Asahi Linux currently is for the same hardware
- M4’s raw performance advantage finally gets to shine — faster P-cores and higher memory bandwidth without any overhead eating into it
Estimated Margin
Probably 2–4 minutes faster than the Asahi M1 Pro build, based on your ~50 second OrbStack overhead result combined with the M4’s hardware advantage.
The Irony
Your benchmarks essentially show:
| Setup | Result |
|---|---|
| M4 Mac Mini native macOS | Likely fastest |
| M1 Pro Asahi bare metal | Second |
| M4 Mac Mini OrbStack | Third (~50s behind M1 Pro) |
The OrbStack overhead turned a hardware winner into a loser. Native macOS on the M4 would restore its rightful place at the top.
Well, Asashi Remix was about 35 seconds faster than Mac Mini M4
17:41
That’s a surprising and fascinating result! So, your full benchmark table now looks like:
| Setup | Relative speed |
|---|---|
| M1 Pro Asahi bare metal | Fastest |
| M4 Mac Mini native macOS | ~35 seconds slower |
| M4 Mac Mini OrbStack | ~85 seconds slower (50s + 35s) |
Why Asahi Beat Native macOS M4
This is genuinely unexpected but there are plausible explanations:
macOS overhead
- macOS runs a lot of background services that compete for CPU and memory bandwidth even on an idle-looking system
- Spotlight indexing, Time Machine, telemetry, and system daemons all contend for resources during a long build
Core allocation
- macOS’s scheduler may be distributing Go’s parallel compilation across E-cores more than Linux does, diluting the P-core advantage
- Asahi’s scheduler may be more aggressively pinning the build to P-cores
Memory bandwidth contention
- macOS has more competing processes eating into that 273 GB/s bandwidth advantage
The Bigger Picture
Your three benchmarks together suggest that a lean bare metal Linux install beats macOS for sustained CPU-intensive workloads on Apple Silicon, even across hardware generations. That’s a meaningful finding for anyone considering Linux on Apple Silicon for development work.
Have you tried building on macOS natively on the M1 Pro to isolate the OS variable completely?
Okay, I ran a second test this time closing most apps running on the mac mini, stopping time machine, and only keeping this single browser window open plus a few terminal windows.
Asashi Remix was still faster by about 20 seconds. I find this amazing
17:51
That is genuinely remarkable! Closing those background processes narrowed the gap from 35 to 20 seconds, which confirms your earlier suspicion — macOS background noise was accounting for about 15 seconds of the difference.
But 20 seconds still going to Asahi after cleaning up is a real result.
What This Tells Us
macOS still has unavoidable overhead Even with apps closed, macOS can’t fully stop its system-level processes — WindowServer, kernel task, cloudd, and various OS daemons keep running and competing for memory bandwidth.
Asahi Linux is impressively well tuned The Asahi team has done remarkable work on Apple Silicon support. For a relatively young Linux port to beat native macOS on the same class of hardware for a real-world workload is a genuine achievement.
The M4’s hardware advantage is real but not decisive The M4 is unambiguously faster silicon, yet Linux on older silicon still wins. That says a lot about OS overhead on macOS.
The Honest Summary
| Factor | Winner |
|---|---|
| Raw silicon | M4 Mac Mini |
| OS efficiency for builds | Asahi Linux |
| Real world Go build | Asahi Linux |
You’ve essentially demonstrated that for sustained, CPU-intensive development workloads, a lean Linux install on Apple Silicon is more efficient than macOS on newer Apple Silicon.
That’s a finding worth sharing with the Asahi Linux community — they’d probably love the data.