What does this equation mean?

while the useful work performed is r $\cdot$ c $\cdot$ L multiply-accumulates — one per cell, once per streamed step, in steady state. Dividing useful work by the total cell-cycles available, r $\cdot$ c $\cdot$ T , gives an idealised utilization $\eta \approx \frac{L}{L + r + c - 2}$. As the streamed sequence L grows large relative to the array’s dimensions, $\eta$ approaches one and the fill-and-drain overhead becomes negligible. But when L is comparable to r and c — a small batch, a short sequence, a matrix dimension that barely exceeds the array’s own size — the overhead is not a rounding error, it is a large fraction of every pass through the array. This is a simplified model, not a specification of any one vendor’s pipeline, but it is the same effect Google’s own engineers measured directly rather than modelled: in their reported case study of one convolutional workload, the TPU spent less than half its cycles performing matrix operations at all, and on the cycles it did spend computing, only about half of the 65,536 available multiply-accumulate cells “held useful weights because some layers… have shallow feature depths” — with roughly 35% of all cycles lost simply waiting for a new weight tile to load [ 2 ] . Independently, the SCALE-Sim simulator was built specifically because the research community lacked tooling to see this kind of effect at all, and its authors report using it to show, across vision, speech, text, and game-playing workloads, that memory bandwidth, dataflow choice, and an array’s aspect ratio each materially change realised runtime and energy for kernels that share the same nominal peak throughput [ 6 ] . A vendor’s peak-TOPS figure describes the array. It does not describe what any particular workload, at any particular batch size, will actually draw from it.