RVV benchmark CanMV-K230 (Kendryte K230, C908)

The CanMV-K230 is based on the Kendryte K230 and has two XuanTie C908 cores. One core runs at 0.8 GHz and doesn't support rvv, the other one at 1.6GHz and supports the 1.0 version of the standard V extension, including Zvfh support, with a VLEN of 128.

• Return to parent page

Based on this commit.

Thanks to Michael Crusoe (mr-c) for contributing the clang-18 results.

Benchmarks

• memcpy
• memset
• strlen
• utf8 count
• merge escaped lines
• mandelbrot
• reverse byte order of 32 bit elements
• 4-bit lookup table
• 6-bit lookup table
• ascii to utf16 (zero extend 1->2 bytes)
• ascii to utf32 (zero extend 1->4 bytes)
• chacha20
• poly1305

Performance observations

Note that all of these only apply to this processor and aren't set in stone.

• Maximizing LMUL is a good strategy for computation and load/stores, but not for permutation instructions
• The vl doesn't impact performance, so a vl=1 and a vl=VLMAX instruction with LMUL=8 will take the same amount of time to execute.
• The fault-only-first load instructions are slightly slower than the regular load instructions, it's probably worth page aligning the loads by hand when best performance is needed. (see strlen)
• When a gather operation doesn't need to cross register boundaries, multiple LMUL=1 or LMUL=2 gathers are faster. (see byteswap)
• SWAR implementations could always be beat by RVV implementations. (see memcpy(musl), memset(musl), byteswap, utf8_count)
• Manual tail handling doesn't seem to be worth it in these benchmarks.
• Manual unrolling could improve performance for very small loops (see utf8_count).
• Aligning the destination or source pointer in a streaming workload, didn't change performance, except for a slight speedup in memset.
• Uni-stride segmented stores are almost as fast as uni-stride stores. (see ascii to utf16/utf32)
• Strided stores, are way slower than uni-stride stores. (see ascii to utf16/utf32)
• Using the mask operand seems to slow down arithmetic operations with LMUL smaller than 8 in the measurement. But this is likely because of the added dependency to the previous instruction, and won't be as visible in practice.

Microarchitecture speculations

The following was derived from manual timing of unrolled instruction sequences:

While the processor has a 128-bit wide vector length, it seems to actually have two execution units each only 64-bit wide. So LMUL=1 operations would need to be split into two uops.

The instructions that scale with LMUL in a 1/2/4/8 (e.g. vadd) and the ones that scale in a 2/4/8/16 (e.g. vsll) pattern in the "Instruction timings" table at the bottom are likely supported by both, and only one of the execution units respectively:

Two 64-bit wide execution units: EX1, EX2:
• only EX1: vsll, vand, vmv, viota, vmerge, vid, vslide, vrgather, vmand, vfcvt, ...
• on EX1&EX2: vadd, vmul, vmseq, vfadd, vfmul, vdiv, ..., LMUL=1/2: vrgather.vv, vcompress.vm

This fits our measurement results, where T is the relative average time per instruction in the sequence:

LMUL=1:   vadd,vadd,... = 1T
LMUL=1:   vadd.vsll,... = 1T
LMUL=1:   vsll,vsll,... = 2T
LMUL=1/2: vsll,vsll,... = 1T

With vector chaining, the execution of those sequences would look as follows:

LMUL=1:   vadd,vadd,vadd,vadd: | LMUL=1:   vsll,vsll,vsll,vsll:
    EX1: a1 a2 a3 a4           |     EX1:  s1 s1 s2 s2 s3 s3 s4 s4
    EX2: a1 a2 a3 a4           |     EX2:
-------------------------------|-------------------------------
LMUL=1:   vsll,vadd,vsll,vadd: | LMUL=1/2: vsll,vsll,vsll,vsll:
    EX1: s1 s1 s2 s2           |     EX1:  s1 s2 s3 s4
    EX2:    a1 a1 a2 a2        |     EX2:

A consequence of this design is that vadd.vi a, b, 0 can be faster than vmv.v.v a, b. This is very unexpected behavior, and instructions like vand are the simplest to implement in hardware, certainly simpler than a vmul, but somehow vand is only on one, but vmul on two execution units?

Instruction timings

The following are measured cycle averages when unrolling and looping over the given instruction, which should estimate the instruction throughput. The registers involved are randomized to usual values, that is floating point values are real numbers and not NaN/Inf, and instructions like vslide* stay within the vl range.

bench_vaddvx_m1:
m_nop
	li a0, WARMUP
1:
	vadd.vx v8,v16,t0
	vadd.vx v9,v17,t1
	vadd.vx v10,v18,t2
	vadd.vx v11,v19,t3
	vadd.vx v12,v20,t4
	vadd.vx v13,v21,t5
	vadd.vx v14,v22,t6
	vadd.vx v15,v23,t7
	addi a0, a0, -1
	bnez a0, 1b
	li a0, LOOP
	rdcycle a1
1:
.rept UNROLL
	vadd.vx v8,v16,t0
	vadd.vx v9,v17,t1
	vadd.vx v10,v18,t2
	vadd.vx v11,v19,t3
	vadd.vx v12,v20,t4
	vadd.vx v13,v21,t5
	vadd.vx v14,v22,t6
	vadd.vx v15,v23,t7
.endr
	addi a0, a0, -1
	bnez a0, 1b
	fence.i
	rdcycle a0
	sub a0, a0, a1
	ret

bench_vaddvx_m4:
	m_nop
	li a0, WARMUP
1:
	vadd.vx v8,v16,t0
	vadd.vx v12,v20,t4
	vadd.vx v8,v16,t0
	vadd.vx v12,v20,t4
	vadd.vx v8,v16,t0
	vadd.vx v12,v20,t4
	vadd.vx v8,v16,t0
	vadd.vx v12,v20,t4
	addi a0, a0, -1
	bnez a0, 1b
	li a0, LOOP
	rdcycle a1
1:
.rept UNROLL
	vadd.vx v8,v16,t0
	vadd.vx v12,v20,t4
	vadd.vx v8,v16,t0
	vadd.vx v12,v20,t4
	vadd.vx v8,v16,t0
	vadd.vx v12,v20,t4
	vadd.vx v8,v16,t0
	vadd.vx v12,v20,t4
.endr
	addi a0, a0, -1
	bnez a0, 1b
	fence.i
	rdcycle a0
	sub a0, a0, a1
	ret