Tile-size sweep

Sweep, do not sample

The bench target already prints one fixed-order line per kernel. Give scripts/run_bench.sh a tile triple from the environment, then loop over the triples and keep every row:

printf 'bm\tbn\tbk\tkernel\tshape\tmedian\tspread\treps\n' > sweep.tsv
for bm in 2 4 8; do
  for bn in 2 4 8; do
    for bk in 4 8 16; do
      TILE=$bm,$bn,$bk ./scripts/run_bench.sh | tail -n +2 \
        | sed "s/^/$bm\t$bn\t$bk\t/" >> sweep.tsv
    done
  done
done

One row per kernel per triple, appended, never retyped. The file is the evidence; the plot is generated from it.

Read the curve, not the winner

Find the minimum, then look at its neighbours, because that is where the information is. The usual shape is a plateau, a steep loss of performance on one side where the working set stops fitting the level you targeted, and a gentler loss on the other where per-tile overhead dominates. Report the plateau and its edges. Report the spread from the harness beside each median, so a difference smaller than the spread is not called a win.

No tile size appears in this node. None was measured for it, and a number invented here would be worse than a blank: it would look like a result, be copied into a README, and quietly become the schedule everyone uses.

Things that break

Rows from different builds are not comparable, and a compile-time TILE macro plus make’s timestamp logic is the standard way to get them: the binary is not relinked, the label says one triple, the code is another. If the tile does not divide the shape, the sweep also compares different amounts of work, so check the shape column against the reference shape before plotting a row. Quoting the minimum row as the tuned schedule is the p0-04 mistake repeated at schedule level: it reports the luckiest sample and discards the evidence of how noisy the rig is.