[kragen]

this is fantastic! they're the first sophon benchmark results i've seen, and they're far more comprehensive than most benchmark results of any kind

have you run into any toolchain difficulties due to the 0.7.1 nature of the rvv?

[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