The mechanism is stride, and it is legible in the index expression. In the naive `i,j,k` order the inner loop reads `B[k][j]`, walking down a column [6]. Each step skips a whole row, which at n=1024 with doubles is an 8 KB jump per multiply, so almost every access misses and the core sits waiting on memory at 2.6 GFLOP/s [7]. Swap the last two loops to `i,k,j` and the inner statement becomes `C[i][j] += a*B[k][j]` with `a = A[i][k]` hoisted out, so both remaining accesses march along contiguous rows at unit stride [8]. That is the shape the hardware prefetcher and the compiler's auto-vectorizer both handle well [9]. Same arithmetic, same `cc -O2`, 6.3x [2].
Put the rates on a clock. At n=1024 the work is 2*n^3, about 2.15 GFLOP [16]. Naive takes roughly 0.81 s, the reordered loop 0.13 s, and Accelerate about 5.2 ms [17]. So the free reorder recovers about 0.68 s of that 0.81, and everything else in the write-up is a fight over the remaining tenth of a second.
The tiled version loses for reasons the author names: this core has a large L2, the compiler already vectorizes the clean reordered inner loop into wide SIMD stores, and the blocked loop pays index arithmetic and loop overhead to relieve cache pressure that was not yet the binding constraint [10]. His best tile lands at 14.83 GFLOP/s, 11% under the reordered loop [3][18]. The sweep behaves exactly as theory says it should, throughput climbing with block size until three tiles at 3*T^2*8 bytes stop fitting in L2 [11]. For scale, a 256-wide tile of doubles puts that working set at 1.57 MB [19]. Every bar in the sweep still sits below 16.73 [11]. Tiling is the optimization with a diagram, which may be part of why it gets taught first.
For the "skip the blocking" reading to transfer, three things have to hold on your machine: an L2 large enough that a streaming loop is not already thrashing, a compiler that vectorizes the clean inner loop at -O2, and matrices near n=1024 rather than far above it. The author lists the same escape hatches from the other side, naming smaller-cache CPUs, much larger matrices, and multi-level registers/L1/L2 schemes as where blocking pays [12]. Note the third case: in real libraries tiling is a level inside a scheme, not a patch applied to a loop that already streams well.
One caveat the ratio hides, though the post is straight about it: part of the 24.5x is core count, because the BLAS figure carries multithreading across cores alongside SIMD, register blocking and per-CPU microkernels [13][4]. A single-threaded hand loop timed against a multithreaded library is not a per-core comparison, and nothing here tells you how much of the lead survives pinning Accelerate to one thread. The 155x is still the number that governs build-or-call, because closing it means reproducing all four of those techniques and not just the cache one. Loop-level work on this kernel tops out at 4.1% of Accelerate's throughput [20], which is why the author's own conclusion is to measure on your own hardware, call the library for real matmul, and spend hand-written effort where no library exists [15]. The benchmark was published on dev.to, syndicated from lkforge.com [21].
