Compilation
Speed Benchmark.

Core count first, because compilation splits cleanly across cores. Then single-core speed, which governs linking and the parts that refuse to parallelise. Then memory capacity, since each parallel job needs its own, and finally the drive, which matters most on a cold build of a large tree.

For full builds, more cores, almost without exception — the work is close to embarrassingly parallel. For the incremental builds you actually run all day, where one or two files change and the linker dominates, single-core speed matters more than the core count.

On a clean build of a large project, noticeably. On incremental builds, much less than people expect, because the files in play are already in the operating system's cache. Moving from a mechanical drive is transformative; moving from a good SATA SSD to NVMe is not.

Budget roughly 2 GB per parallel job for a large C++ project, so a 16-core machine running 16 jobs wants 32 GB and is happier with 64. Running out is worse than having too few cores: the machine starts swapping and the build slows to a crawl.

It can, and the gap is largest for projects with very many small files, where filesystem and process-creation overhead dominate. The effect is real but smaller than the difference between a four-core and a sixteen-core processor.