Until today a c0mpute worker told the network what it had: a couple of role tags and one hardware tag such as c0mpute:gpu:nvidia. It never said how fast it was. A four year old laptop and a 64 core EPYC both showed up as c0mpute:cpu, and a buyer picking between them was guessing.
c0mpute 0.2.27 adds c0mpute bench. It measures the machine it runs on and reduces the result to one number the whole network can compare.
What it measures
Three workloads, all pure Rust, no external binaries, deterministic input:
- fib: recursive fork-join fibonacci, n=36. Scheduler and call overhead.
- matmul: dense f64 matrix multiply, n=512, rows partitioned across threads. FPU and cache.
- hash: blake3 over 128 MiB in 1 MiB chunks. Memory bandwidth, and the exact work the verify and storage roles do all day.
Each one runs at 1, 2, 4, up to N threads. Per sample it records the duration, the speedup over the single thread run, and the throughput in real units: node visits, flops and bytes per second.
c0mpute bench · score 6952
cpu DO-Premium-Intel
cores 8
fib (n=36)
thr duration speedup eff throughput
1 84302 us 1.00x 100% 573 Mvis/s ████████████████████████
2 44016 us 1.92x 96% 1.10 Gvis/s ███████████████████████░
4 23973 us 3.52x 88% 2.02 Gvis/s █████████████████████░░░
8 13156 us 6.41x 80% 3.67 Gvis/s ███████████████████░░░░░
hash (128 MiB)
thr duration speedup eff throughput
1 50189 us 1.00x 100% 2.49 GiB/s ████████████████████████
8 6914 us 7.26x 91% 18.08 GiB/s ██████████████████████░░
The bar is parallel efficiency. A machine that scales perfectly fills it. The 70 or 80 percent you see on cloud boxes is the hypervisor and shared memory bandwidth, and it is worth knowing before you bid.
The score
The score is the geometric mean of the best throughput on each workload against a fixed reference, times 1000. A score of 1000 means one reference core on every workload. The reference is one DigitalOcean Premium Intel vCPU as measured in September 2026, and the constants are pinned in the source so scores stay comparable across releases. That 8 vCPU droplet lands near 7000. A 16 core desktop that scales well is around 20000.
The report file borrows its layout from fleetcode's runtime-benchmarks: a metadata block with the CPU, cores, kernel and compiler, then results keyed by runtime, workload and thread count with duration, scaled and speedup. If you already have tooling that reads those files, it reads ours. Only the shape is shared; the numbers are yours.
What the network does with it
The worker reads the last full report when it starts and publishes the score as bench_score in its capability ad on c0mpute/cap/v1. Older peers ignore the new field, so nothing breaks during a rolling upgrade. The status aggregator adds up every advertised score and exposes it as network capacity, and the status page shows it next to workers online. Quick runs (--quick, about a second) are for a sanity check and are never advertised.
c0mpute bench # full run, saves and prints the table
c0mpute bench --quick # one second smoke run, not advertised
c0mpute bench --json # the report as JSON
c0mpute bench show # the last saved report
c0mpute worker status # includes the score the worker will publish
The TUI grew up
c0mpute tui was a placeholder. It is now a real dashboard on hqtui, the terminal UI library we use across our tools, and the bench report is its first panel: score, per workload throughput, a scaling meter and a speedup sparkline, next to the worker state and module list. The view is a pure function of state and is tested by rendering it to text, which is also how the screenshot in the pull request was made.
Try it
curl -fsSL https://c0mpute.com/install.sh | sh
c0mpute bench
Source, tests and the design notes are in profullstack/c0mpute. The reference constants live in node/crates/c0mpute-bench/src/lib.rs if you want to argue with them.
Top comments (0)