What "Fast" Really Means
Raw clock speed (cycles per second, measured in GHz) is the most quoted performance number, but on its own it is a poor guide. What actually matters is how much useful work gets done, which depends on three things multiplied together — captured by the CPU performance equation:
A chip with a slower clock but fewer cycles per instruction (CPI), or fewer instructions to do the same job, can easily beat a higher-GHz rival. This is why comparing two processors by clock speed alone (the old "megahertz myth") is misleading.
Real designs are full of trade-offs. A cache speeds up memory access but costs chip area and power. A pipeline overlaps the stages of successive instructions to raise throughput, but complicates control and stalls on branches. More cores help programs that can be split into parallel work, but do nothing for a task that is inherently sequential.
That last point is formalized by Amdahl's law: the speedup from parallelizing a program is limited by the fraction that must run sequentially. If of a task cannot be parallelized, then no matter how many processors you add, you can never make the whole task more than faster — the serial part dominates. Amdahl's law is the sober counterweight to the hope that "just add more cores" fixes everything.
Common pitfall: judging a processor purely by its clock speed (GHz). Performance is instructions × cycles-per-instruction × time-per-cycle; a lower-GHz chip with a better architecture (lower CPI, smarter caching) routinely outperforms a higher-GHz one. And by Amdahl's law, more cores help only the parallelizable part of a workload.
An Amdahl's-law speedup curve rising then flattening toward a horizontal ceiling line at 1/serial-fraction, with the serial portion of a task bar shaded in accent to show what refuses to shrink as processors are add.