Benchmark methodology
On this page
PCBenchmarkX measures the execution of defined CPU/GPU scenarios and the latency of response to a software signal. The amount of work is fixed, and the scoring formulas are open. Repeated runs allow checking the stability of the result.
This documentation refers to engine 0.5.2, workload phase4.6-dev-1, statistics stats-phase4.6-v1 and model score-model-1.2-candidate-1. The model name uses Candidate. Its normalization values are preliminary: they cannot be considered averages across all computers. The reference is described in more detail in score calculation.
Preparation
Section titled “Preparation”BoosterX manages the launch of a separate native engine, shows the test progress and saves the result. During measurement it suspends its own hardware and memory monitoring and minimizes its windows, then restores their state. This reduces the influence of the BoosterX interface itself; external programs can still create load.
Repeat tests with the same engine and driver version, the same power, overclocking and cooling settings. Close unnecessary background programs. If you have a laptop, run all tests with the charger connected. When comparing before and after a change, write down exactly which setting you changed.
Candidate sequence
Section titled “Candidate sequence”| Run part | Set duration | Purpose |
|---|---|---|
| Warm-up | 15 s | Prepare the workload for the scored measurements |
| CPU | 20 s total | Three blocks of approximately 6.67 s each |
| GPU | 30 s total | 10 s each for Geometry, Shader and Compute, in three blocks |
| Combined | 30 s total | Three blocks of 10 s each |
| Calibration | 10 s | Select the Loaded Latency complexity |
| Latency warm-up | 2 s | Prepare the separate latency measurement path |
| Baseline Latency | 5 s | Measure latency under baseline load |
| Loaded Latency | 20 s | Measure latency under calibrated load |
Transitions, resource preparation, preliminary CPU frames and finalization add time. Therefore the total run time is greater than the sum of the measured stages: in the verified series the intervals between the starts of neighboring runs within one load were approximately 157–172 seconds — including the pause between runs; the exact duration of a single run cannot be determined from the published data.
The performance test blocks alternate across three rounds. For CPU, before each scored block there is a fixed initial state and 512 preparatory frames. If the operating speed gradually changes from block to block, this is reflected in the diagnostics. The obtained results are not adjusted.
Run profiles and durations
Section titled “Run profiles and durations”The engine supports four profiles: candidate, quick, extended and custom. Exact stage durations:
| Profile | Task | Transition | Warm-up | CPU | GPU | Combined | Calibration | Latency warm-up | Baseline | Loaded |
|---|---|---|---|---|---|---|---|---|---|---|
| Candidate | canonical | 0.5 s | 15 s | 20 s | 30 s | 30 s | 10 s | 2 s | 5 s | 20 s |
| Quick | diagnostic | 0.25 s | 7.5 s | 10 s | 15 s | 15 s | 5 s | 1 s | 2.5 s | 10 s |
| Extended | diagnostic | 1 s | 30 s | 40 s | 60 s | 60 s | 20 s | 4 s | 10 s | 40 s |
| Custom | user-defined | user’s choice within the permitted boundaries |
Candidate is the default profile, and only its runs are ranked. Quick, Extended and Custom are always considered diagnostic: they cannot be mixed with Candidate in a single comparison and cannot be published to the rating. In Custom you can keep part of the tests and set your own durations: scored blocks accept 1–180 s, transitions — 0.1–180 s, latency warm-up — 0.5–180 s. Any override of a duration makes the run diagnostic.
Collection without writing to disk in every frame
Section titled “Collection without writing to disk in every frame”Measurements are stored in pre-allocated memory blocks. When collecting each frame, the program does not format JSON, does not grow a vector and does not write to a file. The buffer size is calculated in advance from the test duration and the expected maximum recording rate, with a margin. In this implementation a limit of 768 MiB applies.
After the GPU work completes, the data is merged and processed. This reduces the influence of data collection on the test, although the collection itself also consumes resources. To measure its influence, you need to separately compare runs with and without measurement collection.
The result contains summary metrics. A separate raw measurement file allows repeating the statistical processing without a new workload execution. Such a recalculation verifies the computations; verifying repeatability on hardware requires a new run.
Run quality and unsuitability of the result
Section titled “Run quality and unsuitability of the result”During each block the engine evaluates run quality — Run Quality. The main indicator is background CPU load, that is, everything that loads the system besides the benchmark itself. It is calculated per block as the difference between the load of the entire system and the load of the benchmark process, measured by the same time counters. Threshold values for the Candidate profile: above 20% — warning, above 50% — the run is deemed unsuitable.
Run Quality also records accompanying conditions: an attached debugger, a remote session, battery power and battery saver mode, the presence of a hypervisor, loss of window focus and a display change. The hypervisor, battery and remote session are disclosed as warnings: by themselves they do not reject the result, but they explain why the numbers may differ from a “clean” bench. A display change during a scored block makes the run unsuitable.
A suitable scored result additionally requires:
- successful calibration of Loaded Latency — if the complexity could not be matched to the target time, the run is unsuitable;
- a passed exit check of the GPU workloads — a mismatch of the control signature makes the run unsuitable;
- no lost collector records — any loss makes the run unsuitable.
The quality classification is saved in the result file, so “bad” conditions are visible after the fact, not only during the run.
How to read the result
Section titled “How to read the result”| Indicator | Meaning |
|---|---|
| Performance | Relative speed of the fixed workloads |
| Core Latency Score | Relative estimate of internal latency; more points is better |
| Consistency | Severity of the slow tail within a run |
| PC Score | Geometric combination of the three components with weights 50/30/20 |
Actual latencies are shown in milliseconds, and for them lower is better. Consistency must not be confused with the repeatability of PC Score between runs. The formulas and normalization constants are open in score calculation.
Limits of the result
Section titled “Limits of the result”- A synthetic scenario helps detect system changes, but does not replace a test of a specific game.
- Low run-to-run variance does not yet prove the accuracy of each timestamp or the absence of systematic error.
- Eight runs of one PC do not establish the distribution of results for all CPUs, GPUs and Windows versions.
- Compare compatible workload versions and identical profiles. The accelerated, extended and user-defined profiles cannot be unconditionally mixed with Candidate.
- Do not use a canceled or incomplete run instead of a completed measurement.
Next: workloads, latency and PresentMon, formulas, repeatability, run comparison, rating.
Verified: 2026-09-20.