out-of-order execution

Think of a kitchen that takes orders in sequence and serves plates in that same sequence to each table — but inside, the cooks start whichever order's ingredients are ready first, not strictly in the order taken. Diners never notice the internal shuffling because the plates still arrive in order. Out-of-order execution (OoO) is a CPU doing exactly this: it executes ready instructions as soon as their inputs are available, even if earlier instructions are still stalled, yet it makes the final results appear in the original program order.

Mechanically, an out-of-order core has three phases. (1) In-order front end: instructions are fetched, decoded, and renamed in program order, and false dependences are removed by register renaming. (2) Out-of-order middle: instructions sit in reservation stations / an issue queue and execute the instant their operands and a functional unit are ready, in whatever order that happens to be. (3) In-order back end: results wait in the reorder buffer (ROB) and are committed — written to the visible architectural state — strictly in program order. So execution is out of order, but fetch/rename and commit are in order. The illusion of sequential execution is preserved.

This is the central trick of every high-performance core since the mid-1990s, and the reason such cores tolerate cache misses and long-latency operations gracefully: while one instruction waits hundreds of cycles for memory, dozens of independent instructions behind it can race ahead. The honest costs are real: the renaming tables, reservation stations, ROB, and wakeup/select logic are large and power-hungry, and — crucially — the speculation that fills the OoO window is exactly where Spectre-class security holes live. OoO never changes what a correct program computes; it only changes when, internally, the work gets done.