The question we all want the answer to is what is the current most likely contender for a decent performance widely available implementation of this profile, and when is it due?
I'm not aware of any chips, even in development, that will genuinely have full RVA23 support. If you'll settle for "near enough" then my betting is we'll have SiFive P650/P670 hardware first (https://www.sifive.com/cores/performance-p650-670). There are some other development boards coming (sorry, under NDA!) that should have near-RVA23 + Xeon-like performance and we should get them in very end 2025 / early 2026. These are server-class parts so the development boards will not be cheap.
Some parts of RVA23 like a complete implementation of the vector sub-extensions, and hypervisor support, are pretty complex.[1]
If you just want RVA23 now (with poor performance) then qemu implements it. We found it's not very useful for software development, not just because it's slow, but also because it performs so differently from the real hardware, so you cannot, for example, optimize your vectorized code.
> There are some other development boards coming (sorry, under NDA!) that should have near-RVA23 + Xeon-like performance and we should get them in 2026. These are server-class parts so the development boards will not be cheap.
I can get a 3A6000 system for 400€ with decent (~Zen2) performance, are we talking more than that?
But RISC-V predates loongarch64 - why did Loongson create a new ISA instead of implementing a fast RISC-V core?
Sure you can move faster if you can make your own standards and don't have to coordinate with anyone, but still makes me wonder if there is some fundamental issue that makes it difficult to create a high performance RISC-V implementation.
How does it compare to the current RISC-V leader, ESWIN SiFive P550?
Anyway, China seem to have decided to pursue a dual strategy of pouring money into RISC-V and LoongArch at the same time. I've no idea why that is. The company I work for talks to several RISC-V vendors who don't believe there is any issue with the RISC-V ISA for high performance server-class application cores.
The P550 is pretty slow. It doesn't have any SIMD, and it's scalar engine is ~about the same as a Core 2 from ~2008. In general, it's fairly confusing to me why SciFive has been so cautious in their designs. It seems like they would be in a much better place if they'd released a few CPUs where rather than trying to balance everything while creeping complexity up, they just added all the power to theoretically match high end CPUs and then addressed the bottlenecks over iterations.
Loongarch is built on MIPS, so the core predates RISC-V by decades.
RISC-V didn't have the specs to build what they were targeting when they started designing a few years ago. Given the similarities in the ISAs, I suspect they may switch to RISC-V in the near future.
It is a sad day in history to see both a RISC-V-related acronym and NDA used in the same sentence. The term oxymoron barely cuts it IMO. I thought that RISC-V used to stand for open hardware and freedom, TIL.
The RISC-V specs are all free to download and implement. Some (by no means all) implementations are proprietary. Red Hat (the company I work for) talks to all sorts of server vendors, x86, Arm, POWER, RISC-V all the time under NDA so we can find out what new products those vendors are developing before they are released, and have software ready in time. The software we write is all open sourced. This is nothing particular to do with RISC-V, and has nothing to do with the RISC-V ISA, nor with open sourcing of software.
My bets are on Tenstorrent Ascalon. They are currently taping out and planning to release a 8 core@2.25GHz devboard and laptop next year. The cores have an 8 wide decode/issue/dispatch and dual issue 256-bit RVV support.
Their the scalar part of their scheduling model is already upstream in LLVM as tt-ascalon-d8.
The only I can think of that may deliver earlier is Ventana with the Veyron V2, they plan to have chiplets in the first half of this year. I'm not sure if they are planning on releasing devboards though, as they target big servers. The cores have a 16 issue backend, with 5 512-bit RVV execution units (arithmetic,mask,permut,load,store) and a decode of up to 10 instructions per cycle.
This release adds the cray style variable length vector instructions. Compiling with avx512 and running without it will crash, but this just uses whatever length the chip supports with the same instruction. Also means you don't have to wait on llvm to update every time they grow the vector size.
I don't get why they decided to create all these very complicated extensions before even getting solid hardware for the base instruction set. RVV support is many, many years into the future and I bet many of its instructions will be micro coded since they aren't very useful for compilers anyway. Specifying standards for the future before you have working prototypes is very (ahaha) risky.
There is solid hardware, it just not standard hardware for consumers. RVV support in software is already good and there are already many commercial chips.
> I bet many of its instructions will be micro coded since they aren't very useful for compilers anyway
I have listened to a lot of the talks about RISC-V and many about Vector extension, and micro-coding was barley mentioned.
What is more common is that people don't implement all the instructions in academic settings.
> Specifying standards for the future before you have working prototypes is very (ahaha) risky.
Absolutely nothing is standardized before hardware implementations exist. In fact, for Vector there was a first generation of the 0.7 that saw limited commercial use and far more more for the RVV 1.0 version.
The question we all want the answer to is what is the current most likely contender for a decent performance widely available implementation of this profile, and when is it due?
I'm not aware of any chips, even in development, that will genuinely have full RVA23 support. If you'll settle for "near enough" then my betting is we'll have SiFive P650/P670 hardware first (https://www.sifive.com/cores/performance-p650-670). There are some other development boards coming (sorry, under NDA!) that should have near-RVA23 + Xeon-like performance and we should get them in very end 2025 / early 2026. These are server-class parts so the development boards will not be cheap.
Some parts of RVA23 like a complete implementation of the vector sub-extensions, and hypervisor support, are pretty complex.[1]
If you just want RVA23 now (with poor performance) then qemu implements it. We found it's not very useful for software development, not just because it's slow, but also because it performs so differently from the real hardware, so you cannot, for example, optimize your vectorized code.
[1] I wrote a general article about RISC-V extensions last year: https://research.redhat.com/blog/article/risc-v-extensions-w...
> There are some other development boards coming (sorry, under NDA!) that should have near-RVA23 + Xeon-like performance and we should get them in 2026. These are server-class parts so the development boards will not be cheap.
I can get a 3A6000 system for 400€ with decent (~Zen2) performance, are we talking more than that?
[deleted - didn't realise you were talking about loongarch, see reply below]
But RISC-V predates loongarch64 - why did Loongson create a new ISA instead of implementing a fast RISC-V core?
Sure you can move faster if you can make your own standards and don't have to coordinate with anyone, but still makes me wonder if there is some fundamental issue that makes it difficult to create a high performance RISC-V implementation.
> why did Loongson create a new ISA instead of implementing a fast RISC-V core?
Simple: They're a MIPS shop.
How does it compare to the current RISC-V leader, ESWIN SiFive P550?
Anyway, China seem to have decided to pursue a dual strategy of pouring money into RISC-V and LoongArch at the same time. I've no idea why that is. The company I work for talks to several RISC-V vendors who don't believe there is any issue with the RISC-V ISA for high performance server-class application cores.
The P550 is pretty slow. It doesn't have any SIMD, and it's scalar engine is ~about the same as a Core 2 from ~2008. In general, it's fairly confusing to me why SciFive has been so cautious in their designs. It seems like they would be in a much better place if they'd released a few CPUs where rather than trying to balance everything while creeping complexity up, they just added all the power to theoretically match high end CPUs and then addressed the bottlenecks over iterations.
> How does it compare to the current RISC-V leader, ESWIN SiFive P550?
I couldn't find many benchmarks of the P550, but at Phoronix it got beaten by a Raspberry Pi 4
https://www.phoronix.com/review/sifive-hifive-premier-p550
which the 3A6000 beats easiely
https://openbenchmarking.org/vs/Processor/Loongson-3A6000,AR...
Loongarch is built on MIPS, so the core predates RISC-V by decades.
RISC-V didn't have the specs to build what they were targeting when they started designing a few years ago. Given the similarities in the ISAs, I suspect they may switch to RISC-V in the near future.
It is a sad day in history to see both a RISC-V-related acronym and NDA used in the same sentence. The term oxymoron barely cuts it IMO. I thought that RISC-V used to stand for open hardware and freedom, TIL.
The RISC-V specs are all free to download and implement. Some (by no means all) implementations are proprietary. Red Hat (the company I work for) talks to all sorts of server vendors, x86, Arm, POWER, RISC-V all the time under NDA so we can find out what new products those vendors are developing before they are released, and have software ready in time. The software we write is all open sourced. This is nothing particular to do with RISC-V, and has nothing to do with the RISC-V ISA, nor with open sourcing of software.
Riscv is an open ISA specification, not implementation
Organizations are free to make closed and even secret implementations of it if they like
That was not what the RISC-V supporters promised.
Most "RISC-V supporter" do at the very least understand what RISC-V is, and what it isn't.
I have never seen an actual RISC-V supporter confuse ISA and microarchitecture.
My bets are on Tenstorrent Ascalon. They are currently taping out and planning to release a 8 core@2.25GHz devboard and laptop next year. The cores have an 8 wide decode/issue/dispatch and dual issue 256-bit RVV support. Their the scalar part of their scheduling model is already upstream in LLVM as tt-ascalon-d8.
See also: https://youtu.be/ttQtC1dQqwo
The only I can think of that may deliver earlier is Ventana with the Veyron V2, they plan to have chiplets in the first half of this year. I'm not sure if they are planning on releasing devboards though, as they target big servers. The cores have a 16 issue backend, with 5 512-bit RVV execution units (arithmetic,mask,permut,load,store) and a decode of up to 10 instructions per cycle.
See also: https://youtu.be/OPgjCjNhqKQ
Both of these claim to support full RVA23 and are high perf OoO cores.
After Chimera Linux’s pessimistic view on RISC-V application processors, I’m not holding my breath
https://chimera-linux.org/news/2025/03/dropping-riscv.html
Note they eventually received a donation of CPU time that allows them to continue RISC-V support but it’s still a grim situation.
This release adds the cray style variable length vector instructions. Compiling with avx512 and running without it will crash, but this just uses whatever length the chip supports with the same instruction. Also means you don't have to wait on llvm to update every time they grow the vector size.
The link is pretty light on details, should this be replaced with the 'read more' link within
Maybe link straight to the profile: https://lf-riscv.atlassian.net/wiki/spaces/HOME/pages/161547...
[dead]
[flagged]
I don't get why they decided to create all these very complicated extensions before even getting solid hardware for the base instruction set. RVV support is many, many years into the future and I bet many of its instructions will be micro coded since they aren't very useful for compilers anyway. Specifying standards for the future before you have working prototypes is very (ahaha) risky.
I can only speculate that the base was insufficient for high commercial traction.
There is solid hardware, it just not standard hardware for consumers. RVV support in software is already good and there are already many commercial chips.
> I bet many of its instructions will be micro coded since they aren't very useful for compilers anyway
I have listened to a lot of the talks about RISC-V and many about Vector extension, and micro-coding was barley mentioned.
What is more common is that people don't implement all the instructions in academic settings.
> Specifying standards for the future before you have working prototypes is very (ahaha) risky.
Absolutely nothing is standardized before hardware implementations exist. In fact, for Vector there was a first generation of the 0.7 that saw limited commercial use and far more more for the RVV 1.0 version.