GPU writeup and story

Four paragraphs

The writeup is four moves. Problem: what was slow, for whom, against which baseline, at which shapes. Roofline: the two measured ceilings, the arithmetic intensity, and the ceiling the kernel should reach. Steps: each optimisation followed by the measurement that came after it, so a reader can see tiling raise intensity and pipelining hide latency. Result: <ms> and <speedup> with the band, the shape, the dtype, and the device name from torch.cuda.get_device_name().

Keep the attempts that failed

A story with no failures reads as a tutorial. The config with num_stages too deep for the shared-memory budget, the tile that spilled registers, the fusion that lost at short sequence length: each is evidence that you searched and that you know which constraint binds. Interviewers ask what did not work, and the answer should be a measurement rather than a shrug.

Numbers with provenance

Every figure traces to results/<commit>.json, and that file records the commit, the driver, triton.__version__ and the GPU. Nothing is typed by hand, for the same reason the RVV table is generated: a stale digit is indistinguishable from a fresh one. The writeup links the artifact, the harness and the baseline so a reader can rerun the comparison.

Things that break

A speedup whose baseline is unnamed, so nobody can tell whether the comparison was materialised attention or a fused library. A roofline drawn with spec-sheet peaks, which makes the kernel look like it has headroom it does not have. An optimisation presented without the before-and-after measurement, which turns the story into a list of techniques rather than a record of what worked. And a writeup that quotes a number from the autotuner without the config, so the result cannot be reproduced on another device. The figures come from Triton 3.9 do_bench; confirm its return units and the triton.__version__ you record against your installed environment.