README speedup table

Columns that carry the claim

| Kernel | Shape | Scalar C GFLOP/s | Scalar spread | RVV GFLOP/s | RVV spread | Speedup | Samples |
| --- | --- | --- | --- | --- | --- | --- | --- |
| matmul f32 | 512x512x512 | <median> | <spread> | <median> | <spread> | <speedup>x | 20 |
| ew_add f32 | 1048576 | <median> | <spread> | <median> | <spread> | <speedup>x | 20 |

Each row is one comparison at one shape: the scalar C baseline against the RVV path. The scalar columns are not symmetry: without the baseline’s own spread you cannot tell whether the ratio clears the noise. Both kernels carry the same sample count because they came from the same interleaved session.

Name the estimator in the caption. The ratio of two medians, the median of per-sample ratios, and the ratio of two single runs are three different numbers, and a reader who cannot tell which one you used cannot reproduce it.

The line under the table

Footnote the rig directly beneath it: QEMU CPU string, VLEN, LLVM commit, sample count. A speedup without that line is a figure nobody can check, and every row here is an emulated figure. It supports one statement, that on this rig this instruction stream did more work per second than that one. It does not support a claim about a RISC-V core, and the caption should say so before a reader assumes otherwise.

The table is generated from results/<commit>.tsv, not typed. Retyping breaks the chain between claim and artifact, and a stale digit becomes indistinguishable from a fresh one.

Things that break

A row whose spread is wider than its speedup: the ratio sits inside the noise and the cell should say so instead of printing the favourable end of the band. The other failure is a mixed table, GFLOP/s in one row and GB/s in the next under a single header, or a row kept because the timing looked good after its reference check failed. That second one is a correctness bug wearing a performance number.