Glossary/Benchmark/Score normalization
Score normalization
Score normalization converts raw measurements onto a common scale against a fixed reference, so results stay comparable across machines and runs.
Also known as normalized score, score 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.
Raw numbers (iterations completed, milliseconds per frame, samples per second) are not intuitively comparable and vary with workload sizing. Normalization maps them to a stable index defined against a reference system or a fixed constant, so a score means the same thing across every machine that runs the test.
The trap is that a normalized score is only comparable within one measurement revision. Change the workload, the sizing, or the scoring formula and old scores become incomparable, even though both are printed as plain numbers. Benchmarks that silently renormalise between versions produce years of misleading forum comparisons.
SystemCheck stamps every report with its measurement revision and the GPU backend used, so you can tell whether two results are legitimately comparable. Compare across the same revision and the same backend; a WebGPU result and a WebGL2 result from the same card are not equivalent even at the same revision.
Normalization also hides scale. A normalized figure says how a result compares with the reference, not what the machine actually did per second, so two machines a few percent apart on an index may be equally fast in practice once run-to-run variance is counted. When a difference matters to a decision, look at whether it is larger than the spread between repeat runs before reading anything into it.
Related terms