How these numbers are taken¶
Every data page answers one question: how does TileOPs compare to the fastest alternative implementation of the same op, on the same workload? Each op gets one table, with one row per workload. Nothing is averaged across workloads: every number on the page belongs to a single shape and dtype.
The colour is the verdict¶
| Meaning | |
|---|---|
| 0.74× | Slower than the alternative — below 0.95×. |
| 1.02× | Level with it — 0.95–1.05×, inside measurement noise. |
| 1.42× | Faster than it — 1.05× and above. |
| 18.06× | No fast alternative to compare against — only a functional reference (a name ending in -ref). The number means little. |
| — | No alternative at all ran on this workload. |
A ratio is the alternative's device time divided by ours, so above 1 means TileOPs is faster.
Columns¶
| Column | Meaning |
|---|---|
| Workload | The shape and dtype the row was measured on, as the benchmark names it. |
| Ratio | alt / ours — the fastest alternative's device time divided by ours, the one number the colour grades. |
| Device time | Milliseconds the device spent executing the call's kernels — the union of their intervals. Every comparison on these pages uses it. |
| Alternatives | One line per other implementation measured on this workload, fastest first, with its own device time in ms. A tuned library kernel (fla, mamba, fa3, triton, …), a native PyTorch op (torch), or a name ending in -ref — an eager composition of PyTorch ops, which is not a bar worth reporting a win against. Divide any of them by our device time to get the ratio against that one. |
| Throughput | TFLOP/s: required FLOPs / device time. The count is analytic — the op's eval_roofline formula evaluated on the workload's own shapes, not a hardware counter — so it counts the work the problem demands, not the instructions the kernel issued. Padding, recompute or a masked-out tile is therefore invisible here, and the figure is only comparable between implementations of the same op on the same workload. |
How that device time is measured — what it counts, what it leaves out, and where it refuses to produce a number — is in Benchmark Timing.
Each op's heading carries its workload count and its test outcome (✅ passed · ❌ failed · ⏭️ all skipped · · no test matched).
Utilisation against the hardware ceiling — what share of peak FLOP/s or HBM bandwidth a kernel reached, and which of the two bounds it — is a different question and is not on these pages. It says how much of the machine a kernel uses, not whether someone else's kernel does the same work faster.
Empty cells¶
· means an input to that metric was not recorded, never that the value is zero: the op reported no FLOP count for that workload, or no alternative ran on it.