Itanium
Intel’s failed processor family that bet performance on static (compile-time) ILP instead of runtime ILP. Nicknamed “Itanic” for how badly it sank.
Why does it matter?
Itanium is the counterfactual. It’s why modern x86 looks the way it does: bigger reorder buffers, aggressive branch prediction, renaming, OoO. Intel spent years trying to push parallelism discovery onto the compiler; the market rejected it. The lesson, that runtime ILP adapts to real code in a way compile-time ILP can’t, shaped every CPU you’ve ever used.
The pitch: give the machine ~infinite registers, let the compiler speculate aggressively and schedule everything statically. At runtime, the CPU just executes the pre-baked plan and keeps track of which speculative paths were right. No reorder buffer, no dynamic scheduling.
Why it flopped:
- Requires the right kind of program (regular, analyzable code)
- Requires a super smart compiler that never really materialized
- “Infinite registers” means infinite die area and infinite money
Meanwhile x86 went the opposite direction: dynamic ILP in hardware at runtime.
| Itanium (static) | x86 (dynamic) | |
|---|---|---|
| Where ILP is found | Compiler | Hardware at runtime |
| Registers | “Infinite” architectural | Small set, renamed to many physical |
| Speculation | Compile-time, eager | Branch predictor + speculative exec |
| Scheduling | Compiler | OoO + reorder buffer |
| Adapts to runtime data | No | Yes |
x86 kept winning by incrementally adding pipelining, reorder buffers, and functional units. The walls (cache misses, branch mispredicts) are still there and still dominate performance, but dynamic hardware adapts to whatever code it’s fed.
From ECE459 L06.