the iron law of performance

When someone asks why one machine feels faster than another, the honest answer is not a single number but a small equation that refuses to be cheated — which is why it is called the iron law. It says: the time to run a program equals how many instructions it executes, times how many clock cycles each instruction takes on average, times how long each clock cycle lasts. Three factors, multiplied. To go faster you must shrink one without inflating the others.

In symbols, CPU time = instruction count times cycles-per-instruction (CPI) times clock-cycle-time. Instruction count is set mostly by the program and the compiler and the ISA. CPI — the average cycles each instruction needs — is set by the microarchitecture (pipelining and caches push it down; cache misses and stalls push it up). Clock-cycle-time is the inverse of the clock rate. A worked feel: 1,000,000,000 instructions, an average of 1.5 cycles each, at 0.5 ns per cycle, gives 0.75 seconds of CPU time.

The iron law is the spine of thinking about speed honestly, and it explains why so many one-number claims mislead. A faster clock shrinks only the third factor and can be undone by a worse CPI; a clever compiler that cuts instruction count helps even at the same clock; a cache that lowers CPI helps without touching the clock at all. Almost every performance idea in this whole domain is really an attack on one of these three terms — keep the equation in mind and the rest of the subject snaps into focus.