Document array_windows/array_chunks' role in the GEMM numbers - #298
Merged
Conversation
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 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012wrzeZAdwGYTCKoxamwQht
Contributor
|
Important Draft PR not reviewedDraft PRs are not automatically reviewed by default.
To automatically review draft PRs, update your CodeRabbit configuration: reviews:
auto_review:
drafts: trueComment |
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_87570fad-c663-4d9f-9e22-4d28d6a0731f) |
AdaWorldAPI
marked this pull request as ready for review
September 4, 2026 14:08
AdaWorldAPI
pushed a commit
that referenced
this pull request
Sep 4, 2026
PR #298 claimed the 512x512/1024x1024 GEMM numbers depend on simd_ops::array_windows/array_chunks. Tracing the actual call graph (backend::native::gemm_f32 -> matrixmultiply crate's Goto algorithm; simd_ops::gemm_f64_tiled -> fixed TILE=64 blocking with F64x8 register accumulation) shows neither path calls array_windows or array_chunks at all -- their only production call site is hpc::blake3's 64-byte block chunking. Corrected the README to describe the GEMM kernels' real mechanism and to attribute array_windows/array_chunks to where they're actually used, without losing the real (separately verified) array_windows-vs-JIT latency finding. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012wrzeZAdwGYTCKoxamwQht
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Documents on the public README that the 512x512/1024x1024 GEMM Performance table rows depend on
simd_ops::array_windows/array_windows_checked+array_chunks(paired with the polyfilledmul_add/add_mul_*FMA primitives), not just Goto-algorithm cache blocking alone.Why
This was previously only documented internally (
.claude/knowledge/agnostic-surface-cpu-matrix.md), not on the public README. It's real, measured functionality:array_windowswas benchmarked per-call against both the original C blasgraph kernel and an actual Cranelift JIT — roughly 7 ns (original C blasgraph) vs 12 ns (Cranelift JIT) vs 17 ns (staticarray_windowsmicrokernel) — landing close to the JIT's throughput without paying for a JIT (compile latency, codegen complexity, dependency).What this is not
Documentation-only — no code changes.
Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_012wrzeZAdwGYTCKoxamwQht
🤖 Generated with Claude Code
https://claude.ai/code/session_012wrzeZAdwGYTCKoxamwQht
Generated by Claude Code
Summary by CodeRabbit