4 ms·

>If you are a hobbyist like me, who just wants to keep up to date with how technology is evolving and what things like vector processing is, then safe yourself

>If you are a hobbyist like me, who just wants to keep up to date with how technology is evolving and what things like vector processing is, then safe yourself a lot of trouble and just read a RISC-V book. Yes, I'd absolutely agree. If you're a professional you'll probably find the hundreds of ARM instructions useful for optimizing your kernels if you're hand-crafting assembly but you'll be pretty far up the learning curve before you get to the crossover point. And not just for hobbyists but also for most academics working on exploring vectorization as well. But if it's me just making use of the effort someone else has put into BLAS for my robot then I'll probably be better off with an SVE processor both from a code optimization scope standpoint and an ease of hardware implementation standpoint.

brucehoult 5y ago
Compared to NEON, SSE, AVX etc, yes. Compared to RVV? I don't think that follows. Also there won't be any generally available (for example in a Raspberry Pi or other SBC) implementations of SVE for probably several years yet, while Allwinner has their D1 chip using RVV [1] already in mass production and I've been running test code on it e.g. http://hoult.org/d1_memcpy.txt http://hoult.org/d1_memcpy.txt http://hoult.org/d1_strcpy.txt http://hoult.org/d1_strcpy.txt Sipeed and Pine64 have announced plans to sell Linux SBCs with this chip for as little as $10 or $12 within the next few months. [1] it's a two year old version 0.7.1 of RVV, not very compatible with the current draft (though that memcpy() works on both), but newer than what is shown in the article.
- Symmetry 5y ago
  If we're talking about non-final versions of RVV then I think there likely won't be any optimized versions of matrix libraries coming out for those chips and both RVV and SVE are going to be effectively moot for a few years for people not writing their own assembly. It's nice that you can get a RV board so cheaply as a hobbyist but as someone who uses vector libraries professionally I don't care and don't expect to ever use a chip costing less than $100. Right now getting high end chips in industrial PCs means going with x86. You can get an ARM chip with nice performance in an Apple laptop but that's not a form factor that's useful to me. ARM's own designs are a few years behind Apple but keeping pace so I think that it won't be too many years before I could plausibly be using ARM chips. I don't have any confidence I'll be able to get a RV chip that performs as well as a contemporary Intel or AMD chip in that timeframe.
  - brucehoult 5y ago
    I expect glibc, musl, newlib to have at least some RVV optimised functions (memcpy, memmove, memset, bzero, strlen, strcpy, strncpy, memcmp, strcmp etc) very soon. Certainly for RVV 1.0, but I think also for RVV 0.7.1 since a lot of boards are going to be sold with that. Simply having RVV versions of these in the standard library will instantly get most of the performance improvement available for general purpose code. I will be personally pushing for that as 1) I'll have RVV 0.7.1 hardware probably this month, 2) I know both RVV 0.7.1 and 1.0 well and can write these routines in my sleep, and 3) I have FSF copyright assignments in place for gcc, binutils, glibc. If you are only interested in computing devices with contemporary x86 or M1 performance then, sure, it's going to be quite some years before you have to care about either SVE or RVV. Apple might well implement SVE sometime soon -- obviously no one knows. I'm typing this on a 16 GB M1 Mac Mini. It's replaced my 32 core ThreadRipper running Linux for day to day use as it's silent and has snappier UI, and is faster for anything using up to four cores, and not all that much slower even for things that sometimes use 32 cores. See for example the last test in http://hoult.org/arm64_mini.html http://hoult.org/arm64_mini.html where it's 71% as fast as the ThreadRipper building the entire RISC-V GNU toolchain in a Linux for arm64 VM. Actually that was on a Mini with 8 GB RAM where I couldn't afford to allocate more than 4 GB to the VM. It's faster than that on my current 16 GB Mini.

brucehoult 5y ago

Compared to NEON, SSE, AVX etc, yes. Compared to RVV? I don't think that follows. Also there won't be any generally available (for example in a Raspberry Pi or other SBC) implementations of SVE for probably several years yet, while Allwinner has their D1 chip using RVV [1] already in mass production and I've been running test code on it e.g. http://hoult.org/d1_memcpy.txt http://hoult.org/d1_memcpy.txt http://hoult.org/d1_strcpy.txt http://hoult.org/d1_strcpy.txt Sipeed and Pine64 have announced plans to sell Linux SBCs with this chip for as little as $10 or $12 within the next few months. [1] it's a two year old version 0.7.1 of RVV, not very compatible with the current draft (though that memcpy() works on both), but newer than what is shown in the article.

Symmetry 5y ago
If we're talking about non-final versions of RVV then I think there likely won't be any optimized versions of matrix libraries coming out for those chips and both RVV and SVE are going to be effectively moot for a few years for people not writing their own assembly. It's nice that you can get a RV board so cheaply as a hobbyist but as someone who uses vector libraries professionally I don't care and don't expect to ever use a chip costing less than $100. Right now getting high end chips in industrial PCs means going with x86. You can get an ARM chip with nice performance in an Apple laptop but that's not a form factor that's useful to me. ARM's own designs are a few years behind Apple but keeping pace so I think that it won't be too many years before I could plausibly be using ARM chips. I don't have any confidence I'll be able to get a RV chip that performs as well as a contemporary Intel or AMD chip in that timeframe.
- brucehoult 5y ago
  I expect glibc, musl, newlib to have at least some RVV optimised functions (memcpy, memmove, memset, bzero, strlen, strcpy, strncpy, memcmp, strcmp etc) very soon. Certainly for RVV 1.0, but I think also for RVV 0.7.1 since a lot of boards are going to be sold with that. Simply having RVV versions of these in the standard library will instantly get most of the performance improvement available for general purpose code. I will be personally pushing for that as 1) I'll have RVV 0.7.1 hardware probably this month, 2) I know both RVV 0.7.1 and 1.0 well and can write these routines in my sleep, and 3) I have FSF copyright assignments in place for gcc, binutils, glibc. If you are only interested in computing devices with contemporary x86 or M1 performance then, sure, it's going to be quite some years before you have to care about either SVE or RVV. Apple might well implement SVE sometime soon -- obviously no one knows. I'm typing this on a 16 GB M1 Mac Mini. It's replaced my 32 core ThreadRipper running Linux for day to day use as it's silent and has snappier UI, and is faster for anything using up to four cores, and not all that much slower even for things that sometimes use 32 cores. See for example the last test in http://hoult.org/arm64_mini.html http://hoult.org/arm64_mini.html where it's 71% as fast as the ThreadRipper building the entire RISC-V GNU toolchain in a Linux for arm64 VM. Actually that was on a Mini with 8 GB RAM where I couldn't afford to allocate more than 4 GB to the VM. It's faster than that on my current 16 GB Mini.