RVV benchmark CanMV-K230 (Kedryte 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
• 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.
• 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.

Instruction timings

The following are 20/80 percentile cycle averages when unrolling and looping over the given instruction, it doesn't include vsetvl and load/store instructions. 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.

This doesn't necessarily measure either latency or throughput, it just uses the methodology described above with the instructions in the table below.