performance
Suppose two friends both promise to deliver a stack of letters across town. One rides a fast motorcycle but can carry only one letter per trip; the other drives a slow truck loaded with a thousand letters. Which one is faster? The honest answer is: it depends on what you mean by faster. If you ask how quickly the very first letter arrives, the motorcycle wins. If you ask how many letters arrive per hour, the truck wins. 'Performance' is exactly this slippery — there is no single number that captures it, and the first skill in measuring computers is refusing to be fooled by one.
In computer architecture, performance is usually defined precisely as the inverse of execution time: the less time a program takes to run, the higher its performance, so performance equals 1 divided by execution time. If machine A runs a program in 10 seconds and machine B runs the same program in 5 seconds, then B has twice the performance of A on that program. Note the careful wording: on that program. Performance is always measured relative to a specific workload, because the same chip can be wonderful on one task and mediocre on another.
The deepest honest point is that performance is multidimensional. Latency (how soon one job finishes) and throughput (how many jobs finish per unit time) are genuinely different, and improving one can hurt the other. Add energy, cost, and reliability and you have several axes that a single 'speed' number flattens away. A faster clock (more gigahertz) does not by itself mean faster — the real run time is instruction count times cycles per instruction times clock-cycle time, the iron law. Whenever someone quotes one figure for how good a computer is, your first question should be: faster at what, and measured how?
Machine A finishes a video encode in 20 s; machine B finishes the same encode in 8 s. Performance(B) / Performance(A) = (1/8) / (1/20) = 20/8 = 2.5, so B is 2.5 times faster on this task — even though B might be slower than A on a different, branch-heavy task.
Performance is 1/time, and it is always tied to a specific workload — never a single universal score.
Beware any single 'this computer is faster' claim. Faster at latency or throughput? On which program? At what power and cost? A higher clock rate does not by itself mean faster — the megahertz myth misled a whole generation.