bench: roofline datapoint for Apple M2 Pro (Mac mini, cliffs + perf)

[axiom-of-choice]

Datapoint for #137. Adds Apple M2 Pro to the map.

Run from a clean checkout of 263e02f (dirty: false in the report), Mac14,12 Mac mini, macOS 26.5.2 (25F84), AC, automatic energy mode.

matmul inf-cliff ~32758.8  |  slice cliff 4094.1  |  reduce exact <= 2048

The interesting one: the slice clamp is present on M2 Pro

Chip	slice-x16 (Q.4 crop-DMA)
Apple M2 Pro (this run)	clamp @ 4094
Apple M5 Pro	exact (no clamp)

The issue says the pre-A16 crop-DMA clamp is gone by A16/M5, and this is the first M-series confirmation in the table that it is there on an earlier chip. So the boundary is now bracketed from both sides rather than only asserted on one.

The other two look architecture-wide, not per-generation

Both match the M5 Pro:

• matmul inf-cliff ~32759, and flat across K in {4, 8, 32, 64, 128}, consistent with fp16_max/2 independent of reduction depth, which is what I measured by hand in matmul saturates at fp16_max/2 (~32752); two transpose-fed cases return inf even below that #115 before this tooling existed.
• reduce exactness <= 2048, first wrong at 2049 returning 2050.

Worth noting the second one against history: when I probed the integer reduce by hand on this same machine (#115, 2026-07-31) it looked exact past 2048 and I reported it as not reproducing. The suite disagrees, and the suite is right. My hand probe kept the addends small enough that the sum stayed on the exact fp16 grid, so it never actually crossed the boundary the metric measures. The harness picks the boundary case properly. Retracting that half of my earlier report; the per-generation split there was my measurement artifact, not silicon.

Perf half (added)

Ran --perf with sudo from a clean tree. Measured ANE peaks:

Peak fp16 GEMM	Peak perf/W	Streaming bandwidth
3.26 TF/s	1379 GFLOP/s/W	1.0 GB/s

Two table cells stay empty, both for reasons worth stating rather than hiding.

Ridge, and the table's GEMM/bandwidth cells, are blank because of a harness bug I hit and filed as #146. aggregate_rooflines reads those three from roofline_analysis.py, and that step raised KeyError: 'ane'. Cause: layer_norm failed to compile on the ANE at these shapes, so the bandwidth script correctly recorded ane_gbps: None and that archetype's peak block has no ane key, but load_ceilings iterates a hardcoded ("CPU","GPU","ANE") per archetype and raises. Not specific to this machine: any run where one archetype loses one engine loses the whole synthesis. The measured numbers above are in this report's perf_rooflines regardless, so nothing is lost, only unsynthesized. Once #146 lands, re-running aggregate_rooflines.py fills those cells with no new measurement.

Decode is blank for a genuinely different reason, and it is a datapoint. On M2 the decode model's [1, 32000] vocab projection exceeds ANE family 3's 16384 max dimension, so both batch rows return:

NotImplementedError: aneforge: tensor (1, 32000) (op 'matmul') exceeds ANE family 3's
max dimension 16384; tile the graph or target a higher chip.

That is a real per-generation capability limit, not a harness failure. The same model measures fine on your M5 (117 tok/s in the table), so bench/decode_measurement.py currently cannot produce a decode number on family-3 silicon at all without tiling the projection. Worth deciding whether the harness should tile it, or whether the table should distinguish "not measured" from "cannot run on this family".

Not included

Not included

Nothing further. Both halves are in.

Files

• bench/results/rooflines/roofline-apple-m2-pro-Mac14_12-723396ad9091-1c1aa174.json (new)
• bench/results/ROOFLINES.md (regenerated with bench/aggregate_rooflines.py, now 2 machines)

[axiom-of-choice]

@sbryngelson Feel free to edit this contribution sections