qemu VS riscv-gnu-toolchain

https://gitlab.com/qemu-project/qemu/-/blob/master/hw/scsi/s...

QEMU's IOThreads allow the user to configure the threads and get something similar to thread per core architecture. But if 1 thread becomes a bottleneck, then some form of thread synchronization is needed again even with thread per core architecture. Some problems can be parallelized and they work well with thread per core.

Add `ENV ERL_FLAGS="+JPperf true"` to your Dockerfile and it will build just fine cross platform. The flag just changes some things during build time and won’t affect runtime performance.

[1] https://gitlab.com/qemu-project/qemu/-/issues/1034

> 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.

I see the commits that started switch support from RVV 071 to 100 start here, https://gitlab.com/qemu-project/qemu/-/commit/9ec6622db30df1c00d863c1ffc33341f9e0a534d

>> https://gitlab.com/qemu-project/qemu/-/issues/1696 ]

> Can I please just get the detail in mail instead of having to go look at random websites?

Maybe it's me but if I did boot boot linux 292.612 times to find a bug, you might as well click a link to a repository of a major open source project on a major git hosting service.

Is it really that weird to ask people online to check a website? Maybe I don't know the etiquette of these mail lists so this is a geniune question.

Capstone is used[1] by QEMU as disassembly engine in debug logs and in monitor mode debugger, by the way, so it's in the scope of the RISE effort.

[1] https://gitlab.com/qemu-project/qemu/-/blob/master/disas/cap...

A user on the qemu bugtracker found a way to get the Intel Arc working across resets without crashing the host: Just don't passthrough the audio device of the GPU and everything works!

[1]https://gitlab.com/qemu-project/qemu/-/commit/3412d8ec9810b819f8b79e8e0c6b87217c876e32 [2]https://gitlab.com/alex.williamson/qemu/-/commit/9a6d1822a2bd55f5dee1aec1b6529ae57949d5ba.patch

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.

The TH1520 has much faster memcpy speeds at every level of cache and DRAM.

https://hoult.org/JH7110_memcpy.txt

https://hoult.org/JH7110_memcpy.txt

And yet ... both Richard Jones at Fedora and I have found that the VisionFive 2 is actually slightly faster at building software packages!

My result was that building the same binutils + gcc + newlib snapshot (an old one with RVV 0.7.1 support)...

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

... the VisionFive 2 takes 108 minutes while the Lichee Pi 4A takes 122 minutes.

That's with the supplied fan on the LPi4A (and confirmed it's not throttling) and no cooling at all on the VisionFive 2. I used the same Samsung external USB3 SSD on both -- the VisionFive 2 gets slightly faster transfer speeds (IIRC 190 MB/s vs 160) with that, but that's not enough to matter: just 12s difference on the time to tar up the source directory, compared to a 14 minute build time difference. Both have enough RAM to cache everything anyway.

> VF2 GPU: IMG BXE-4-32 Lichee Pi: ?? Anyone?

BXM-4-64

I've also found the 1.5 GHz in-order VF2 does remarkably well vs the 1.85 GHz OoO LPi4A on software build tasks, though not as extreme as Richard shows.

I'm lazy and using the original Image-55 on my 8 GB VF2, and the Debian that came preloaded in the eMMC on the LPi4A. My mass-production LPi4A arrived yesterday, I haven't tried it yet, tests are on the beta board that arrived a couple of months ago.

On pure CPU core + L1 cache tests (e.g. https://hoult.org/primes.txt) the LPi4A is considerably faster.

The LPi4A is also much faster on memcpy tests.

https://hoult.org/TH1520_memcpy.txt

https://hoult.org/JH7110_memcpy.txt

My build test is an RVV 0.7.1-enabled snapshot of the gnu toolchain (gcc 9.2) that I use on the TH1520 and SG2042. Newlib, non-multilib (just rv64gcv) build. I used the same Samsung 2 TB external USB3 SSD drive for src/build trees on both boards. https://github.com/brucehoult/riscv-gnu-toolchain

VF2:

real 107m52.116s

To build rvv programs I use brucehoults rvv 0.7.1 toolchain and some assembly macros, so I can write a subset of rvv 1.0 that I can run on rvv 0.7.1: https://github.com/brucehoult/riscv-gnu-toolchain https://github.com/camel-cdr/rvv-d1/blob/main/rvv-rollback.S

I'm using a rvv 0.7.1 toolchain, which doesn't support the rvv 1.0 mnemonics.

Step 1. Build the RISC-V GNU toolchain suitable for compiling and assembling RVV 0.7.1 instructions, and that would be https://github.com/brucehoult/riscv-gnu-toolchain. For grins I built this on a RISC-V machine, the Unmatched. It took a few hours, but there's something sublime about using RISC-V everywhere you can.