2026-05-13
Once instructions get renamed and dispatched, they don't just "execute" — they have to grab one of a fixed set of execution ports, each wired to specific functional units. A modern superscalar CPU isn't a uniform sea of compute; it's a handful of specialized pipes, and if your code hammers one of them, the others sit idle while you stall.
Take Intel's Golden Cove (Alder Lake P-core), which has 12 execution ports:
The scheduler picks a port when a µop becomes ready. If five integer adds are ready but only ALUs are free, great — issue all five in one cycle. But if all five are multiplies, only three can issue (ports 0, 1, 5), and the others wait. That's port pressure.
Real example: a tight loop doing x = (x * 1664525) + 1013904223 (LCG random). Each iteration needs one multiply and one add. Multiply has 3-cycle latency on port 1; add has 1-cycle latency anywhere. With dependency chain serializing them, throughput is ~4 cycles/iter, even though the CPU can technically retire 6 µops/cycle. The bottleneck isn't ALU count — it's the latency through one specific port.
Compare with unrolling 4 independent LCG streams: now four multiplies are in flight, sharing ports 0/1/5. Throughput jumps to roughly 1 cycle per stream-iteration. Same instructions, 4× faster, purely from port utilization.
Rule of thumb: peak IPC is bounded by min(dispatch width, sum of usable ports for your µop mix). If your hot loop is 50% loads and your CPU has 3 load ports, you can't exceed 6 IPC even with infinite ALUs. Llvm-mca and Intel's IACA/uiCA simulate port assignment cycle-by-cycle and will literally show you which port is saturated.
The deeper insight: compilers optimize for instruction count, but performance is set by the most pressed port. Two equivalent codings of the same algorithm can differ 2× because one routes work to busier ports. This is why hand-tuned crypto and codec kernels sometimes use weird-looking instructions — they're dodging port contention.