Why did the jump from Intel MacBooks to Apple Silicon feel that huge? - Paul Herrmann

Where I know this from RWTH course RWTH courses: Digital Signal Processing, Special Purpose Operating Systems, Microcontroller Programming and Debugging, Betriebssysteme, and Compilerbau<br>Own research Own reading: AnandTech's M1/A14 deep dives, Dougall Johnson's Firestorm and Rosetta 2 teardowns, Howard Oakley's QoS measurements, the RISC-vs-CISC measurement paper by Blem et al. (HPCA 2013), plus my own switch to an M3 Pro<br>My first MacBook was an M3 Pro. So I never personally lived through the Intel-to-M1 moment that Mac users describe with a certain glow in their eyes. But I came from state-of-the-art Intel and Windows notebooks, and even three chip generations into Apple Silicon, the difference floored me: a laptop that is instant, silent, cool on my lap, and the battery life is notably better. My old machines could win benchmarks too. They just never felt like this.<br>The cleanest illustration of the jump is a machine I never owned: the 2020 MacBook Air. Apple sold it twice in the same year, in the same chassis. The early-2020 Intel version ran hot, throttled under load, and became famous because its fan was not even attached to the heatsink with a heatpipe; it mostly blew air around the case (Macworld). The late-2020 M1 version had no fan at all. Same shape, silent, cool, and roughly twice as fast in single-core and about 2.6x in multi-core in Geekbench 6 (2,347/8,341 vs. 1,197/3,150 as the averages at the time of writing, M1 Air and Intel i7 Air on Geekbench Browser). Apple’s battery rating went from 11 to 15 hours of web browsing (Intel Air, M1 Air).<br>Same case, one year apart, a different class of machine. How? That question turns out to be a nice tour through computer architecture, so this post became long. Every section introduces the concepts it needs, and you can stop after any of them with a correct, just less detailed, picture.<br>Wide beats fast: what a CPU core actually does all day<br>To understand the first big reason, I need to introduce how a modern CPU core is organized, because “8-wide decode” means nothing without that background.<br>A CPU executes a program as a stream of instructions: load this value from memory, add these two numbers, store the result, jump if the result was zero. The naive picture is that the core does these one after another, one per clock tick. Real cores stopped working like that decades ago, for two reasons.<br>First, pipelining . Executing one instruction involves several steps: fetch it from memory, decode what it means, execute it, write the result back. The execute step happens in the ALU (arithmetic logic unit) , the circuit that actually performs the calculation; the decode step before it figures out which operation the instruction bits encode and sets the control signals accordingly, effectively wiring up the ALU in preparation for the execution. Instead of finishing one instruction completely before touching the next, the core works like an assembly line: while instruction 1 is executing, instruction 2 is being decoded and instruction 3 is being fetched. Every station of the line is busy all the time.<br>Second, superscalar execution . A core does not have one ALU, it has many: several integer ALUs, several floating-point/vector units, several load/store units. So it can start multiple instructions in the same clock cycle, as long as it can find instructions that do not depend on each other. This is where the term “width” comes from: a 4-wide core can feed up to four instructions per cycle into its execution units.<br>The catch is the phrase “do not depend on each other”. If instruction B needs the result of instruction A, B has to wait. These conflicts are called hazards , and the worst ones involve memory: a load that misses the cache and has to go to DRAM can take hundreds of cycles. In a naive in-order core, everything behind that load just stalls: hundreds of cycles are spent doing nothing but waiting for the data to arrive, while most of the core’s transistors sit idle.<br>The answer is out-of-order execution (OoO) . The core keeps a window of upcoming instructions, in Apple’s case hundreds of them, and continuously scans it for instructions whose inputs are ready, executing those immediately even if previous instructions are still waiting. To keep the program’s illusion of sequential execution intact, results are held in a structure called the reorder buffer (ROB) and only “retired” in original program order. The bigger the ROB, the more independent work the core can find to hide the latency of a slow memory access.<br>One obstacle is still missing from this picture: branches . A significant share of all instructions are conditional jumps (an if, a loop condition), and until such an instruction is actually executed, the core does not know where the instruction stream continues. A pipeline that waited at every branch would be idle most of the time, and an out-of-order window of hundreds...