One fmla in eleven instructions keeps a NEON matmul at 7% of the M2's 112 GFlops

The 112 GFlops target describes a loop that does almost nothing except multiply. One fmla on a 128-bit register performs four lanes of multiply-accumulate, so eight flops per instruction ^[2]. Four fmla per cycle is 32 flops per cycle, and at 3.5 GHz that comes to 112 GFlops ^[1]. Reaching it means four fmla issue every cycle, with their operands already in registers.

Compare that to the kernel that measured 7.86 GFlops ^[9]. At eight flops per fmla, 7.86 GFlops is about 0.98 billion fmla per second, one every 3.6 cycles at 3.5 GHz ^[4]. The published inner loop over k is eleven instructions: a compare and a branch, two madd to compute the A and B offsets, a shift and an add to turn one offset into a byte address, a ldr q for four floats of B, a ld1r to broadcast one float of A, the fmla, then the k increment and the loop branch ^[10]. Eleven instructions in 3.6 cycles is roughly three instructions retired per cycle ^[5].

There is a dependency problem on top of that. The register v2 is the only accumulator, cleared once before the k loop, and each fmla reads back the value the previous one wrote ^[11]. The author's next kernel opens with four accumulators and the comment "We are using 4 here to remove dependencies within K blocks" ^[12], pulls four consecutive A values with a post-incrementing ld1r, and advances the B offset by N shifted left two between four q loads ^[14]. That structure spreads the two madd computations across four fmla instead of one. The excerpt ends mid-instruction inside that kernel ^[18].

The scalar assembly result is the one I would keep. Writing the same loop by hand produced 1.98 GFlops against the compiler's 2.09 at -O2, about 5 percent slower ^[5][4][6], and the author wrote "the c compiler is smarter than me." ^[6] The 3.8x that followed came from switching the instruction ^[7].

Memory access is the other half of the gap. B is addressed at offset (k * N + n) ^[15], so each step of k walks forward N floats. At the top of the sweep N is 1024 ^[3], a 4 KB jump per step and 4 MB of B touched per pass ^[8]. Neither kernel packs or blocks B, and the figure quoted for each one is a single average across the whole sweep from 64x64 to 1024x1024 ^[3]. That average covers the shapes that fit in cache and the ones that do not.

The post explains its motivation with "and yet people keep making all these dang ARM computers in my cloud" ^[16], and then measures a MacBook Air with an M2 ^[1]. It does not benchmark a cloud instance. For these percentages to carry over you need a core at the same 3.5 GHz with four FMA pipes and 128-bit vectors ^[2]; move any of the three and the denominator moves with it. The author says the next article will use SME/SVE2 ^[17].