RVV benchmark XuanTie C920v1 (Milk-v Pioneer, SG2042)

The Milk-V Pioneer is based on SOPHON SG2042 with 64 XuanTie C920v1 cores. It has a frequency 2GHz and implements rv64gc and the XTheadVector extension, based on 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 (C920v1 + XTheadVector) was originally marketed as C920, but XuanTie retroactively changed their marketing to refer to the XTheadVector cores as C920v1. The official C920 will be a modified C920v1 with RVV 1.0 that is yet to release.

• Return to parent page

Based on this commit.

Thanks to perfxlab and Cloud-V for granting me access to a Milk-V Pioneer server.

Benchmarks

• memcpy
• memset
• strlen
• utf8 count
• merge escaped lines
• mandelbrot
• reverse byte order of 32 bit elements
• 4-bit lookup table
• 6-bit lookup table
• histogram
• ascii to utf16 (zero extend 1->2 bytes)
• ascii to utf32 (zero extend 1->4 bytes)
• chacha20
• poly1305
• base64 encode

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 a gather operation doesn't need to cross register bounderies, multiple LMUL=1 or LMUL=2 gathers are faster. (see byteswap)
• The results from LUT4 are confusing, my best bet is that the added vsetvli cause the slowdown, otherwise rvv_vrgather_m1 shouldn't be faster than rvv_m1_vrgather_m2.
• 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.
• Uni-stride segmented stores and strided stores, are way slower than uni-stride stores. (see ascii to utf16/utf32)
• 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 Some valid vtype-instruction combinations are missing.

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.