AMD EPYC 9R14 (Zen 4): the full speed panel

This directory holds the third host of the chart, an AMD EPYC 9R14 (Zen 4, Genoa). Every timed chart row was re-run there with the public timing reproduction, following its README. That covers all 42 manifest rows and the six chart rows outside the manifest. PolyXOR128's raw variant, the four HalftimeHash styles and a ChainHash backend comparison were run alongside. The Xeon and M2 tabs are unchanged except for the ChainHash rows, which were refreshed to the same revision (records/chainhash/refresh-a0116ea).

Host

SMHasher3's x86 timer counts TSC ticks. B/cycle on this tab therefore means bytes per 2.600 GHz tick. Wall-clock GB/s is 2.6 × B/cycle, and bytes per core cycle at 3.66 GHz is 0.71 × B/cycle. The printed GiB/s assumes 3.5 GHz, as on the other hosts. The Xeon's TSC runs at 2.900 GHz, and the M2 uses a calibrated clock, so compare hashes within one tab.

Protocol

This is the reproduction's x86 rule, the same as on the Xeon. Each row gets two complete serial passes of unmodified SMHasher3 NAME --test=Speed. The cell takes the higher bulk average (262144-byte keys, eight alignments) and, independently, the lower 1–31-byte average.

Each start waits until no other SMHasher3 process runs on CPUs 8–15. Every 5 s the runner samples for overlapping runs; none was excluded. Another job ran on CPUs 0–7, the other L3, during the measurements, so no machine-wide load threshold was applied. Load1 at launch ranged 0.95–6.35 and is recorded per run.

The rows outside the manifest ran on the same binary with the same selection. There, a whole-machine check discarded and repeated three runs that overlapped another SMHasher3 process (evidence/extra/discarded.jsonl). No bulk spread exceeds 2%. The largest small-key spreads are 3.5% (HalftimeHash-512) and 3.2% (polyxor-128.raw), so no row needed the

5% re-run.

The ChainHash pin of the reproduction moved to a0116ea during the run. ChainHash does not enter any other row. The build was repeated at the new pin, and VerifyAll was asserted: 0x66672BD6 and 0x1FCA728C, unchanged. The chainhash and chainhash-128 rows were then re-timed on that binary (evidence/panel-chainhash). Their earlier values at 30c0111 are kept in speeds_zen4.json#/meta.

Results

Verification is SMHasher3's VerifyAll value on this build. Sanity is the reproduction's native Sanity record. The four Sanity failures (foldhash ×2, shipped HalftimeHash24 and Marvin32) are the ones the reproduction README documents for x86. The two HalftimeHash24 wrappers have zero registered constants. Their computed values equal the Xeon's (0x8A105352 shipped, 0x3F1372EA fixed).

ChainHash backends on Zen 4

The headers dispatch to ZMM when AVX-512 is present. Forcing each x86 backend in one binary (speeds_zen4_chainhash_backends.json):

ZMM is 1.75× (ChainHash) and 1.56× (ChainHash-128) faster than YMM in bulk on Zen 4. Zen 4 executes 512-bit VPCLMULQDQ as two 256-bit halves, but the wider loop still wins, so the ZMM dispatch is right on this CPU.

The forced ChainHash-128 registrations pass the backend as a compile-time constant. Their short-input cost (about 128 cycles) is higher than the dispatched entry point's 116.6; bulk is unaffected.

Files

Reproduce with the repository's README (--host EPYC9R14 --cpus 8-15 --nice 10). The extra rows use records/chainhash/refresh-a0116ea/bench/run_speed.py on the same binary.