Repository navigation
docs: correct overstated claims, cite the Go issues, state measured results - #18
Merged
Merged
Conversation
…esults A review of the round-2 write-ups against the measurements: - README: the SIMD kernels exist on amd64 and arm64 only (it said all six targets, selected at run time); it now lists them all (not only the sum), and the performance summary states what was measured on a Zen 3 against NumPy 2.5.3, including where go-ndarray is slower, instead of only the Apple-silicon parity results. - perf.md: the parallel-GEMM stall and NumPy's threaded-dot advantage are hypotheses, not findings (the GEMM drop already shows at 2 cores of one core complex, which the shared-panel explanation does not cover); the "40% in the edge loop" profile covered 64^2 and 512^2 together; the Workspace table is best of two, not median; 43 GFLOP/s is not a measured peak; ULP figures name their sample sizes. - The amd64 math.Exp bug is now golang/go#81995 (reproduced with Go 1.26.8 and 1.27.1 on Zen 3, Cascade Lake and Haswell, with and without FMA); the math.Log one was already golang/go#56600. The note that math.Exp returns 0 just above ln(2^-1075) is about arm64, not amd64, and is a last-place difference, not a bug. The README example was compile-checked. No code change. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The docs and two kernel comments said Go's loong64 and ppc64le assemblers expose no vector-double arithmetic. Checked on Go 1.26.4 and 1.27.1 by assembling and disassembling: true for ppc64le, but loong64 has vector add/sub/mul/div (VADDD assembles to vfadd.d, VMULD to vfmul.d, XVADDD to xvfadd.d; no vector FMA), s390x has them with FMA (VFADB, VFMADB), and riscv64 has them behind the optional V extension. So kernels for those three are work not yet done, not a toolchain wall. Also drop the claim that these targets beat NumPy: they were never measured against it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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
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.
A review of the round-2 write-ups against the measurements:
targets, selected at run time); it now lists them all (not only the
sum), and the performance summary states what was measured on a Zen 3
against NumPy 2.5.3, including where go-ndarray is slower, instead of
only the Apple-silicon parity results.
hypotheses, not findings (the GEMM drop already shows at 2 cores of one
core complex, which the shared-panel explanation does not cover); the
"40% in the edge loop" profile covered 64^2 and 512^2 together; the
Workspace table is best of two, not median; 43 GFLOP/s is not a
measured peak; ULP figures name their sample sizes.
and 1.27.1 on Zen 3, Cascade Lake and Haswell, with and without FMA);
the math.Log one was already math: math.Log does not handle subnormal floating point number on amd64 golang/go#56600. The note that math.Exp
returns 0 just above ln(2^-1075) is about arm64, not amd64, and is a
last-place difference, not a bug.
The README example was compile-checked. No code change.
🤖 Generated with Claude Code