Pipelining and the Cost of a Hazard

You have compared cache hits and misses. Pipelining overlaps instruction stages, including work that may wait for memory. Throughput counts completed instructions per cycle. Latency counts cycles from an instruction's start to its completion. Overlap can raise throughput without shortening latency in the same-clock model used here. Real designs can use different clock periods.

Assume an empty pipeline, one instruction starting each cycle, and no stalls. The first completes after five cycles. Each follower completes one cycle later. For n instructions, the total is 5 + (n - 1) cycles. Three instructions take seven cycles, rather than fifteen without overlap.

A data hazard occurs when an instruction needs a result that an earlier instruction has not yet made available. Forwarding sends an available result directly to the stage that needs it, before register write-back. For example, an add result ready after execute can feed a following instruction. Forwarding helps only if the result arrives in time.

A load may produce its result later than an add. If the next instruction needs the loaded value before it is available, it must wait even with forwarding. In the model below, the consumer cannot execute until the load result arrives. This is a data-hazard stall.

A branch predictor chooses a likely path before a branch is resolved. A correct prediction can avoid waiting. A misprediction discards younger wrong-path instructions and redirects fetching. Their results must not become architectural results of the program. Some effects, such as cache changes, may remain; discarding instructions does not undo every hardware effect.

For our timing questions, add the stated stall cycles to the no-stall total. A stall cycle delays useful completion in this model. For three instructions with one added stall, the total is 5 + 2 + 1 = 8 cycles. Do not infer a stall count from the word hazard alone; the timing and forwarding rules must be given.