Model Reference

Model Reference — "vs typical hardware"

New in 1.1.0.

The baseline tells you where a machine lands against a fixed reference. The model reference table answers a different question: is this chip performing to spec for what it is? A run that grades B tells you little on its own — a B is normal for a mid-2010s Intel laptop. But an i7-1370P that comes in 25% under what a healthy i7-1370P does is a finding, whatever letter it earned.

loadbearer ships a small table of per-model expected raw values — baseline/models/cpu.toml and gpu.toml, embedded in the binary — and when a run's CPU or GPU model matches an entry, the report adds a vs typical hardware block:

  vs typical hardware
    CPU  -3%   CPU matches a typical Intel Core i5-8350U
      int_single -5% · int_multi +0% · float_single -4% · float_multi +1% · hash +2% · …

CPU and GPU only. Memory, disk and network depend on the RAM kit fitted, the SSD, and the OS — not on the CPU/GPU model — so there is no model to compare them to. The block is not graded and never touches a score, exactly like network, --soak and battery health.

How the delta is computed

For every subtest that both the run and the model entry have, loadbearer takes a direction-adjusted ratio (the same convention as everywhere else — higher is always better):

ratio = value / reference_value        (all CPU/GPU subtests are higher-is-better)

The per-component figure is the geometric mean of those ratios, shown as a percentage (+ is faster than the model). Each subtest's own delta is printed underneath so you can see whether a shortfall is broad (thermals, power profile) or confined to one kernel (a missing instruction-set extension, say).

The verdict bands:

Component delta	Verdict
within ±5%	"matches a typical model"
more than ~5% low	"below par — check thermals, the power profile, and background load; re-run --duration thorough on mains"
more than ~5% high	"above a typical model — newer stepping, better cooling, or a native build"

A single reference sample is common early in the table's life; when an entry has samples = 1 the block says so and treats the number as indicative.

The references are measured at --duration thorough. A shorter preset has a smaller working set and a shorter budget, so it reads systematically off against them — high when the machine is cool, and it can swing the other way once it's warm. When the run's preset isn't thorough the block prints (this run used the <preset> preset; the reference is measured at thorough … treat the gap as approximate), and the JSON model_ref entry carries a run_preset field (omitted when it was thorough). For a number you can lean on, run --duration thorough.

Matching

The machine's CPU/GPU model string is normalised — (R)/(TM) dropped, an @ 1.70GHz clock removed, a trailing w/ Radeon 780M Graphics stripped, the 13th Gen prefix and the CPU/Processor noise words removed, lowercased. Then:

1. an exact hit on the normalised string, or
2. a distinctive SKU token from the table (≥ 4 chars, contains a digit — e.g. i7-1370P, N95) that appears in the machine's model string. The longest such token wins.

There is no looser fuzzing. A wrong match is worse than no match, so a model loadbearer isn't sure about simply gets no block.

Build ISA

The references are all measured on the released portable (SSE2) build. A build made with -C target-cpu=native (or custom RUSTFLAGS) runs wider float / hash / crypto kernels — AVX2, AVX-512, SHA — and will sit above the reference for reasons that have nothing to do with the silicon's health.

So every result file now records config.build_isa: sse2 for the released build, avx2 / avx512 for a native build (neon on ARM, the bare arch otherwise). A non-sse2 build still gets a comparison, but the verdict is flagged indicative only and doesn't use the ±5% bands. build_isa is empty in result files written before 1.1.

loadbearer models

loadbearer models                       # print the whole table
loadbearer models "i7-1370P"            # one entry, matched as a live run would
loadbearer models "i7-1370P" --as-result  # synthetic result file, for compare
loadbearer models --json               # the table as JSON

--as-result emits a loadbearer.result/1 whose cpu (or gpu) metrics are the model's reference values, scored against reference-v1 — so you can pipe a model straight into compare.

compare --against MODEL

loadbearer compare mine.json --against "i7-1370P"

adds a synthetic machine built from the table (CPU and GPU only), so a single result can be lined up against a chip you don't physically have. compare accepts one result file when --against supplies the second machine. The synthetic machine carries no memory/disk/network metrics, so those rows drop out of that comparison, and its "reference" preset is exempt from the usual mismatched-preset warning.

Growing the table

The seed is the seven machines that calibrated reference-v1 — a small, older-leaning, all-Intel sample (see The Baseline for the list and the caveats, which apply here too). To add a model, or add samples to an existing one:

# collect thorough runs of the model, one file each
loadbearer run --duration thorough --output ryzen-7840u-1.json
loadbearer run --duration thorough --output ryzen-7840u-2.json

# regenerate the TOML — geometric mean per model across the inputs
loadbearer models --add ryzen-7840u-*.json > baseline/models/cpu.toml

--add does not merge with the embedded table (unlike loadbearer baseline, which is the same story) — it rebuilds it from the result files you give it, so pass every file you want represented. Review the diff and open a PR. Runs should be at --duration thorough from a portable build, on mains power.

Like the baseline, the model reference table is calibration data, not part of the stability contract: entries and values change as more machines are measured, and a change to them is a normal minor/patch release.