RISC-V Vector extension on the Allwinner D1

[brucehoult]

I've managed to (figuratively) get my hands on a board with the new Allwinner D1 RISC-V SoC using the Alibaba/T-Head C906 core. As in, the machine is in Beijing and I'm sshing in.

This SoC will soon be available on SBCs in the Pi Zero category from Sipeed (promised price $12.50) and Pine64 (promised price "under $10") as well I think from Allwinner themselves. And probably others.

For that price you might only get 256 MB or 512 MB of RAM. The board I'm using has 512 MB and is running at 1.008 GHz.

The most exciting part about this SoC is that it turns out Allwinner have paid for the optional RISC-V Vector extension hardware. It turns out that Sipeed engineers weren't even sure until I sent them some test programs to run. The unfortunate part is the Vector ISA implemented is the 20 month old draft 0.7.1. While this is very similar in spirit to what will shortly be the ratified 1.0 version and it's usually fairly easy to convert assembly language code from one to the other, it is incompatible at both the assembly-language and binary level.

But it's probably the only RISC-V Vector hardware most people will be able to get their hands on in the next 12 months. And it's much nicer than MX / SSE / AVX. And no one has ARM chips with SVE yet.

Thanks to Sipeed.com and RVBoards.org for generously providing access.

I've run a test program comparing the speed of memcpy() on copies of various sizes, and another program comparing strcpy(). The results are at:

http://hoult.org/d1_memcpy.txt
http://hoult.org/d1_strcpy.txt

The source code is at:

http://hoult.org/test_memcpy.c
http://hoult.org/test_strcpy.c
http://hoult.org/rvv_lib.s

[hamster_nz]

That strcpy() performance is pretty interesting - about 2x as fast, even for (stupidly?) long strings.

But then reading that note that the standard code calls strlen() then memcpy() that makes sense...

[brucehoult]

I would expect most fast non-SIMD implementations using scalar instruction sets do. Its hard enough to make optimised block copies without trying to find and check for zero bytes in the middle of them -- and you don't want to overwrite even one byte past the place you're copying the null to.

Using strcpy to copy 32 MB is not the common case :-)