OpenMathLib/OpenBLAS

OpenBLAS

Performance History

Latest Results

sbdot: convert in stack blocks instead of malloc'ing two n-float buffers kernel/x86_64/sbdot.c is the SBDOT kernel of every BFLOAT16 build, on all architectures (no KERNEL file overrides it; the Makefile build enables BFLOAT16 by default on arm64 and POWER). Except for unit-stride calls served by the AVX512-BF16 kernel (Cooperlake/Sapphire Rapids), each call, or each thread part, malloc'ed float copies of x and y without a NULL check, converted them with SBF16TOS_K and called SDOTU_K once. Convert blocks of 1024 elements into one stack array instead, with an inline conversion that gives the same bits as bf16to.c (denormals become signed zeros, NaNs are made quiet, all other values are exact), and call the same SDOTU_K per block. The first block result is taken as is and later ones are added in order. The array is aligned to 64 bytes by hand because MSVC builds this file too. Where the AVX512-BF16 kernel exists, the generic path is kept out of line so that the accelerated path does not set up its 8 KB frame. Results are bit-identical whenever a thread part has at most 1024 elements. For longer vectors the block results are added in float, which can change the result at rounding level and the payload of NaN results; where SDOTU_K accumulates in double or x87 precision, sums close to the float overflow or underflow limits can differ by more. This also fixes a hang on arm64: kernel/arm64/dot.c threads SDOTU_K again from inside each sbdot worker thread, and in the default (pthreads) build that nested call never got a thread once sbdot itself used all of them (on a 14-core Jetson Thor: n >= 552960 with the default thread count). The 1024-element calls stay below dot.c's threading threshold. On a Zen 2 host, one thread, with the Zen, Haswell, Nehalem, Sandybridge and Core2 kernels and incx 1 or 2, sbdot gets 1.18-1.57x faster for n <= 100, 1.65-1.89x at n = 1024, 2.48-2.70x at n = 4096, 5.91-6.12x at n = 20000 and 7.39-8.11x for n = 10^5..10^6 (OPENBLAS_NUM_THREADS=4, Zen and Haswell kernels: 7.2-7.8x for n = 10^5..10^6). On a Jetson Thor (Neoverse V3AE, NEOVERSEV2 kernels), one thread: 1.54-2.43x for n <= 4096 and 7.17-7.90x for n = 10^5..10^6.

apullin:sbdot-nomalloc

30 minutes ago

utest: keep RVV regression tests compatible with GNU89

SmaCow666:fix/rvv-extrema-valid-seed

43 minutes ago

riscv64: use vlseg2/vsseg2 for the C update in zgemm_kernel_8x4_zvl256b The main 8x4 tile loaded and stored C with two stride-16 passes per segment (real and imaginary parts). Use a 2-field segment load/store instead, as is already done for the A panel, and update and store each C segment before loading the next so the 16 accumulators and the C tuple fit in the register file without spills. The arithmetic is unchanged and results are bit-identical. On a SpacemiT K3, single-thread zgemm gains 14-18% for n >= 512 on the X100 core and about 2.5% on the A100 core.

velonica0:openblas_zgemm_kernel_n

2 hours ago

riscv64: share one x load between two output columns in SGEMV_T (FP32) gemv_t_rvv.c re-reads the whole x vector for every output column. Processing two columns per iteration feeds one x load to two accumulators and removes 25% of the load bytes of the FP32 transposed path. LMUL=8 cannot hold two accumulators plus x plus A in the 32 architectural vector registers (the compiler spills to the stack), so the FP32 path uses LMUL=4; FP64 is untouched and bit-identical. Because vlmax changes, the FP32 reduction order changes and results differ in the last bits. Verified with upstream sblat1/2/3, a 527-case SGEMV driver, VLEN 128/256/512 and an MNIST MLP demo. No hardware performance numbers are claimed: see the PR body.

Nizhenghang:riscv64-sgemv-t-two-column

3 hours ago

RISC-V: fix the strided loop of sum_vector.c (S/DSUM on RISCV64_ZVL256B) The unrolled strided loop never advanced ix and tripled inc_xv on every iteration ("inc_xv += inc_xv * 2"), so for incx > 1 and n >= 2*vl it summed the first block repeatedly plus elements past the end of x. Results were wrong, and for longer vectors the reads left the mapping (SIGSEGV for cblas_ssum(1000, x, 2)). Advance ix by two blocks instead, as zsum_vector.c does.

HiderX:riscv-zvl256b-sum-stride

5 hours ago

RISC-V: faster DAMAX kernel for RISCV64_ZVL256B 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.

HiderX:riscv-zvl256b-damax

7 hours ago

RISC-V: use the RVV NRM2 kernel for RISCV64_ZVL256B nrm2_rvv.c (already used by RISCV64_ZVL128B and x280) is 23%/9%/8% faster for SNRM2 and 10%/6%/6% faster for DNRM2 than nrm2_vector.c on the SpacemiT X100 (n = 1024 / 32768 / 4M), and it propagates NaN inputs, which nrm2_vector.c can drop.

HiderX:riscv-nrm2-rvv-inf

7 hours ago

Merge pull request #6171 from HiderX/riscv-zvl256b-dsdot-rvv RISC-V: use the RVV DSDOT kernel for RISCV64_ZVL256B

develop

9 hours ago

Latest Branches

Compute SBDOT in stack blocks instead of malloc'ing copies of x and y#6249

4 days ago

be327ee

apullin:sbdot-nomalloc

RISC-V: seed extrema reductions from a valid input element#6225

7 days ago

dbeeea4

SmaCow666:fix/rvv-extrema-valid-seed

riscv64: zgemm 8x4 zvl256b: use segment load/store for the C update#6218

9 days ago

c2a56e7

velonica0:openblas_zgemm_kernel_n

Home Terms Privacy Docs