Sequential RandomX benchmark research

Checked 2026-09-10. The relay uses RandomX v2; results for the older rx/0 algorithm are not interchangeable with its workload.

Fastest relevant published submission found

XMRig submission 3xnV18 reports an AMD Ryzen 9 9950X3D, XMRig 6.26.0, rx/2, one hashing worker, and 1,000,000 hashes in 914.911 seconds: 1,093.00 H/s. It reports 100% huge pages and affinity -1 (not explicitly pinned). The CPU's 16 cores / 32 hardware threads describe the machine, not the active worker count. This result is not total throughput divided by physical cores or hardware threads.

It leads the RandomX v2 single-thread index checked here. That index contains only five CPU entries at this check; it is not an exhaustive search of hardware or tuning possibilities. I did not find a published strict output-to-next-input RandomX v2 chain result on a modern high-frequency desktop CPU in the searches performed.

What the XMRig source actually measures

The 6.26.0 CPU worker XORs BenchState::data() into the input blob when the benchmark uses one worker. BenchState accumulates a 64-bit word from completed results with XOR. The earlier report's description of these single-thread submissions as independent inputs was wrong.

There is still a material workload difference. The worker uses randomx_calculate_hash_first and randomx_calculate_hash_next. In the matching RandomX API implementation, _next computes the seed for the next input before hashAndFill finishes the current output and fills the next scratchpad. The worker incorporates the completed result into benchmark state after that call returns.

Therefore, by inspection, the immediately following hash input has already been prepared before the current result can affect it. This is a feedback benchmark with pipelining, not the relay's strict recurrence where every next input includes the immediately preceding complete hash. It still runs one hashing worker. This distinction does not justify dividing the reported throughput by two, nor does it establish the Ryzen's actual relay-chain rate.

The relay uses the one-shot API and a 68-byte input containing its domain, epoch, segment, iteration, and the preceding 32-byte hash. The vendor randomx-benchmark --noBatch also uses the one-shot API, but its nonce inputs are independent; it is a useful API comparison, not an exact chain benchmark.

Evidence for the actual relay chain

Our tuned measurements give about 617–619 H/s on the Hetzner EPYC Genoa guest and 564–569 H/s on the Graviton5 host with a pinned hashing worker. These are measured chain rates on the available machines, not evidence that faster CPUs cannot exceed them. The Hetzner guest does not expose physical host SMT placement.

Follow-up: the owner's Apple M4 laptop measured 765.98 and 765.79 H/s in two 50,000-hash runs of the actual chain, with one hashing worker. The full-mode upstream v2 vector passed. This is now our fastest directly measured chain result. macOS controlled core placement, and Spotlight indexing ran concurrently; it is not a measured peak hardware limit or a result on the Ryzen candidate.

The remaining measurement is to run the same strict-chain benchmark on the 9950X3D (and other fast candidates), with one pinned worker, the SMT sibling idle or disabled, full huge-page coverage, and recorded sustained clock and thermal conditions. Until then, 1,093 H/s is a candidate benchmark reference, not a verified chain rate or an upper bound on attacker performance.