For years the ARM-vs-x86 laptop conversation ended with "sure, but check the benchmarks against a real workload." We finally did.
The test
Same repository, same cargo build --release, same dependency cache warmed identically, run three times per machine with the median reported.
| Machine | Chip | Build time | Battery (video loop) | | --- | --- | --- | --- | | Machine A | ARM, 12-core | 41s | 19h 10m | | Machine B | ARM, 10-core | 47s | 17h 40m | | Machine C | x86, 14-core | 44s | 9h 5m | | Machine D | x86, 8-core | 58s | 8h 30m |
The headline result
The fastest ARM machine beat every x86 machine in the roundup on compile time and more than doubled the best x86 battery life. That's the part that used to be theoretical — compiled-language performance parity, not just efficiency-per-watt on paper.
- Rust's LLVM backend has closed most of the codegen gap on ARM targets over the last two major toolchain releases.
- Unified memory architectures cut cache-miss penalties during large monomorphized builds.
- Thermal headroom matters more than raw core count once you're past 8 cores on a laptop chassis.
The build that used to be an excuse to get coffee is now a build you can watch finish.
Where x86 still wins
Emulated or Rosetta-style compatibility layers for legacy toolchains, and anything depending on AVX-512 code paths that haven't been ported. If your build pipeline is pure Rust or Go, none of that applies to you anymore.
The gap didn't close gradually — it closed within a single chip generation. If your last "ARM isn't ready yet" benchmark is more than 18 months old, it's wrong now.