Harder to write compilers for RISC? I would argue that CISC is much harder to design a compiler for.
That being said there's a lack of standardized vector/streaming instructions in out-of-the-box RISC-V that may hurt performance, but compiler design wise it's much easier to write a functional compiler than for the nightmare that is x86.
The Vector extension has been ratified since 2021 it's a standard part of the spec just don't expect a random microcontroller to support it.
The SpacemiT K1 is 64GCVB and RVA22, doesn't say which specific RVA22 there's some without Vector support but it says in "GCVB" so w/e, also, "VLEN 256/128-bit x2 execution width", if I'm parsing that correctly means you either get 256-bit vector registers or set the whole thing to 128 and then get (roughly) twice the ops/s.
And yes it's much easier to emit vector code than to deal with the nightmare that's SIMD. It's as if Intel would've been sensible ages ago and not introduced SIMD but expanded on repnz stosb to make it useful for things other than memcpy. And no Intel has no excuse: Crays existed when they decided on SIMD.
How good are the RISC-V vector instructions implementations IRL? I've never heard of them. My experience with ARM is that even on certain data center chips the performance gains are abyssal (when using highly optimized libraries such as dpdk)
It's bound to differ wildly. Most ARM chips are Contex Asomethings, that is, ARM designs, and those that aren't are designed by companies with lots of resources... but also with mobile and embedded as their primary market so it's not the primary focus. Most RISC-V cores are open source designs and/or created by startups, generally also not targeting HPC. The EU is investing into RISC-V HPC for EuroHPC (that is, supercomputers), you might be able to buy a chip associated with that soonish and try for yourself.
Heck, you can build a microcontroller-class chip that supports vector instructions -- you just have to iterate element by element. Instruction support does imply that the instructions work, not that they're fast.
That should be more on the BLAS side of things though, if you want to packet route I guess wait until Mikrotik ships boards with RISC-V SoCs, I haven't heard anything and definitely not official statements but they're bound to get on the train. They used Tilera in the past and as far as I'm aware the reason they switched away was Tilera overall failing, not because it didn't work for the application. A structurally similar RISC-V chip should be quite easy to design and as it's a standard architecture you don't have to write your own libraries so it's way easier to not go bankrupt doing it. Oh and Tilera of course definitely isn't a Vector chip, it's a "have a gazillion cores on a die, each barely larger than a DSP" kind of approach. You can have a core per pair of ports or whatever it is they're doing.
Another interesting thing would be RISC-V GPUs. They do a lot of memory stuff that makes them so much better at BLAS stuff and vector instructions fit right into that. For proper graphics support you'd still need a custom ISA extension to wire up some odds and ends (say the texture units with their crazy indexing operations) but it's definitely an option... which is unlikely to see HPC scale any time soon as I don't see NVidia, AMD or Intel giving up the architectures they have.
Harder to write compilers for RISC? I would argue that CISC is much harder to design a compiler for.
That being said there's a lack of standardized vector/streaming instructions in out-of-the-box RISC-V that may hurt performance, but compiler design wise it's much easier to write a functional compiler than for the nightmare that is x86.
The Vector extension has been ratified since 2021 it's a standard part of the spec just don't expect a random microcontroller to support it.
The SpacemiT K1 is 64GCVB and RVA22, doesn't say which specific RVA22 there's some without Vector support but it says in "GCVB" so w/e, also, "VLEN 256/128-bit x2 execution width", if I'm parsing that correctly means you either get 256-bit vector registers or set the whole thing to 128 and then get (roughly) twice the ops/s.
And yes it's much easier to emit vector code than to deal with the nightmare that's SIMD. It's as if Intel would've been sensible ages ago and not introduced SIMD but expanded on
repnz stosbto make it useful for things other than memcpy. And no Intel has no excuse: Crays existed when they decided on SIMD.How good are the RISC-V vector instructions implementations IRL? I've never heard of them. My experience with ARM is that even on certain data center chips the performance gains are abyssal (when using highly optimized libraries such as dpdk)
It's bound to differ wildly. Most ARM chips are Contex Asomethings, that is, ARM designs, and those that aren't are designed by companies with lots of resources... but also with mobile and embedded as their primary market so it's not the primary focus. Most RISC-V cores are open source designs and/or created by startups, generally also not targeting HPC. The EU is investing into RISC-V HPC for EuroHPC (that is, supercomputers), you might be able to buy a chip associated with that soonish and try for yourself.
Heck, you can build a microcontroller-class chip that supports vector instructions -- you just have to iterate element by element. Instruction support does imply that the instructions work, not that they're fast.
That should be more on the BLAS side of things though, if you want to packet route I guess wait until Mikrotik ships boards with RISC-V SoCs, I haven't heard anything and definitely not official statements but they're bound to get on the train. They used Tilera in the past and as far as I'm aware the reason they switched away was Tilera overall failing, not because it didn't work for the application. A structurally similar RISC-V chip should be quite easy to design and as it's a standard architecture you don't have to write your own libraries so it's way easier to not go bankrupt doing it. Oh and Tilera of course definitely isn't a Vector chip, it's a "have a gazillion cores on a die, each barely larger than a DSP" kind of approach. You can have a core per pair of ports or whatever it is they're doing.
Another interesting thing would be RISC-V GPUs. They do a lot of memory stuff that makes them so much better at BLAS stuff and vector instructions fit right into that. For proper graphics support you'd still need a custom ISA extension to wire up some odds and ends (say the texture units with their crazy indexing operations) but it's definitely an option... which is unlikely to see HPC scale any time soon as I don't see NVidia, AMD or Intel giving up the architectures they have.