4 ms·

I wonder if qemu-system-riscv64 results are interesting? On the one hand they mostly tell you about the x86 hardware you're running it on and the quality of TC

by rwmj 3y ago

I wonder if qemu-system-riscv64 results are interesting? On the one hand they mostly tell you about the x86 hardware you're running it on and the quality of TCG. On the other hand we're quite interested in how qemu performs compared to actual hardware because we (Fedora) may wish to use qemu until hardware capabilities catch up. I have qemu on AMD 7950X and Genoa if interested.

camel-cdr 3y ago
I don't know how rdcycle works on qemu. This benchmark is more meant for developers to figure out how to vectorize algorithms effectively, as in which instructions to choose.
- rwmj 3y ago
  > 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{,H} / reading the corresponding CSRs eventually calls https://gitlab.com/qemu-project/qemu/-/blob/69680740eafa1838527c90155a7432d51b8ff203/target/riscv/csr.c#L759 https://gitlab.com/qemu-project/qemu/-/blob/69680740eafa1838... which calls cpu_get_host_ticks which is basically an arch-independent wrapper around RDTSC, assuming you are running qemu on x86 host. I think icount_enabled is false in normal qemu builds. Therefore it would measure the time taken by qemu to emulate the vector instruction, in host instructions. Which I guess is what you would want (maybe?). > 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.
dzaima 3y ago
QEMU's RVV is all ahead-of-time-compiled scalar loops when I looked at it a couple months ago, so the results would be very bad (worse than scalar equivalents). Even x86-64 SSE2 on x86-64 is scalar ahead-of-time-compiled helpers.
- rwmj 3y ago
  Yes, it's all just implemented using qemu helpers. I expect performance will be terrible.

by rwmj 3y ago

camel-cdr 3y ago

I don't know how rdcycle works on qemu. This benchmark is more meant for developers to figure out how to vectorize algorithms effectively, as in which instructions to choose.

rwmj 3y ago
> 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{,H} / reading the corresponding CSRs eventually calls https://gitlab.com/qemu-project/qemu/-/blob/69680740eafa1838527c90155a7432d51b8ff203/target/riscv/csr.c#L759 https://gitlab.com/qemu-project/qemu/-/blob/69680740eafa1838... which calls cpu_get_host_ticks which is basically an arch-independent wrapper around RDTSC, assuming you are running qemu on x86 host. I think icount_enabled is false in normal qemu builds. Therefore it would measure the time taken by qemu to emulate the vector instruction, in host instructions. Which I guess is what you would want (maybe?). > 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.

dzaima 3y ago

QEMU's RVV is all ahead-of-time-compiled scalar loops when I looked at it a couple months ago, so the results would be very bad (worse than scalar equivalents). Even x86-64 SSE2 on x86-64 is scalar ahead-of-time-compiled helpers.

rwmj 3y ago
Yes, it's all just implemented using qemu helpers. I expect performance will be terrible.