RVV Benchmark Results

Lisp scalar is flat at ~396 Melem/s from n=251 (L1-resident) to n=1M (DRAM), whereas C scalar drops from ~960 to ~691. A memory-bound loop tracks the cache like C does; a flat line means the Lisp loop is instruction/latency-bound.

SBCL recomputes each array element’s byte address from the tagged fixnum index on every element (slli to untag/scale, then add to the base pointer), three times per element for the three arrays. RISC-V has no scaled/indexed addressing mode, so this cannot be folded into the load the way x86-64 (movss [base+idx*4+disp]) and arm64 (add with folded lsl) can. gcc strength-reduces the loop to three pointer-induction variables; SBCL does not.

SBCL does not auto-unroll scalar loops. Manual unrolling closes most of the gap:

The benchmark’s of-type index (SBCL’s index is (integer 0 array-dimension-limit), which this build reports as not a subtype of fixnum) also makes the loop-index arithmetic go through generic TWO-ARG-+/TWO-ARG→= calls. Switching the loop variable to fixnum produces a much tighter loop but does not move the measured number on this benchmark (the loop is already latency-bound), so it is a codegen smell rather than the bottleneck.

Zba removes one slli per aref: the scalar f32 add loop goes from a flat ~396 Melem/s to ~486–496 Melem/s (~1.23–1.28x), and the inner loop now disassembles to three sh1add and no slli.

This narrows but does not close the gap to C (~994 Melem/s at n=4093): the remaining ~2x is loop unrolling and pointer-induction strength reduction, compiler issues independent of Zba (see slow-scalar.adoc).

The scalar-vs-RVV tables in this file have all been re-measured on the Zba build, so their scalar columns already reflect the Zba speedup; the speedup ratios are correspondingly lower than on a non-Zba build (faster scalar, unchanged RVV throughput).

LMUL=2/4 gives a large, real speedup in cache: at n=4093 the chunk path goes from 2.3x (m1) to 4.5x (m2) to 7.9x (m4), and the block path reaches 8.4x (m4). This is exactly the instruction-count reduction predicted: one LMUL=4 vector instruction covers VLEN*4/32 = 32 elements.

At n=1048576 the memory system is the limit: m1/m2/m4/m8 all converge to ~1.5–1.6x and ~0.72–0.79 Gelem/s.

LMUL=8 is neutral to slightly worse than M4 at VLEN=256 (6.2x vs 7.9x at n=4093): with VLMAX=8 an M8 group already covers 64 elements per instruction, but the two 8-register groups (16 registers total) add register pressure without extra memory parallelism. See the VLEN=1024 tables below, where M8 covers 256 elements and is expected to help more.

blk8 (8-way unroll) is not a win over blk m4 at VLEN=256: at n=4093 blk8 is 6.2x vs blk m4’s ~8.0x, and at n=65536 4.5x vs 4.9x. With VLMAX=8 a 4-way unroll already keeps 32 elements in flight, so 8-way adds register pressure without more memory parallelism.

chunk m4 at n=4093 reaches ~3.9 Gelem/s, in the same neighborhood as the C auto-vectorizer (3.4 Gelem/s at n=4093).

u32 max (vredmaxu.vs) is a clear win: ~3.6–6.3x over the scalar loop, because the integer max has a loop-carried branch that the scalar path cannot hide, while the vector reduction is parallel.

f32/f64 sum (vfredosum.vs) does not beat a tight scalar loop (~1.0x and ~0.9x). vfredosum is the ordered sum variant; it preserves element order (required to match Lisp reduce #'+) and therefore does not gain the tree-reduction parallelism of the unordered vfredusum. This is a documented, honest result rather than a bug.

u32 max masked (vmsgtu.vv → vmerge.vvm) is ~2.1–4.1x over scalar max, comparable to (slightly below) the single-instruction vmaxu.vv chunk, as expected for a two-instruction sequence.

u32 cmp-count (vmsgtu.vv → vcpop.m) is ~1.8–2.7x over a scalar count loop.

FMA/MACC fuses two operations into one instruction: ~2.4–2.9x for f32, ~2.4–3.8x for u32 in cache, collapsing to ~1.3–1.7x at n=1M where the arrays stop fitting in cache.

The overwrite-multiplicand form (vfmadd.vv, %RVV-F32-FMADD-CHUNK) performs within noise of the accumulate form (vfmacc.vv): ~2.8x at n=4093 and n=65536, ~2.2x at n=251, and ~1.3x at n=1M — the same instruction shape, so no extra cost.

f32→u32 is the standout: ~4.5–6.8x over scalar, because Lisp float to integer conversion (truncate) is expensive, while vfcvt.xu.f.v is a single instruction.

u32→f32 is ~1.7–2.3x over scalar coerce.

Integer widening (u8/u16 → u32) is ~4.3–6.7x: the RVV path fuses load-extend-store, so it makes one memory pass where the scalar path zero-extends each narrow element into a 32-bit lane.

u32→u16 narrowing is ~3.9–6.0x: vnsrl.wi 0 truncates and halves the lane count in one instruction, while scalar must mask each element to 16 bits.

f32→f64 widening is ~2.0–2.3x and stays cache-resident through n=1M. f64→f32 narrowing drops to ~1.3x at n=1M: the 8-byte source element makes both paths DRAM-bound (the same effect seen in the f64 add and gather rows), so the instruction-count win no longer shows.

Widening arithmetic turns two e32 lanes into one e64 result in a single instruction (vwadd.vv/vwaddu.vv, vwmul.vv/vwmulu.vv), so the RVV path is ~2.1–3.0x faster than the scalar loop in cache (add ~2.6–3.0x, mul ~2.1–2.6x) and ~1.4–1.8x at n=1M, where the 8-byte destination makes both paths DRAM-bound.

The scalar widening-multiply baseline (~495 Melem/s) is higher than widening-add (~396) because the scalar 32x32→64 multiply is more work, but the RVV numbers are the same ~930–1280 Melem/s for both, so the multiply’s speedup is slightly lower.

vfwmacc.vv/vwmaccu.vv fuse a widening multiply with a 64-bit accumulate: ~2.0–2.6x in cache, collapsing to ~1.1x at n=1M where the 8-byte destination and 64-bit accumulator make the loop DRAM-bound (the same effect seen in the f64 rows).

Strided and indexed gather are ~1.0–1.2x over scalar at cache sizes. They are memory-bound (random-ish access) and the scalar baseline is a simple (aref src (* i k)) / (aref src (aref idx i)) loop, so there is little compute to hide; the real value is enabling vector code for non-contiguous access at all.

AoS→SoA deinterleave is not a throughput win in the way the arithmetic VOPs are: both the scalar loop and the segment load walk both arrays sequentially, so there is no cache-behaviour gap to exploit, only the per-segment instruction-count saving.

The speedup grows with nf (more fields amortise the fixed vsetvli/vlseg/store-stream cost) and with n (the per-call VOP overhead amortises), reaching ~1.4x at nf=8, n=65536.

nf=2 at small n is a loss (~0.5x): the segment-load round-trip costs more than the scalar two-load/store loop it replaces. This is the expected, measurement-driven outcome for a memory-side op; its value is correctness + expressiveness (a single instruction deinterleaves AoS into SoA), recorded honestly rather than marketed as a speedup.

LMUL=2/4 is an even bigger win than at VLEN=256: chunk m4 reaches ~13.0x at n=65536 and stays at ~10.1x at n=1048576 (the AI cores have enough bandwidth that the 1M case is not DRAM-bound the way it is on the default cores). With VLMAX=32, an LMUL=4 group covers 128 elements per instruction.

LMUL=8 is not a further win here either: it is ~6.6–9.2x, below M4’s ~10–13x. The load/compute/store chunk is memory-bound, so M4 already saturates bandwidth and the wider 8-register groups only add register pressure (16 registers for one binary op) without extra throughput. LMUL=8 is retained for completeness (spec 02) but is not faster.

blk8 is a loss at VLEN=1024 (~3.9–5.5x vs blk m4’s ~13x): with VLMAX=32, a single M1 vector already covers 32 elements, so 8-way unroll only adds per-iteration overhead and register pressure without more memory parallelism. This is the same "unroll saturates" effect seen with `blk4 at VLEN=256, just more pronounced.

f32/f64 sum (vfredosum) now shows a modest ~1.4–1.7x (vs ~1x at VLEN=256) because the scalar baseline on the AI cores is slower; u32 max stays a strong ~3.5–7.6x.

f32→u32 is the largest single speedup measured anywhere in this suite: ~20–38x at VLEN=1024, because the scalar truncate path runs at only ~47 Melem/s on these cores while vfcvt.xu.f.v is one instruction.