Repository navigation
Conversation
amax_vector.c reduces every LMUL-2 strip into a scalar, which serialises the loop. The new amax_zvl256b.c keeps one LMUL-8 accumulator and reduces once; for unit-stride data larger than 2 MiB, which streams from DRAM, it uses four LMUL-1 accumulators instead, because on the SpacemiT X100 small vector loads sustain a markedly higher single-core DRAM read bandwidth than LMUL-8 loads. On the X100 DAMAX is about 3x faster in cache and 1.45-2x faster from DRAM for 16-byte aligned data. The result starts from 0 as before, so results are unchanged. SAMAX keeps amax_vector.c, and C910V is not affected.
This branch has not been deployed
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.
Summary
On RISCV64_ZVL256B, DAMAX uses
amax_vector.c. That kernel reduces every LMUL-2strip into a scalar accumulator, which serialises the loop. This PR adds
kernel/riscv64/amax_zvl256b.cand uses it for DAMAX only. The new kernel:vfmaxaccumulator and reduces once at the end;LMUL-1 accumulators instead.
The second path is based on measurements on the SpacemiT X100, where the
single-core DRAM read bandwidth depends strongly on the width of the vector
loads:
The result still starts from 0, so results are bit-identical to the old kernel.
C910V and SAMAX keep
amax_vector.c.Performance
Platform: SpacemiT K3, one X100 core (2.2 GHz), single thread, GCC 15.2.
cblas_damax, unit stride, called through the public API. Each number is themedian ns per call over 4 processes per build, alternating. Offsets are in
elements from a 64-byte aligned buffer: 0, 2 and 4 are the 16-byte
alignments that malloc/NumPy give, and large glibc blocks sit at offset 2.
At every size and offset, all patched processes were faster than all develop
processes. An earlier job measured 1.45x / 1.84x / 1.99x at n = 4194304. The
develop kernel's DRAM rate at offset 0 varies between runs.
Caveat: at odd offsets (8 but not 16 byte aligned) with n = 4M, the
patched kernel measured 0.89–0.98x of develop. In the same job, the
unchanged SAMIN/DAMIN kernels also varied between 0.80x and 1.01x at odd
offsets at that size, so I consider those cells within run-to-run noise.
SAMAX was measured as well:
DAMIN, with this structure, is about 2.9x faster in cache but up to 9%
slower from DRAM. That is because
amin_vector.chappens to stream fromx+1, where on the X100 every LMUL-2 load spans two cache lines, and that isfast. Neither SAMAX nor DAMIN is switched in this PR.
Testing
OpenBLAS tests. The default
makegoal's tests give identical results:utest 141/141, extension tests 1479/1479, and all BLAS/CBLAS tests PASSED.
Differential check against develop, 8640 cases covering:
cblas_samax/samin/damax/damin;2 MiB switch;
The outputs are byte-identical.