Glossary/CPU/Multi-core scaling
Multi-core scaling
Multi-core scaling is how close a workload gets to N-times speedup on N cores, limited by serial code, shared cache, memory bandwidth, and clock drop.
Also known as parallel scaling, core scaling
Measured by SystemCheck
Part of the four-stage run: a 60-second sustained CPU load reporting throughput, decay and consistency; a memory stage reporting bandwidth and latency; a GPU raster load at a fixed resolution reporting frame rate, pacing and decay; and a path tracer reporting samples per second. The paragraphs below say which metric carries this term.
Perfect scaling is unreachable. Amdahl's law caps you at the serial fraction of the work; below that, four practical effects erode the rest: all-core boost is lower than single-core boost, cores contend for shared L3 and memory bandwidth, SMT threads share execution resources, and synchronisation costs grow with thread count.
Observed scaling on a healthy desktop for a compute-bound parallel workload is typically 60-85% of theoretical. Much below that on a workload that should parallelise cleanly points at a real constraint: memory bandwidth saturation, an aggressive power limit that collapses all-core clocks, or background processes stealing cores.
SystemCheck's CPU stage saturates every logical processor with independent Web Worker tasks, which is close to an ideal parallel workload. If your multi-core result is far below what your core count suggests relative to comparable machines, the bottleneck is in your system, not in the code being run.
Scaling also changes over time on a machine that cannot sustain its all-core clocks. A run that starts with every core boosting and then settles lower has scaling that looks good in the first seconds and worse later, because each core is doing less work per second once the power or thermal limit applies. That is why SystemCheck's CPU stage records throughput across its whole length rather than taking a single reading at the start.
Related terms