Roofline bounds and the traffic boundary

Operational intensity is not an intrinsic constant of an algorithm name. Count floating-point operations under an explicit convention and count bytes crossing the selected boundary, such as between a last-level cache and main memory. Reuse can make main-memory traffic much smaller than the total volume of load instructions. Write allocation, writebacks, packing, and temporary arrays can increase traffic beyond a minimal source-level estimate. Different boundaries can therefore give different intensities for the same execution.

The numerator needs equal care. A multiply followed by an add is commonly counted as two floating-point operations, including when one fused multiply-add instruction performs both. An integer instruction, a vector instruction, and a floating-point operation are not interchangeable counts. State precision, vector utilization, and the mathematical work being retained. Removing unnecessary operations can lower a reported FLOP rate while improving job time, so useful completion remains the actual outcome to optimize.

At low intensity, the bandwidth slope is lower than the compute ceiling. Increasing reuse can move a kernel rightward and raise this model ceiling without changing available bandwidth. Above the ridge, the compute ceiling is lower, so further reuse alone cannot raise the simplest Roofline limit. Optimizations can also change actual work, achievable vector throughput, or the relevant traffic boundary. Identify those changes explicitly instead of moving a point on a graph without explaining the accounting.

Actual performance may remain far below the roof because of dependency latency, branch behavior, poor vector utilization, synchronization, small problem size, or insufficient outstanding memory requests. A bandwidth number measured by a wide streaming benchmark may not be attainable by an irregular pointer chase. Empirical ceilings characterize their benchmark conditions rather than prove a strict bound for all possible programs. Use compatible precision, thread count, placement, and traffic conventions when comparing a kernel with a reference ceiling.

Blocking or fusion can retain intermediate values and reduce traffic across a chosen boundary, but larger live working sets may spill elsewhere. Fusion can reduce parallel scheduling opportunities or complicate numerical behavior. Compare the measured transferred bytes, useful result, and elapsed time after the change. If the measured point appears above a supposed roof, first check units, operation conventions, traffic estimation, and whether the chosen empirical ceiling actually applies before declaring a physical contradiction.

Test the calculation in the Roofline lab, whose hypothetical compute ceiling stays fixed at 1,000 GFLOP/s. Reset, set intensity I=4 FLOP/byte and bandwidth B=80 decimal GB/s, and predict the 320 GFLOP/s ceiling and 12.5 FLOP/byte ridge before reading them. For a separate comparison, Reset and re-set both controls to I=16 and B=80: the bandwidth roof becomes 1,280 GFLOP/s, so the compute ceiling limits the displayed bound to 1,000. Play or Step traces the roof without changing the selected kernel parameters or its readouts. The two settings match the worked example's traffic assumptions, but the instrument neither measures those bytes nor guarantees any achieved throughput. Explain which traffic-reduction and utilization measurements a real transformation would still need.