What does this equation mean?

It is tempting to compare these four families by a single number — peak operations per second, or operations per watt — and the rest of this article explains why that number, alone, is close to meaningless. A more useful decomposition separates what a device can theoretically do from what a piece of software actually gets it to do, and splits that gap into two distinct causes: $T_{\mathrm{achieved}} = T_{\mathrm{peak}} \cdot U_{\mathrm{hw}} \cdot U_{\mathrm{compiler}}$. Here $T_{\mathrm{peak}}$ is the arithmetic identity fixed at design time, $U_{\mathrm{hw}}$ $\in$ (0,1] is the fraction of cycles the hardware keeps its arithmetic units genuinely busy on whatever workload is thrown at it, and $U_{\mathrm{compiler}}$ $\in$ (0,1] is the fraction of a program’s theoretically available parallelism that the compiler or mapper actually manages to expose to the hardware. A GPU’s SIMT scheduler mostly targets $U_{\mathrm{hw}}$ , hiding latency and filling gaps dynamically regardless of how well the source program was written. A systolic array and a statically scheduled dataflow chip push almost the entire burden onto $U_{\mathrm{compiler}}$ : there is no runtime mechanism left to rescue a poorly mapped program. Sze and colleagues make exactly this point about dataflow choice inside a fixed processing-element array, cataloguing weight-stationary, output-stationary, row-stationary and no-local-reuse dataflows that each keep a different operand fixed in the register file to maximise reuse for a given data-movement energy budget, and observing that because “all of the variables are known before runtime,” an offline mapper can be built to choose the energy-optimal dataflow for a given layer shape and hardware configuration [ 10 ] . That is $U_{\mathrm{compiler}}$ as an explicit design target rather than something left to chance.