Cross-generation results wanted: Autolykos gather-only versus full Metal search

[giffeler]

Purpose

I am collecting comparable Apple Silicon measurements for an unexpected Metal compute result.

ErgoMetal’s normal search kernel performs seed hashing, 32 pseudo-random 32-byte reads from a consensus-sized dataset, 256-bit accumulation, and a final BLAKE2b compression. A deliberately non-consensus gather-only variant retains the same seed calculation, index distribution, reads, and accumulation, but omits the final compression.

The stripped kernel was intended to approximate an upper bound for the random-gather stage. On an Apple M4, however, it was consistently slower than the complete search kernel.

M4 reference result

The reference campaign used:

• full 216,430,305-element dataset, occupying 6,925,769,760 bytes
• 30-second measured intervals
• one excluded warm-up
• four order-balanced rounds
• start temperatures between 48.60 °C and 49.96 °C
• Release build based on commit 0b54038d2d3f08b61f32ae59ee4661ec8331550e

Median active throughput:

Variant	Million nonces/s
Complete search	3.107991
Gather-only	2.951784

The median ratio was:

search / gather-only = 105.292%

The four same-round ratios ranged from 103.180% to 105.740%.

How to reproduce

This campaign creates sustained GPU load and needs enough unified memory for consensus-sized active and prefetched datasets. Please do not force the allocation if Metal reports insufficient recommended working-set capacity.

Build the Release executable as described in the README, then run:

DURATION=30 WARMUP_RUNS=1 START_TEMPERATURE_CELSIUS=50 \
Scripts/benchmark-ab.zsh /tmp/ergometal-gather-ab 4 \
  "search:--search-kernel search" \
  "gather:--search-kernel gather-only"

Omitting TABLE_SIZE is intentional: it selects the consensus-sized dataset. The campaign writes the individual snapshots and event histories together with results.jsonl and summary.json.

For the closest comparison with the original result, use commit:

0b54038d2d3f08b61f32ae59ee4661ec8331550e

Please report

Mac model:
Apple chip:
GPU core count:
Unified memory:
macOS version and build:
Xcode version:
Git commit:
Executable SHA-256:

Measured start-temperature range:
Search median active throughput:
Gather-only median active throughput:
Search / gather-only ratio:
Same-round ratio range:
Session peak-temperature range:
Errors or temperature-gate timeouts:
summary.json SHA-256:

Results from smaller diagnostic tables are welcome, but please identify them clearly; they are not directly comparable with the full-table reference campaign.

Current interpretation

The result does not prove that trailing arithmetic improves this workload. Removing the final compression may alter register allocation, scheduling, or useful latency hiding enough to make the stripped kernel a poor ceiling model. Compiler and GPU-generation effects are also plausible.

The conservative project decision was therefore to leave the production search kernel unchanged and not pursue speculative register-pressure or manual memory-level-parallelism rewrites.

The main questions are:

1. Does the ordering reproduce on M1, M2, M3, M4, or M5 variants?
2. Does it change with the Metal compiler version?
3. Which occupancy, limiter, bandwidth, or cache counters best explain the difference?

References

• ErgoMetal repository
• Complete reference campaign report
• Metal search kernels