Measuring CPU performance

Q: What is the iron law of processor performance?

The iron law states CPU time = instruction count x CPI x clock period. A processor is faster only if it reduces one of those three terms (the number of instructions, the average cycles per instruction, or the time per cycle) without inflating the others.

The iron law and Amdahl's law

7 min read

CPU performance is governed by the iron law: CPU time equals the program's instruction count times the average cycles per instruction (CPI) times the clock period, so a design is only faster if it cuts one of those three terms without inflating the others.

Builds onFetch, decode, execute

You built a CPU and could ask: is it fast? That sounds like one number, but performance is really a product of three. How fast a processor runs a program depends on how many instructions the program is, how many clock cycles each instruction takes on average, and how long each clock cycle lasts. Multiply them and you get the runtime. This is the iron law of performance, and it is the lens architects use to judge every design decision.

CPU time = instruction count x CPI x clock period

The middle term, CPI, is *cycles per instruction*, the average number of clock cycles an instruction takes. The clock period is the inverse of the clock frequency, so a 1 GHz clock has a 1 ns period and a 2 GHz clock a 0.5 ns period. The law makes the tradeoffs visible: you make a processor faster only by shrinking one of the three terms without inflating the others, and that proviso is where it gets interesting, because the terms fight each other.

The three terms pull against each other

Each microarchitecture style you have met trades CPI against the clock period:

Single-cycle: every instruction finishes in one cycle, so CPI is a clean 1. But the clock must be slow enough for the *longest* instruction's path through the datapath, so the clock period is large.
Multicycle: break each instruction into several short steps. Each cycle is now short (a fast clock), but an instruction takes several of them, so CPI rises to roughly 3 to 5.
Pipelined: overlap instructions (pipelining) so the short-cycle clock stays, and CPI drops back toward 1 because one instruction completes per cycle, minus the stalls hazards cost.

Put real numbers on three designs running the same 1,000,000-instruction program. Notice the winner has neither the best CPI nor, by itself, an obviously better design; it wins on the product.

Design	CPI	Clock period	Time for 1M instr
Single-cycle	1.0	10 ns	10.0 ms
Multicycle	4.0	2 ns	8.0 ms
Pipelined	1.2	2 ns	2.4 ms

Same program, same instruction count, three microarchitectures. Time = 1,000,000 x CPI x clock period. The pipelined design has a worse CPI than the single-cycle one but wins easily because its short clock period multiplies through.

Work the single-cycle versus pipelined comparison: 1,000,000 x 1.0 x 10 ns = 10 ms against 1,000,000 x 1.2 x 2 ns = 2.4 ms. The pipelined CPU is about 4.2x faster even though its CPI of 1.2 is *worse* than the single-cycle 1.0. Its short clock period is what carries the day. Reading only one term, CPI, would have pointed you at the wrong design.

Why clock speed alone misleads

That is exactly why clock speed (GHz) is a poor measure on its own: it is only one of three terms. A 3 GHz chip with a CPI of 3 runs 1 instruction every 3 cycles x 0.33 ns = 1 ns, the same effective rate as a 1 GHz chip with a CPI of 1. MIPS (millions of instructions per second) and MFLOPS mislead the same way: a different instruction set may need *more* instructions to do the same work, so a higher MIPS can still mean a slower program. The only honest comparison is total time on a real workload, which is why benchmarks (suites of representative programs, like SPEC) exist.

Common mistakes. Do not compare processors by clock speed or MIPS alone; all three iron-law terms matter, and they move together (pipelining shrinks the clock period but can raise CPI through stalls). Do not compare MIPS across different instruction sets, since the instruction counts differ for the same work. And beware optimizing a part that is a small slice of the runtime: making a rarely-used routine ten times faster barely moves the total, which is the warning Amdahl's law makes precise.

Amdahl's law: the limit of speeding one part

Suppose you can accelerate only part of a program. If a fraction p of the runtime is sped up by a factor s, while the remaining 1 - p is untouched, the overall speedup is the whole time divided by the new time:

speedup = 1 / ( (1 - p) + p / s )

Say 80% of the time is in a part you make 4x faster: p = 0.8, s = 4. Then the speedup is 1 / (0.2 + 0.8 / 4) = 1 / (0.2 + 0.2) = 1 / 0.4 = 2.5x. Not 4x, because the untouched 20% did not move. Worse, even with an *infinitely* fast part (s to infinity) the best you can do is 1 / (1 - p) = 1 / 0.2 = 5x. The slow 20% you left alone caps the whole result. Amdahl's law is the quantitative form of 'make the common case fast': effort spent on a part is worth only as much as that part's share of the runtime.

Try it

Processor X runs a program of 1,000,000 instructions at CPI 2.0 with a 1 GHz clock (1 ns period). A redesign cuts CPI to 1.25 but the clock drops to 800 MHz (1.25 ns period). Using the iron law, which is faster, and by how much?

The iron law ties the entire course together. The instruction set fixes the instruction count, the microarchitecture (single-cycle, pipelined, cached) sets the CPI, and the circuit and process technology set the clock period. Every optimization, from a faster adder to a deeper pipeline to a bigger cache, is ultimately judged by what it does to these three numbers and by Amdahl's law's reminder that only the common case is worth optimizing.

These same three terms govern every processor, from this 8-bit teaching machine to a modern superscalar core. With a way to measure it in hand, the natural next step is to watch a real program execute instruction by instruction, which is exactly what the program trace lesson does.

Frequently asked

What is the iron law of processor performance?

The iron law states CPU time = instruction count x CPI x clock period. A processor is faster only if it reduces one of those three terms (the number of instructions, the average cycles per instruction, or the time per cycle) without inflating the others.

What is CPI (cycles per instruction)?

CPI is the average number of clock cycles an instruction takes. A single-cycle design has CPI 1; a multicycle design has CPI around 3 to 5; an ideal pipeline drives it back toward 1, minus the cycles lost to hazards and stalls. It is the middle term of the iron law.

Does a higher clock speed always mean a faster CPU?

No. Clock speed is only one of the three iron-law terms. A high-GHz design with a high CPI, or one whose instruction set needs more instructions for the same work, can be slower overall. A 3 GHz chip at CPI 3 matches a 1 GHz chip at CPI 1. Only total time on a real workload is a fair comparison.

What is Amdahl's law?

Amdahl's law gives the overall speedup when only a fraction p of a program is sped up by a factor s: speedup = 1 / ((1 - p) + p / s). The untouched fraction 1 - p caps the result, so even an infinitely fast part yields at most 1 / (1 - p). It is the math behind 'make the common case fast'.

Why are MIPS and clock speed misleading benchmarks?

Both capture only one piece of the picture. MIPS counts instructions per second, but different instruction sets need different instruction counts for the same task, so higher MIPS can still be slower. Clock speed ignores CPI and instruction count entirely. Representative benchmark suites measuring total time on real programs are the honest alternative.

Every lesson here builds toward one thing: a working CPU, from the transistor up.

Open the free lab →