A single benchmark score is a summary statistic, and every summary discards the distribution it came from. The shape of the run matters more than its total.
- Peak throughput measures the best moment; sustained throughput measures the plateau you actually work in. For anything longer than a few seconds, sustained is the number that predicts real experience.
- Run-to-run variance under about 3% is measurement noise; two results inside that band are the same result, and treating a 1% difference as an improvement is how people fool themselves.
- A high score with poor consistency is usually worse in practice than a lower score delivered evenly. Stutter is felt, averages are not.
- Always record what else was running, whether the machine was on mains power, and whether it started cold. A result without its conditions is not evidence.
The number is a summary, not the measurement
A benchmark produces a time series: work completed in each interval across the run. The score you are shown is a reduction of that series to one figure. That reduction is necessary (you cannot compare two machines by eyeballing two graphs), but it is lossy, and what it loses is precisely the information that distinguishes a machine that is fast from a machine that was briefly fast.
Two systems can post an identical composite score with completely different behaviour. One holds a flat line for the entire run. The other spikes 30% above the first for the opening ten seconds and then falls 25% below it for the remaining fifty. They average out. They are not the same machine, and if your work takes more than ten seconds, the flat one is better.
This is why SystemCheck reports throughput, decay, and consistency as first-class figures rather than folding everything into one score and hiding the rest. The composite grade exists for quick comparison. The component numbers exist so you can tell what the grade is made of.
Peak versus sustained
Peak throughput is the highest rate observed during the run, typically in the first few seconds while the chip is still cold and boost budgets are full. Sustained throughput is the rate once the system has reached thermal and power equilibrium. The gap between them, expressed as a percentage, is decay.
Which one matters depends entirely on the length of your workload. Opening an application, loading a web page, applying a filter to one photo. These finish inside the boost window and peak predicts them well. Exporting video, compiling a large project, running a simulation, playing for an hour. These live entirely in the sustained plateau, and peak tells you nothing useful about them.
The failure mode is comparing your sustained-heavy workload against a benchmark number derived from a short burst. That is how a laptop that reviews well ends up feeling slow at the thing you bought it for.
Variance: when is a difference real?
Any measurement on a general-purpose operating system carries noise. Scheduler decisions, background services, memory layout, browser JIT warm-up state, and ambient temperature all move the result a little. On a quiet desktop, run-to-run spread of 2-3% is ordinary. On a laptop, or a machine with an active background process, 5% or more is common.
The practical rule: run three times, discard nothing, and look at the spread. If your three results fall inside a 3% band, you have a reliable measurement and the middle value represents the machine. If they are spread across 10%, you do not have a measurement yet. You have three snapshots of an unstable environment, and the honest response is to close things and try again rather than to pick the highest.
Never compare a single run against a single run and call a 1-2% difference an improvement. It is not. This applies to your own before-and-after testing as much as to comparisons between machines, and it is the single most common way enthusiasts convince themselves a tweak worked.
Consistency, and why stutter beats averages
Consistency measures how tightly the per-interval results cluster around their own mean. It is a separate axis from throughput, and it maps onto perceived smoothness far more directly than any average does.
The GPU case makes this vivid. A system averaging 60 frames per second with even pacing feels smooth. A system averaging 60 frames per second where every twentieth frame takes 50 milliseconds feels broken, and no average will show you the difference. SystemCheck reports frame-time stability in Stage 2 and sample-time consistency in Stage 3 precisely because the average is the part that lies.
When you see high throughput paired with poor consistency, look for contention before you look for hardware. Something else on the machine is competing for the resource in bursts. That is a fixable condition, and it is not a property of the hardware you are trying to measure.
Conditions are part of the result
A benchmark number without its conditions is an anecdote. The variables that move results enough to matter are few enough to write down every time:
- Power source: a laptop on battery is frequently running a fraction of its plugged-in power budget. This alone can halve a result.
- Starting temperature: a run started immediately after another run begins heat-soaked and will decay faster from a lower peak.
- Background load: browser tabs running timers, sync clients, update services, and anti-malware scans all take cores.
- Browser and GPU backend: WebGPU and WebGL2 are different code paths with different overhead; the browser version and driver version both move GPU results.
- Power plan and ambient temperature: a balanced Windows power plan and a warm room both cost measurable sustained throughput.
How to compare against someone else's result
Cross-machine comparison is where the largest errors happen, because the conditions differ in ways neither party recorded. Compare component figures rather than composite scores where you can: sustained CPU throughput against sustained CPU throughput is a defensible comparison, and grade against grade is not, because the grade folds in GPU and path-tracing results that may have run on a different backend entirely.
Treat any comparison across different browsers, different operating systems, or different GPU backends as directional only. A 15% difference across two browsers on the same machine is entirely possible and says nothing about the hardware. If you want a hardware comparison, hold everything else constant, and if you cannot, say so when you report the number.
Terms used here
Questions
- How many times should I run a benchmark?
- Three, with a couple of minutes of idle between runs so the machine starts from a comparable thermal state. If the three results fall inside a 3% band, the middle one represents your machine. If they are spread wider than that, the environment is unstable and the results should not be used for comparison.
- Why is my score lower than someone with the same CPU?
- Cooling, power limits, background load, browser, and GPU backend all move results, and identical part numbers do not imply identical sustained behaviour. A laptop and a desktop with the same CPU model can differ by 40% or more in sustained throughput because their power budgets are different.
- Should I use peak or sustained throughput to compare machines?
- Sustained, unless your actual workloads are all short bursts. Peak measures the best few seconds under ideal thermal conditions; sustained measures the equilibrium the machine settles into, which is where any workload longer than about ten seconds spends its time.