Graviton5 instruction and sequential-work study

Three parallel agents optimized SHA3-256, mixed integer multiplication, and integer division across the owner's Apple M4, the Hetzner EPYC Genoa VM, and the existing AWS Graviton5 c9g.4xlarge. The parent agent separately instrumented RandomX's JIT phases and compared default/native compiler targeting.

Development and short exploratory tests ran concurrently. Final measurement windows were explicitly serialized across agents: multiply, SHA-3, division, then RandomX. Inside a window, the same study could run on the three different machines simultaneously. This removes competition among our studies during final runs, but does not remove existing background services, the production Nitro enclave, unknown cloud co-tenants, or operating-system activity.

Linux tests use one pinned worker. A Hetzner vCPU does not establish exclusive ownership of its physical core or SMT sibling. macOS does not provide a hard performance-core pin through these harnesses; the OS controls placement. No production services were restarted, no security settings were changed globally, and no existing work was discarded.

Results

Best tested valid implementation per machine; medians of repeated final runs. All timings below are nanoseconds per complete hash or dependent arithmetic round, as labeled. Smaller is faster. Compare machines within a row, not work amounts between different rows.

Graviton's clearest observed advantage is low-half multiplication with fused addition and dependent bit mixing: 1.52x over M4 and 1.82x over Hetzner. The inspected Graviton dependency path uses MADD followed by EOR with a folded rotation; x86 needs IMUL, ADD, RORX, then XOR. Explicit ARM scheduling preserved this advantage when tested on M4 too. Wider mixed integer state also favored Graviton, but forcing SIMD for the 32-bit round reversed the ranking: Hetzner won that implementation. The table correctly chooses scalar code on ARM and SIMD on x86 for identical semantics.

SHA3's best complete-chain rates are 6.813M / 8.072M / 4.056M hashes/s on Graviton / M4 / Hetzner. Graviton is 1.68x Hetzner. All implementations use the same OpenSSL 3.5.0 permutation source, with custom register-resident wrappers and full unrolling preserving all 24 rounds and standard SHA3 padding.

SVE integer division helped Graviton relative to its scalar implementation, but the optimized x86 32-bit result was effectively tied (1.2% difference). Explicit AVX-512 conversions removed a misleading compiler disadvantage on x86. M4's scalar division won both division cases. Bit permutations favored Graviton over the tested M4 software implementation, while Hetzner's BMI2 implementation won both cases.

Optimization and validation

The studies tested native compiler targeting, unroll factors, scalar/SIMD alternatives, explicit ARM scheduling, hardware crypto instructions, lower- overhead SHA3 assembly wrappers, full Keccak unrolling, exact floating-point quotient estimates with integer correction, x86 unsigned vector conversions, and hardware/software bit permutations. An affine accumulator diagnostic initially reassociated by the compiler was corrected and excluded from claims about nonlinear sequential work.

Independent Python references validate arithmetic states and short SHA3 chains. All 42 final ten-million-hash SHA3 runs agree. Corresponding billion- round multiplication checksums, thirty-million-round division states, and five-million-round bit-permutation states agree across machines and equivalent implementations. A second agent independently reviewed the floating-point correction's mathematical bounds; its validity is limited to the documented operand ranges. Each detailed study retains code, assembly, raw measurements, compiler metadata, and a verified artifact hash manifest.

Existing RandomX

Instrumenting RandomX showed Graviton spends 90.6% of hashing time executing the generated program, 1.8% compiling it, and 2.3% changing JIT page permissions. Native targeting produced 570.9 H/s versus 571.6 H/s at default targeting: no useful improvement. M4 and Hetzner also showed no benefit in the comparable native-targeted probes. The Mac experiment caught and corrected a -march=native configuration that accidentally selected software AES; the production/default build already selected hardware AES correctly.

The twenty final RandomX samples all agree on their deterministic chain digest. These probes retain the algorithm, secure JIT, and existing allocation tuning. No production change resulted from this compiler-targeting experiment.

Detailed studies

• SHA3-256 strict chain
• Mixed multiply/add and wider-state rounds
• Integer division and bit manipulation
• RandomX JIT profiling/compiler targeting

Interpretation

A complete SHA3-256 hash, a RandomX hash, and a small arithmetic round perform very different amounts of work. Their numerical rates must not be compared as interchangeable hashes per second. Within each row of a study, input/output semantics are the same across machines and the fastest tested valid implementation is selected per host. That still does not establish the fastest possible implementation on any architecture.

These measurements do not demonstrate a minimum decryption delay. The custom arithmetic rounds are performance probes, not reviewed cryptographic delay functions. Replacing or modifying RandomX would change the security argument; its assumed strength cannot automatically be transferred to a new instruction mix. A published CPU advantage also does not prevent an adversary using the same hardware or specialized circuitry.