Roofline model

Two measured ceilings

The roofline is one inequality: attainable FLOP/s is the smaller of peak FLOP/s and bandwidth times arithmetic intensity. Both constants are measurements on the rig, not datasheet numbers:

peak_flops = <GFLOP/s>     # dedicated FMA loop, or hand kernel as a lower bound
bandwidth  = <GB/s>        # copy kernel, counted bytes over time
ridge      = peak_flops / bandwidth    # FLOP per byte

Measure the compute ceiling with a dedicated loop that has enough independent operations to saturate, or use the hand-written kernel and label the result a lower bound. Measure bandwidth with a copy that has no arithmetic to hide behind. Record VLEN, LMUL, dtype, host and QEMU CPU string beside both, because on this rig they are part of the ceiling.

Where the matmul sits

A square f32 matmul performs 2N^3 flops and must move at least 12N^2 bytes, so its best-case intensity is N/6 FLOP/byte. At 512 that is 512/6, roughly 85 FLOP/byte, which is algebra, not a measurement. A naive loop moves far more than the compulsory traffic, and blocking brings it back toward 12N^2, so plot the dot from the traffic the loop actually causes rather than from the formula.

If the dot is right of the ridge, the compute ceiling applies and the gap to it is what remains to gain. If it is left, bandwidth times intensity is the ceiling. The speedup over scalar has its own ceiling: the applicable roofline divided by the scalar rate. The ridge point explains which ceiling applies and therefore what bounds the speedup, not the size of the scalar baseline.

The traffic number is modelled from the loop, because QEMU user-mode does not model DRAM or provide guest counters for this measurement; label it as a model.

Things that break

Datasheet peaks put every kernel under a ceiling the part cannot hold and make the plot recommend nothing. Shape-derived bytes ignore repeated or uncoalesced traffic, so the dot sits at the wrong intensity. And a speedup ratio is not a roofline ceiling; the two answer different questions.