Skip to content

docs: refresh the performance claims #26

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
tannevaled merged 1 commit into from
Oct 9, 2026
Merged

docs: refresh the performance claims #26

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 9 additions & 3 deletions docs/index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -101,15 +101,21 @@ is wrong on subnormals
(3.7–5.9× from 512²).
- **At parity:** `SumAxis(0)`, `Inner` against 16-thread OpenBLAS, `Log` on
one core.
- **Slower:** `MatMul` against 16-thread OpenBLAS (0.55× at 1024², 0.3× at
256² and below); `Dot`/mat·vec against NumPy's threaded BLAS (0.16×); `Exp`
- **Slower:** `MatMul` against 16-thread OpenBLAS at 512² and up (0.42× at
512², 0.51× at 1024², measured in one run; at 256² ours is 1.44× faster);
`Dot` and mat·vec against NumPy's 16-thread BLAS (0.69× and 0.52× since
v0.6.0's helper pool; 0.16× before); `Exp`
below 256 Ki elements (0.82×); the *allocating* forms of elementwise ops up
to 256 Ki elements, `Concatenate`/`Stack` and slice copies outside a
`Workspace` (0.2–0.5×).

On Apple silicon the GEMM reached parity with tuned BLAS at 1024² (OpenBLAS in
an arm64 VM, single-threaded vecLib on an M4 Max) and beats the pure-Go
**gonum 4–10×**.
**gonum 4–10×**. On the other targets, against go-ndarray's own scalar code on
one core: on a RISC-V SpacemiT X60 the RVV kernels cut `Sum` by up to 5.8× and
`MatMul` time by 31–45%; on an IBM z17 the s390x kernels cut `MatMul` 1024²
from 340 to 70 ms and `Max` by 92–96% (see [Performance](performance.md),
*SIMD coverage*).

CI runs the suite on amd64, arm64 and 386 natively and on
riscv64/loong64/ppc64le/s390x/arm under qemu, on Linux, macOS and Windows,
Expand Down
6 changes: 6 additions & 0 deletions docs/performance.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -36,6 +36,12 @@ here is measured, every win is real, and where NumPy still leads it says so.
> micro-kernel from 7.0 to 27.5 GFLOP/s and the serial GEMM from 5.3 to 20.0
> GFLOP/s at 512², against the scalar code; no NumPy or BLAS reference was
> available on that host (see *loong64: LASX kernels*).
> On a RISC-V SpacemiT X60 (VLEN 256) the RVV kernels added in v0.7.0 make
> `Sum` up to 5.8× faster and, with v0.7.1's 6×8 micro-kernel, cut `MatMul`
> time by 31–45%, one core against the scalar code. On an IBM z17 (a z/VM guest
> on real hardware) the s390x kernels cut `MatMul` 1024² from 340 to 70 ms
> (v0.9.0) and `Max` by 92–96% (v0.9.1), likewise. Neither host had a NumPy or
> BLAS reference (see *SIMD coverage*).
> SIMD kernels exist on **amd64, arm64, ppc64le, loong64, riscv64 and s390x** (LASX,
> RVV and the s390x vector facility used only when the CPU reports them); the
> 32-bit targets run the pure-Go reference code; the s390x kernels are measured
Expand Down
Loading