RISC-V Vector benchmark results

• riscv-gnu-toolchain

  11 6 0.0 C

  GNU toolchain for RISC-V, including GCC (by brucehoult)

That shouldn't be news.

Other than the CanMV-K230 (Kendryte K230, single 1.6 GHz C908 core implementing RVV) which just started shipping in the last two weeks, every RISC-V board with RVV has either C906 or C910 cores which implement draft 0.7.1.

Those CPU cores were announced in mid 2019 (when RVV 0.7.1 was the current draft) and boards using them start arriving in mid to late 2021.

RVV 1.0 boards will start arriving in force next year, probably starting with the StarFive JH8110 SoC, and (apparently, though I'm not sure I believe it) an update of the SG2042 in the Pioneer, and also the 16 core (but faster cores) SG2380.

> Do you happen to have the name of the gcc branch

The branch has been deleted from the official repo. I have a snapshot on my github:

https://github.com/brucehoult/riscv-gnu-toolchain

Note that it is primarily binutils which understands RVV 0.7.1. GCC understands it only to the extent of accepting "v" in "-march" and passing the right flags to the assembler. This enables using the gcc driver to build .s files and inline RVV asm in C. There is no support for RVV intrinsic functions or auto-vectorisation.

It's also a somewhat old gcc. I use it to build .o files from assembly language, and then link them with C compiled by a newer gcc or llvm. Or not, most of the time gcc 9 is fine.

THead have RVV 0.7.1 support in newer gcc, but I haven't been tracking that closely.

• sail-riscv

  9 390 8.2 Coq

  Sail RISC-V model

  

The official formal specification of the Vector Extension has just been merged into the Golden RISC-V model:

https://github.com/riscv/sail-riscv/commit/c90cf2e6eff5fa4ef...

• InfluxDB

  www.influxdata.com featured

  Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

  

• qemu

  37 - -

> I don't know how rdcycle works on qemu.

That's a good question! I had to look it up myself ...

Obviously qemu TCG isn't a cycle-accurate emulation. Using RDCYCLE / reading the corresponding CSR eventually calls https://gitlab.com/qemu-project/qemu/-/blob/69680740eafa1838... which calls cpu_get_host_ticks is basically an arch-independent wrapper around RDTSC.

So it just measures the time taken to run using RDTSC. Which I guess is what you would want (maybe?). It would measure the time taken to emulate the vector instruction in host instructions.

> This benchmark is more meant for developers to figure out how to vectorize algorithms effectively, as in which instructions to choose.

Absolutely, I'm not saying the qemu results would say anything very deep, but they're kind of interesting from the point of view of either optimizing qemu or if you have to use qemu because the hardware you want isn't available / isn't cheap enough.

Suggest a related project