Apple M4 laptop: strict sequential RandomX v2 benchmark

Measured 2026-09-10 UTC on the owner's laptop. The local machine reports an Apple M4, 32 GiB RAM, 4 performance cores and 6 efficiency cores, with 10 physical and 10 logical cores. The executable is native arm64, compiled in release mode.

The two results differ by about 0.025%. This is approximately 24% faster than our tuned Hetzner result (617–619 H/s) and 35% faster than the tuned Graviton5 host result (564–569 H/s). These are measured operating conditions, not a controlled comparison isolating CPU microarchitecture or a hardware speed limit.

Method

Built the current working tree with cargo build --release -p relay-timelock -j 2. Both runs executed:

target/release/relay-timelock calibrate --mode full --workers 1 --samples 50000

This is the actual relay dependent-chain loop: every 68-byte input contains the immediately preceding 32-byte result. It uses RandomX v2.0.1, full-memory mode, the native ARM JIT, hardware AES, and the existing secure JIT protections. It has one hashing worker and no pipelining of independent hashes. Dataset/cache initialization is reported separately and excluded from H/s. The per-run dataset key and initial seed are random, as in the server calibrations.

A thread CPU-usage sample showed the main thread idle and the hashing worker using about 100% of one CPU. The benchmark was not pinned to a particular core; macOS controls scheduling and may migrate the worker. We did not measure its performance-core residency or sustained clock frequency. No SMT parallelism is involved: the machine reports equal physical and logical core counts.

Conditions and limits

• Spotlight indexing ran concurrently and consumed substantial CPU. No unrelated process was stopped. This result does not establish idle-machine peak speed.
• AC power was attached throughout the captured benchmark power samples; the battery went from not charging before run 1 to charging after run 2.
• pmset -g therm reported no recorded thermal or performance warning. That does not establish an absence of frequency variation or thermal limits.
• The Linux huge-page allocator advice is guarded by __linux__ and does not apply on this macOS build. Huge-page coverage was not measured here.
• Graviton's comparison result was on a parent CPU while production enclave generation continued elsewhere on that instance. Hetzner's physical host placement and co-tenant load are unknown.
• These roughly 65-second hashing samples do not establish multi-day sustained performance, and the result is not an upper bound on attacker hardware.

Validation and retained evidence

The release-build full_mode_upstream_v2_vector test passed after both measured runs, so validation did not compete with timed hashing. It checks the complete full-memory output against the upstream RandomX v2 expected digest. The test command and output are in validation-command.json and validation.log.

Raw calibration JSON, power and thermal snapshots, compiler versions/flags, binary digest, relevant source-file digests, and the tracked source diff are retained here. environment.json explicitly identifies the dirty working tree; this is not claimed to be a clean-commit or signed reproducible build.

See the server tuning report and the published benchmark investigation.