[camel-cdr]

Yes.

I'm using the old gnu toolchain branch from brucehoult and write the benchmarks such that they work in rvv 1.0 and rvv 0.7.1. To help with that I've got a gnu assembler macro file that does 1 to 1 instruction translation when possible and for the other cases I need to #if/#else/#endif.

I'm working on rvv unicode conversions, and plan to release a blog post/article with benchmarks and explanation soon. The problem is that I've uses c intrinsics to write it, so I need to manually translate the assembly code to rvv 0.7.1 compatible code.

That entails

    vsetivli -> vsetvli
    vle64 -> vle32
    vmvNr -> vmv.v.v & 2 vsetvli
    vzext.vN -> N/2 vwaddu & N/2+1 vsetvli

in my case.

Also, the board I've got access to (it might be an eval board, idk) has a bug in vredmax, so I also needed to adjust the code to not use that. (I've yet to investigate that further)

[kragen]

thanks, this information is fantastic

i really hope to have a chance to read your blog post! i haven't tried rvv programming at all

[camel-cdr]

It's up now: https://camel-cdr.github.io/rvv-bench-results/articles/vecto...

[adgjlsfhk1]

this is a great resource! any chance you can add a matmul benchmark to this?

[camel-cdr]

I was thinking about that, but matmul is so too hardware specific (cache sizes, and the like), and I'm not confident I can get an implementation that can get close to max performance.

[adgjlsfhk1]

getting big matmul good is hard, but up to about 100x100 you don't need to worry about cache sizes, it's all about the microkernel