The Iron Law of Performance
Ask someone what makes a CPU fast and they will say "gigahertz". They are a third right. The true answer
— the equation every computer architect keeps taped above their desk — is the iron law of
processor performance. It breaks the time a program takes into exactly three factors, and
every design decision in this course moves one of them:
\text{CPU time} \;=\; \underbrace{\frac{\text{instructions}}{\text{program}}}_{\text{IC}} \;\times\; \underbrace{\frac{\text{clock cycles}}{\text{instruction}}}_{\text{CPI}} \;\times\; \underbrace{\frac{\text{seconds}}{\text{clock cycle}}}_{T_{\text{cycle}}}.
The units telescope: instructions cancel, cycles cancel, and you are left with plain
seconds. That is why it is "iron" — it is just unit arithmetic, and there is no cheating
it. Written with clock frequency f = 1/T_{\text{cycle}},
\text{CPU time} \;=\; \frac{\text{IC} \times \text{CPI}}{f}.
Three levers, three owners
The three factors are not controlled by the same people, which is exactly why the law is useful for
thinking about who can do what:
| Factor | Means | Chiefly set by |
|---|
| IC — instruction count | how many instructions the program runs | the algorithm, compiler and ISA |
| CPI — cycles per instruction | average cycles each instruction takes | the microarchitecture (pipeline, caches) |
| Tcycle — cycle time | how long one clock tick lasts | circuit design & silicon technology |
"Gigahertz" is only the last column. A chip can have a blazing clock and still be slow if it wastes
cycles (high CPI) or runs bloated code (high IC). The whole product is what you feel.
Worked example — and the trap
A program runs 10^9 instructions at \text{CPI} = 2.5
on a 2\ \text{GHz} chip
(T_{\text{cycle}} = 0.5\ \text{ns}). Then
\text{CPU time} = 10^9 \times 2.5 \times 0.5\times10^{-9}\ \text{s} = 1.25\ \text{s}.
Now the trap. Suppose a new compiler cuts the instruction count by 20\% — but
the instructions it emits are fancier and push CPI up from 2.5 to
3.2. Did you win? Only the product knows. Multiply it out and see:
0.8\,\text{IC} \times \frac{3.2}{2.5}\,\text{CPI} = 0.8 \times 1.28 = 1.024 —
1.024, so the program actually got 2.4\% slower.
This is the eternal tug-of-war: cut one factor and another often springs up. RISC vs CISC, hardware vs
software, is largely a fight over this trade.
// The iron law: CPU time = IC x CPI x cycle_time = IC x CPI / frequency.
function cpuTime(ic: number, cpi: number, ghz: number): number {
const cycleTime = 1 / (ghz * 1e9); // seconds per clock
return ic * cpi * cycleTime;
}
const base = cpuTime(1e9, 2.5, 2.0);
console.log(`baseline: ${base.toFixed(3)} s`);
// "Smarter" compiler: 20% fewer instructions, but CPI rises 2.5 -> 3.2.
const tuned = cpuTime(0.8e9, 3.2, 2.0);
console.log(`new compiler: ${tuned.toFixed(3)} s`);
console.log(`speedup = ${(base / tuned).toFixed(3)}x (below 1.0 means SLOWER!)`);
Why you cannot compare chips by clock speed
In the 1990s marketing sold CPUs by megahertz, and it worked until it didn't: a
1.4\ \text{GHz} Pentium III could beat a
1.8\ \text{GHz} Pentium 4 on real work, because the P4 traded a much higher
clock for a much worse CPI. The iron law explains it in one line — the P4 won column three and lost
column two, and lost overall. To compare machines honestly you must know all three factors (or just
measure the wall-clock time on a real
benchmark).
- \text{CPU time} = \text{IC} \times \text{CPI} \times T_{\text{cycle}} = \dfrac{\text{IC}\times\text{CPI}}{f};
- clock frequency is only one of three factors — a fast clock can be undone by a
high CPI or a bloated instruction count;
- optimisations trade the factors against each other, so only the product tells you whether
you actually won.
On an ideal pipelined machine every instruction would finish one per cycle, giving
\text{CPI} = 1. Reality adds stall cycles: a cache miss might
cost hundreds of cycles, a mispredicted branch a dozen, a data dependence a few. So architects write
\text{CPI} = \text{CPI}_{\text{ideal}} + \text{stalls per instruction}, and
most of the rest of this course — caches, branch prediction, out-of-order execution — is a war on those
stall cycles. Amdahl and the iron law together tell you where to aim: attack the stalls that eat the most
total cycles.
A common slip is to reason "IC dropped 20% and CPI rose 20%, so it's a wash." It is not. The factors
multiply: 0.8 \times 1.2 = 0.96, a 4\%
win — but 0.8 \times 1.28 = 1.024, a 2.4\%
loss. Small percentage changes interact non-linearly, and the sign of the final result can flip.
Always carry all three numbers through the multiplication before you claim a speedup.