Why clock speed alone cannot rank computers

By UK GCSE Computer Science · independent study · myAudience

Original AI-generated teaching illustration via built-in image_gen; author inspected 2026-10-04. · Generated project artwork; no copied exam/publisher figure. Independent publication review pending.

Why clock speed alone cannot rank computers

CPU performance is how quickly a specified workload is completed, not simply the largest clock number on an advertisement. Frequency supplies cycles per second; work also depends on how many instructions are needed, average cycles per instruction, data availability and the opportunities for concurrent execution. This lesson uses declared fictional models with fixed assumptions. They help explain causal relationships but are not benchmarks for current products. Comparing real machines fairly requires the same relevant task, comparable conditions and measured results rather than a single isolated hardware feature.

In a simple nonoverlapping model, time equals instruction count multiplied by average cycles per instruction, divided by cycles per second. A billion instructions at two cycles each on a 2 GHz processor need one second: two billion cycles divided by two billion cycles per second. A 3 GHz machine needing four cycles per instruction for the same billion instructions needs four-thirds of a second. Under these stated values it is slower despite the higher frequency. This does not prove a real architectural ranking; the fictional cycles and counts are the information required to calculate it.

Cache can reduce average access delay when information is reused. Our separate fictional access model assigns a complete hit time of 1 ns and a complete miss time of 50 ns, including any lookup overhead. At 90% hits, average time is 0.90 × 1 + 0.10 × 50 = 5.9 ns. At 99% hits it is 0.99 × 1 + 0.01 × 50 = 1.49 ns. These are weighted means, not a guarantee that each access takes the average. If miss time were only an additional penalty, the equation would instead need the hit lookup plus the weighted penalty.

The cache figures are separate from the instruction-count example. Combining them without knowing how many accesses occur, which delays overlap and what other execution time exists would double count or invent timing. A larger cache can improve a suitable reuse pattern, yet larger size alone does not guarantee a given hit rate. Data patterns, organisation and other design decisions matter. A rigorous answer says what changes, what is held fixed and how the model predicts a delay reduction, instead of claiming all programs become a fixed percentage faster.

Extra cores offer more opportunities for simultaneous work, but a dependent sequence cannot be split arbitrarily. Suppose a task takes one second on one core and consists of a 0.25-second serial part followed by a 0.75-second part that can be perfectly divided. With four identical cores and no coordination cost, the total becomes 0.25 + 0.75/4 = 0.4375 seconds. Speedup is 1/0.4375, about 2.29 times, not four times. With infinitely many ideal cores, the serial part still leaves a 0.25-second lower bound and speedup at most four.

This ideal serial-fraction calculation is optional quantitative enrichment that explains the assessed core-count factor. It does not require learners to memorise a named performance law. Real work may have communication, synchronisation, unequal task sizes, memory contention or power limits, all of which can reduce the benefit. If each stage needs the result of the previous stage, the problem may have little parallelism. A task with many independent images can differ from one with a single dependent computation even on the same processor.

For a demanding transfer, compare eight cores with four when the same fixed task retains a 25% serial part. The eight-core ideal time is 0.25 + 0.75/8 = 0.34375 seconds, giving a 2.91-fold speedup from one core. It is only about 1.27 times faster than the four-core result, because 0.4375/0.34375 is approximately 1.2727. Doubling the cores did not halve total time. If a separate coordination cost of 0.12 seconds is added only to the eight-core case, time becomes 0.46375 seconds and the nominally larger machine is slower than the ideal four-core comparison.

The generated plate displays three clearly separate fictional models: cycles/frequency, weighted cache-access delay and serial/parallel work. Its four parallel lanes show independent work after a single serial phase, not four processors duplicating the same entire task. To evaluate an upgrade proposal, identify the user's workload and dominant delay, then request measurements appropriate to that workload. A CPU with more cores might improve throughput across independent jobs while barely improving a single dependent job's latency. Correct explanations connect an architectural feature to the task and acknowledge missing evidence.

Worked example: Calculate four-core time and speedup for the stated one-second task.

The serial0.25s is unchanged.

Divide only the parallel0.75s by4 to get0.1875s.

Total0.4375s; speedup1/0.4375=16/7≈2.29.

Answer: 0.4375 s, about2.29× ideal speedup; the result assumes perfect division and no overhead.

Check your understanding: For eight cores add0.12s coordination overhead absent from the ideal four-core case. Which modeled configuration is faster and why?

Answer: Eight-core time0.25+0.75/8+0.12=0.46375s, which exceeds four-core0.4375s by0.02625s. Extra parallel capacity is outweighed by the stipulated additional overhead. This is a conditional comparison, not a universal claim that eight cores are worse.

Why: Only the parallel fraction is divided; explicitly included overhead can reverse a hardware-count ranking.