Cores vs. Clock Speed — What Actually Speeds Up Your Builds
More cores add more workers; a higher clock speed makes each worker faster — and a modern build hits a wall on one of those levers well before the other.
A kitchen with many cooks, each working a separate order at once, finishes more orders in the same amount of time than a kitchen with one cook — no matter how blindingly fast that one cook is. A kitchen with one exceptionally fast cook still finishes any single order sooner than a slower cook would. Cores and clock speed map onto that same split: more cores means more independent work happening at once, while a higher clock speed means each individual core gets through its own work faster, regardless of how many other cores are busy.
Modern build tools — make with -j, Cargo, Gradle, MSBuild — parallelize by compiling many independent source files at the same time, handing each one to a separate core. On a large codebase with hundreds or thousands of translation units, that scaling genuinely holds up: a chip with 16, 24, or even 32 cores can keep all of them meaningfully busy for most of a build, and adding cores keeps paying off roughly until there's no more independent work left to hand out.
Not every part of a build parallelizes, though. Linking — stitching every compiled object file into one final binary — and any single unusually large source file are largely serial work handed to one core, so their duration is set almost entirely by that one core's actual speed, not by how many other cores are sitting idle. On a codebase with a heavy link step or a few oversized files, a chip with a modest core count but strong single-core performance can finish that stage faster than a chip with twice the cores and a lower clock speed.
For a typical multi-file project, core count is the bigger lever, right up until it stops exceeding the amount of genuinely parallel work available. Clock speed and per-core efficiency then decide how fast whatever's left over — linking, one bottleneck file — actually finishes, which is exactly why chip reviews report the two figures separately rather than collapsing them into one "speed" number: they answer different questions about the same build.