Pipelines, Throughput and Hazards

Consider a simplified processor with fetch, decode and execute stages, each taking one clock tick. Without overlap, one instruction occupies three ticks before the next starts. With separate stage resources, instruction 2 can be fetched while instruction 1 is decoded. The instructions remain distinct even though they are active together.

For n instructions and k equal-length stages, an ideal initially empty pipeline takes k+n−1 ticks. Six instructions in three stages therefore take eight ticks instead of eighteen. This formula assumes no stalls, no competing resource use and equal stage times; a question with different assumptions needs its own timeline.

Scroll the diagram to see the full view.

Latency is the time taken by one instruction from entry to completion. In the simple example it remains three ticks. Once the pipeline is full, throughput is one completed instruction per tick. Saying that every instruction now takes one tick confuses these two measurements.

The slowest stage constrains the clock period in a basic synchronous pipeline. Dividing a processor into more stages can change the period, but adds overhead and can increase the cost of a branch misprediction. Clock frequency alone does not determine the time a whole program takes. Compare the same workload and include stalls and memory delays.

A data hazard occurs when an instruction needs a result not yet available from an earlier instruction. A stall or forwarding mechanism may be needed. A control hazard arises when a branch makes the next instruction address uncertain. Instructions fetched along an incorrect path may need to be discarded.

A structural hazard occurs when stages need the same limited resource at once. These issues can reduce useful throughput. Pipelining is also a broader software idea: processing one data item in a later stage while the next enters an earlier stage. Dependencies, buffering and stage balance still matter; overlap is not a guarantee of proportional speedup.

Attempt the task before opening its worked response. Record each change of state, explain the rule used, and check the result against the original requirements. Code examples labelled Python 3 use that language’s conventions; pseudocode states its own assumptions.