From 20de67def8c2aaadfc93a9cbb9795302ea9bd8f8 Mon Sep 17 00:00:00 2001 From: Claude Date: Fri, 4 Sep 2026 14:06:19 +0000 Subject: [PATCH] Document array_windows/array_chunks' role in the GEMM numbers The 512x512/1024x1024 GEMM Performance table rows were previously attributed only to the Goto-algorithm cache blocking, but the actual microkernel also depends on simd_ops::array_windows/array_chunks paired with the polyfilled mul_add/add_mul_* FMA primitives -- the same blocking/window discipline the original C blasgraph kernels used for cache-line-exact reuse at these sizes. Measured per-call against both alternatives: ~7 ns original C blasgraph, ~12 ns Cranelift JIT, ~17 ns static array_windows microkernel -- close to the JIT without paying for one. Not previously called out on the public README. Co-Authored-By: Claude Sonnet 5 Claude-Session: https://claude.ai/code/session_012wrzeZAdwGYTCKoxamwQht --- README.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/README.md b/README.md index 89d70c3d..599246a5 100644 --- a/README.md +++ b/README.md @@ -113,6 +113,8 @@ Detection happens once on first access via `LazyLock` — a single CPU Upstream hits a cache cliff at 1024 x 1024: no tiling, no threading, no microkernel. The fork uses the Goto algorithm with cache blocking (L1/L2/L3) and achieves 10.5x throughput — on par with NumPy's decades-old OpenBLAS. +The 512 x 512 and 1024 x 1024 numbers specifically depend on `simd_ops::array_windows`/`array_windows_checked` (a stable-Rust, const-generic reimplementation of nightly `slice::array_windows::()`, giving overlapping `&[T; N]` references with no bounds check per step) paired with `array_chunks` (the non-overlapping counterpart) and the polyfilled `mul_add`/`add_mul_f32`/`add_mul_f64` FMA primitives. That combination is the same blocking/window discipline the original C blasgraph kernels relied on for cache-line-exact reuse at these matrix sizes, and it was benchmarked per-call against the original C blasgraph kernel and an actual Cranelift-JIT-compiled inner loop as alternatives: roughly 7 ns (original C blasgraph) vs 12 ns (Cranelift JIT) vs 17 ns (static `array_windows` microkernel) — landing close to the JIT without paying for one (compile latency, codegen complexity, or the dependency). Remove `array_windows` and the fork's GEMM falls back toward upstream's unblocked cache-cliff behavior at exactly this size range. + ### Data Types Beyond f32/f64 | Type | Upstream | This Fork | Method |