Roofline Explorer
Every flop record carries an arithmetic intensity and a bound_by field. Every accelerator record carries peak FLOPS and memory bandwidth. Join them and the ridge point — where a part crosses from memory-bound to compute-bound — falls out as 1000 × TFLOPS ÷ GB/s. That number decides which hardware property actually matters for each workload.
Accelerator ridge points
Ridge = 1000 × dense TFLOPS ÷ memory bandwidth (GB/s). Higher is better — it means the part stays memory-bound at larger batch sizes.
| Accelerator | VRAM | Bandwidth | Dense TFLOPS | Ridge (flop/byte) | FP8 TFLOPS | FP8 Ridge | Status |
|---|---|---|---|---|---|---|---|
| Loading… | |||||||
Flop classes by bound
Each class's arithmetic intensity and the knob that moves it. Sorted by bound type.
| Class | Bound by | Arithmetic intensity | Scales with | Status |
|---|---|---|---|---|
| Loading… | ||||
How to use this
Memory-bound classes (decode GEMM, decode attention, MoE experts, KV transfer) are limited by memory bandwidth. The ridge tells you the batch size at which the part becomes compute-bound — below it, you are buying bandwidth, not FLOPS.
Compute-bound classes (prefill attention, reranking, batch encoding, diffusion) are limited by tensor-core FLOPS. The ridge tells you the context length at which attention becomes compute-bound — above it, you are buying FLOPS.
Interconnect-bound classes (MoE routing, TP all-reduce, KV transfer) are limited by link bandwidth. No ridge point applies — the cost is in the network, not the compute.
Every accelerator and flop class links to its record page. The ridge computation is done by tools/build_joined_views.py from the records' own FLOPS and bandwidth figures.