RVV benchmark Sipeed Lichee Pi 4A (TH1520, C910)

The Sipeed Lichee Pi 4A has a quad core TH1520 with XuanTie C910 cores. It has a frequency 1.848GHz and implements rv64gc and the 0.7.1 version of the vector extension supporting SEW=8/16/32/64, single, half and double precision floating point instructions, with a VLEN of 128 bits.
Note: The core (C910 + XTheadVector) was originally marketed as C920, but XuanTie retroactively changed their marketing to refer to the XTheadVector cores as C910. The official C920 will be a modified C910 with RVV 1.0 that is yet to release.

• Return to parent page

Based on this commit.

Thanks Bruce Hoult for contributing this.

Benchmarks

• memcpy
• memset
• strlen
• utf8 count
• merge escaped lines
• mandelbrot

Performance observations

Note that all of these only apply to this processor and aren't set in stone.

• Maximizing LMUL is a good strategy for computation, it looks like LMUL=4 is better when memory bottlenecked. (I'd recommend aiming for LMUL=4 as a default)
• The vl doesn't impact performance, so a vl=1 and a vl=VLMAX instruction with LMUL=8 will take the same amount of time to execute.
• The fault-only-first load instructions are quite slow compared to the regular load instructions, so one should try to page align the loads by hand when possible. (see strlen)
• When not reading and doing much computation, SWAR implementations can be faster than RVV for large input sizes. (see memcpy)
• Manual tail handling and unrolling doesn't seem to be worth it in these benchmarks.
• Aligning the destination pointer in a streaming workload, like memcpy can make the runtime slightly faster for medium large sizes, but slows it down for smaller sizes.
• Using the mask operand seems to slow down arithmetic operations with LMUL smaller than 8 in the measurement. But this is likely because of the added dependency to the previous instruction, and won't be as visible in practice.

Instruction timings

The following are 20/80 percentile cycle averages when unrolling and looping over the given instruction, it doesn't include vsetvl and load/store instructions. The registers involved are randomized to usual values, that is floating point values are real numbers and not NaN/Inf, and instructions like vslide* stay within the vl range.

This doesn't necessarily measure either latency or throughput, it just uses the methodology described above with the instructions in the table below.

Note: The way it's currently measured has a dependency on the destination, the newer benchmark code gets rid of that, but hasn't been run on this processor yet.