RVV benchmark XuanTie C906 (MangoPi MQ Pro, Allwinner D1)

The MangoPi MQ Pro has a single Allwinner D1 XuanTie C906 core, which has been open-sourced. It has a frequency 1GHz and implements rv64gc and the XTheadVector extension, based on the 0.7.1 version of the vector extension, supporting SEW=8/16/32, single and half precision floating point instructions with a VLEN of 128.

• Return to parent page

Benchmarks

Based on this commit.

• memcpy
• memset
• strlen
• utf8 count
• merge escaped lines
• mandelbrot
• ascii to utf16 (zero extend 1->2 bytes)
• ascii to utf32 (zero extend 1->4 bytes)
• chacha20
• poly1305

Performance observations

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

• Maximizing LMUL is a good strategy in general, but isn't always the fastest, see mergelines.html. This is likely due to vcompress.vm not scaling proportionally to LMUL (4, 10, 36, 136 cycles).
• 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.
• Using the mask operand doesn't impact performance.
• Most instructions take 4 for LMUL=1/2, 8 for LMUL=4 and 16 for LMUL=8 cycles 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)
• Manual tail handling and unrolling can increase the performance for certain sizes (~20% in utf8 count), when the operation isn't memory bound.
• Aligning the destination pointer in a streaming workload, like memcpy can make the runtime slightly faster/more stable.
• Uni-stride segmented stores are almost as fast, as regular uni-stride store at proportional LMUL. (see ascii to utf16/utf32)
• Strided stores are a lot slower than regular stores, especially when the memory isn't in cache. (see ascii to utf16/utf32)

Problems and unexpected things

• There seems to be a problem with some kernel builds, reducing the clocks speed considerably.
• Even though the C906 chip is supposed to support RVV 0.7.1, it dosn't implement the vdot/vfdot instructions.
• vmsgt.vx v8, v8, a3 gives an illegal instruction, even though it is supposed to work. This probably also includes other instructions, but vmsgt.vx with different source and result operands seems to work.
• sstatus.vs is masked by 0x01800000 instead of 0x600, as specified for RVV 1.0. (RVV 0.7.1 didn't specify a position)

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. The real latency is likely close to 2/4/8/16, instead of 4/4/8/16.