the effect of hazards on effective CPI

In a perfect, hazard-free pipeline, one instruction finishes every cycle: cycles-per-instruction, or CPI, equals 1. That is the dream. But every stall and every flush is a cycle where no instruction finishes, so real CPI creeps above 1. Effective CPI is the honest, all-in average — the actual cycles spent divided by the instructions completed — and it is the single number that captures how much the hazards are hurting you.

The bookkeeping is straightforward. Start from the ideal CPI of 1 and add the average stall cycles that each kind of hazard contributes per instruction: effective CPI = 1 + (load-use stalls per instruction) + (branch penalty per instruction) + (any structural stalls). Each term is a frequency times a penalty. For branches: if a fifth of instructions are branches, your predictor is wrong one time in ten, and each misprediction flushes 3 cycles, the branch term is 0.20 times 0.10 times 3 = 0.06. Add up all such terms and you have the real CPI. This plugs straight into the iron law of performance — run time equals instruction count times CPI times cycle time — so a higher effective CPI directly lengthens program run time.

Effective CPI is the scoreboard for the whole pipelining game, and it makes the tradeoffs honest. Forwarding drives the data-hazard term toward zero; good prediction shrinks the branch term; extra hardware removes structural terms. But it also exposes the catch with deep pipelines: more stages buy a shorter cycle time, yet they raise the misprediction penalty (more stages to flush) and so push the branch term up. Whether deepening helps depends on whether the faster clock outweighs the fatter CPI — which is exactly the pipeline-depth tradeoff, and effective CPI is how you measure it.