...

The cam4 benchmark in spec2017 is reasonably friendly for vectorization, performance gains relative to a single FPU scalar implementation should be on the order of 17%.   Verify the benchmark vectorizes and sees a comparable performance improvement on RISC-V On the BPI-F3, vectorization is dropping the instruction counts by 25.76%, but the cycle counts (as measured by perf) are up just over 7%.  There is little data on the uarch in that k1 processor, but based on my (Jeff)'s observations it's a pretty weak vector architecture, roughly on par with the c908 in the k230 board (which didn't have enough memory to reliably run most of the FP benchmarks).

While these numbers are disappointing from a cycle count standpoint, that is more likely an artifact of the design of the k1 processor rather than a weakness in the vector code generation in the compiler.  I (Jeff) strongly suspect that if we had thorough documentation on the k1 uarch and exposed the various aspects to the vectorizer's cost model that we would find that most vectorization opportunities would considered unprofitable and dropped.

Stakeholders/Partners

RISE:

...

Updates

28 May 2024 

• Added note on performance on the k1 design (BPI-F3 board).

14 Mar 2024 

• We are currently seeing an 18% reduction in dynamic instruction counts for GCC using vector operations which is roughly in line with expectations.
  • x86 gets an approximate performance improvement of 12% from vectorization
  • aarch64 gets an approximate performance improvement of 6% vectorization
  • The 18% reduction for risc-v doesn't necessarily mean a 18% performance improvement, but in general we should be seeing instruction count improvements at or larger than the performance improvements seen on the competitive architectures
  • Conclusion: We're in the ballpark.  Next steps are to confirm on real vector hardware, keeping in mind that uarch issues may come into play

...