3 ms·

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 bo

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

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.