what is out-of-order execution
Out-of-order execution is a processor design technique where instructions are allowed to run in whatever order their inputs become ready, rather than strictly in the order they appear in the program, letting the processor keep working instead of stalling whenever one instruction has to wait.
```flowchart
{
"rows": [
{ "type": "nodes", "items": [
{ "title": "In-order execution: instructions run strictly in sequence", "sub": "one stalled instruction blocks everything behind it", "tone": "red" }
]},
{ "type": "arrow" },
{ "type": "group", "title": "Out-of-order execution instead", "items": [
{ "title": "Ready instructions run immediately, out of sequence", "sub": "stalled instructions no longer block independent work", "tone": "green" }
]},
{ "type": "arrow" },
{ "type": "nodes", "items": [
{ "title": "Results reordered back to correct program order", "sub": "program behaves correctly despite internal reordering", "tone": "blue" }
]}
]
}
```
**Out-of-order execution exists because strictly running instructions in their original program sequence wastes processor time whenever one instruction has to wait, even if later, independent instructions are already ready to run.** A processor executing instructions strictly in order must stall completely whenever one instruction is waiting on something like a slow memory access, even if several instructions further down the program have no dependency on that wait and could run immediately — out-of-order execution instead lets the processor identify and run those independent, ready instructions right away, only reordering the final results back into correct program order once everything completes.
```svg
```
```svg
```
| Aspect | In-order execution | Out-of-order execution |
|---|---|---|
| Execution sequence | Strictly matches program order | Runs whichever ready instruction first |
| Handling of stalls | Everything behind a stall waits | Independent instructions keep running |
| Hardware complexity | Simpler | Significantly more complex |
| Common use | Simple, low-power cores | High-performance CPU cores |
**Implementing out-of-order execution requires substantial additional hardware complexity, including tracking instruction dependencies and reordering results back into correct final order.** A processor supporting out-of-order execution needs dedicated hardware to track which instructions depend on which others, decide which ready instructions to run next, and ultimately reassemble all the out-of-sequence results back into the program's originally intended order — this added complexity is a major reason out-of-order cores are typically larger and consume more power than simpler in-order designs.
**Out-of-order execution is generally reserved for high-performance processor cores, while simpler, lower-power cores often use in-order execution instead.** Because the hardware complexity and power cost of out-of-order execution is only worth paying when maximizing single-thread performance matters most, many high-performance CPU designs use out-of-order cores, while simpler embedded or power-constrained cores frequently rely on simpler in-order execution instead.
**Out-of-order execution's performance benefit depends heavily on how much independent, ready work is actually available for the processor to reorder around a stall.** A workload with abundant independent instructions gives out-of-order execution plenty of useful reordering opportunities, while a workload where nearly every instruction depends on the one before it leaves out-of-order execution with little room to help — this dependency on available independent work is why out-of-order execution's real-world benefit varies meaningfully across different types of software.
Read out-of-order execution through a flexible-checkout-line lens: rather than forcing every customer to wait behind whoever is currently stuck at the register, it lets ready customers move to an open register immediately — with a final step ensuring everyone's receipt still comes out in the order they actually arrived.