speculative execution

Imagine driving toward a fork in the road while the GPS is still recalculating. Rather than stopping dead, you make your best guess and keep driving down the more likely branch; if you were right you have saved time, and if you were wrong you turn around. Speculative execution is a CPU doing this: when it hits a branch (or any uncertainty) whose outcome is not yet known, it predicts the likely path and starts executing instructions along it immediately, before it is certain they should run at all.

Concretely, when a conditional branch is fetched, the branch predictor guesses taken or not-taken, and the front end keeps fetching and executing down the predicted path. These speculative instructions run through reservation stations and execution units normally, but their results are held in the reorder buffer and are not committed — not made official — until the branch actually resolves. If the prediction was correct, those instructions are already done and simply commit in order, a huge time saving. If it was wrong, the machine squashes (discards) all the speculative instructions in the ROB, restores the renaming and other state to the point of the branch, and restarts fetching down the correct path. Because nothing speculative was committed, the visible state is untouched.

Speculation, combined with good branch prediction, is what keeps a deep out-of-order pipeline full across the frequent branches in real code — without it, the machine would stall at every branch waiting to know the direction. The honest and now-famous caveat: although speculative work is rolled back from the architectural state, it still leaves microarchitectural traces — most notably it can pull data into the cache. Spectre and Meltdown exploit exactly this, measuring cache timing to read secrets that speculation touched but supposedly 'never happened'. Speculation is a performance feature that turned out to be a real, exploitable security surface.