// PHORONIX — LINUX & OPEN SOURCE
RISC-V RVV Vector Performance Benchmarks With The SpacemiT K3 SoC
Since May we have been benchmarking the SpacemiT K3 RISC-V SoC as one of the first to market RISC-V chips supporting the RVA23 profile. The SpacemiT K3 has shown how far RISC-V performance has come in the past half decade and one of the promising elements of this modern RISC-V SoC with its X100/A100 cores is supporting the RISC-V Vector Extension "RVV" 1.0. In this article are some initial benchmarks looking specifically at the RISC-V RVV 1.0 performance impact in different supported software.
Today's benchmarks are focused on quantifying the performance impact of the RISC-V Vector RVV 1.0 performance with the SpacemiT K3 SoC. The benchmarks on the K3 continue to be carried out on the SpacemiT K3 Pico ITX system kindly supplied by SpacemiT for review at Phoronix. This 16 core system with 16GB of RAM was running Bianbu 4.0 with the Linux 6.18 kernel and GCC 15.2 compiler.
Per the kernel.org documentation on the RISC-V Vector support, the /proc/sys/abi/riscv_v_default_allow sysfs interface can be used for runtime toggling of the RISC-V Vector support. That was initially my plan for comparing the RISC-V Vector performance impact on the K3. However, in practice it didn't work out quite so well...
With the many AVX-512 benchmarks over the years at Phoronix it's been quite simple to compare with simply clearing the CPU ID bit working for most software packages. The hope was that /proc/sys/abi/riscv_v_default_allow would allow for a straight-forward RVV comparison too in simply being able to turn off the Vector support.
But when disabling "riscv_v_default_allow", the Bianbu 4.0 system simply became inoperable due to illegal instructions. No binaries were then able to run on the system. Presumably Bianbu is relying on some unconditional RVV instructions in its libc build or other common library that led to the system being unable to do execute anything once riscv_v_default_allow was disabled.
So after a hard reset, comparing the RISC-V Vector performance resorted to manually disabling RVV support in relevant supported packages via either build options in the different programs or adjusting their RVV-enablement patches to compile without the necessary bits.
Here is a look at the RVV 1.0 impact for different software packages with RVV used or not. While it would have also been interesting to quantify the power impact of RVV usage, unfortunately, the K3 SoC doesn't expose any power metrics under Linux at this time. So there is no power metrics exposed via sysfs / HWMON / PowerCap or other interfaces. My WattsUp Pro external power meters were preoccupied in other systems for external AC power monitoring, thus this article is just looking at the performance impact.