Comment by ndiddy
7 hours ago
I think he's kind of speaking past the original author. The original piece is basically about how the author doesn't think that RISC-V will take off outside embedded, because of some design decisions that lead to poor performance compared to ARM64 and because so much of the ISA being optional means that there's too much fragmentation to make binary distribution feasible. Meanwhile, this piece is mainly about how RISC-V is great for embedded because companies can build it into custom chips with specifically the functionality they need, and because of how cheap it is for low-end use cases since there's no license fees.
The only real point of contention I see between the two is that this piece goes on to talk about how it's a selling point that RISC-V can be used for both low-end 10 cent microcontrollers, and high-end multi-core processors running Linux. Personally I don't see the benefit of this since you're going to have to recompile your software anyway, and since all the RISC-V SBCs I'm aware of have significantly worse performance and efficiency than comparably priced ARM SBCs.
The two authors also have a very different definition of what "high-end" means.
Dmitry is talking about high-end application processors that you might find in a mid-range or better laptop, smartphone or server. Armstrong Subero seems to think that anything larger than a "dirt cheap microcontroller" is high-end.
People shouldn't take this the wrong way, but the VexRISC-V cores in Baochip are not "high-end". They are basically as low-end as you can get while still meeting the modern definition of "application core". And that doesn't matter, because being high-end application SoC is not Baochip's design criteria. These cores are actually pretty decent for Baochip's criteria.
The VexRISC-V are implementing the exact style of "classic-RISC" microarchitecture that RISC-V is optimised for. It's basically the optimal niche for RISC-V, before any of the problems start showing up.
I don't think I've ever seen anyone express the opinion that RISC-V can't easily cover the "dirt cheap microcontroller" to "low-end application processor" range, even stretching up into "mid-range application processor". Just that it's really fighting an uphill battle if it ever wants to compete with high-end application processors (and that it's going to struggle in the low-range/mid-range application market because of that).
To add to what you said, I don't see any big issues with high-end prosessors and licenses.
Anyone who spends $200 million to develop a completely new high-end processor microarchitecture every 3 to 5 years is not going to complain about an ARM license too much. You get freedom with $$.
If you got “freedom with $$”, there would have been no ARM/Qualcomm lawsuit.
1 reply →
First, im a big fan of what riscV has brought into the world; 0.50 cent processors with radios that can reach a kilometer, 8 cent MCUs that you can put anywhere because they are basically free, 8 dollar Linux computers, and 1 dollar WiFi nodes that can run reasonable applications. And also, the first application capable chip you can actually trust to be free of unpublished capabilities.
RiscV is going to win despite its limitations, simply because they can be worked around freely, and the cost per core is zero. Every major company will be making their own flavor, because it’s the only way they can economically own the product of their work. Not many companies can be Qualcomm or Apple, but when a company invests millions in an architecture, they want it to be an asset on -their- balance sheet. It may not be the best starting point, but it’s the only journey that ends in ownership without starting from scratch.
X86 had dominance for decades not because it’s the best architecture, but because it was the best choice. RiscV doesn’t have to be the best architecture to be the best choice for companies to build on.
Can you list the actual chips you’re referring to and additional sources to follow? I’ve finally started playing with ESP32 and recently getting curious about the smallest possible things out there. Also
Interesting. So I've seen a lot of reviews of RISC-V machines and they seem to be a decade or more behind in terms of performance.
I always thought that was a case of "the tech is still catching up",[0] but it sounds like there are fundamental issues that prevent performant implementations?
If so... I heard China was investing heavily in RISC-V, which implies that either they're going to have to settle for permanently crippled perf, or find a way around the issues.
--
[0] Making chips is an extremely high tech process with decades of trial and error and proprietary secrets, so this would be the logical explanation to me regardless of architecture. But I'm not hardware guy, so I'd love to hear more about this!
No.
Intel and AMD have proven that if you throw enough money at the problem, you can make fast microarchitectures despite a flawed ISA, and in many ways RISC-V is less flawed than x86. The things we are debating here are more along the lines of minor nitpicks.
The main roadblock to the existence of fast RISC-V cores is the entrenchment of large x86 and arm ecosystems.
> The main roadblock to the existence of fast RISC-V cores is the entrenchment of large x86 and arm ecosystems.
I'd disagree with that, their existence and decades of a head start mean they've been much more well invested but that's one of the things we're starting to see change, even if it's because of what would appear to be political motivations. We're starting to see a lot of investment into it in China because it looks like it's a reasonable way for tech sovereignty against the x86 monopoly. They've got licenses to some older (not sure about newer) AMD processor designs, I think around Zen2 architecture, for one of their major manufacturing firms but that won't easily let them move forward since they've got to do a lot of work to keep it up with compatibility and performance for newer ISA additions and such. That's one of the reasons they've been subsiding development of LoongSong64 and RISC-V to the point where for a while the larger LoongSong64 cores were illegal to export to some countries[0].
And then you've got a lot of other companies building faster RISC-V cores, for yes more embedded style designs but not the usual traditional embedded designs either. You've got TensTorrent working on AI work loads with real hardware out there that at least for ML stuff can compete on inference if you can get your software to run on it, and then you've got Bolt doing similar for GPU workloads[1]. While both of those are closer to embedded since you're not going to use them as a desktop, they're still making really fast RISC-V cores that could be theoretically turned into a standard RVA23 core by adding the missing extensions to make it work. That's of course not trivial but the entrenchment of x86 and arm aren't quite as daunting as they might have originally seemed.
It's still not as fast as I'd like, simply because I want to start seeing some RISC-V mini pcs get made that are fine for a daily driver office pc to happen.
[0] https://www.tomshardware.com/news/china-bans-exports-of-its-...
[1] https://bolt.graphics/
1 reply →
x86 is a horrible architecture, but most of the modern high performance processors are x86. They're only now getting around to making comparatively performant ARM chips.
Not having decently performing risc-v chips right now doesn't mean anything other than nobody spent enough time and money on accomplishing that.
the current highest performance RISC-V systems you can buy off a shelf are equivalent to a raspberry pi 5 so they're not terribly behind. in terms of IPC, currently available RISC-V cores are already basically on par with Zen 3 and Apple M1 from what i understand and Jim Keller believes that RISC-V will be the one that leads the way for raw performance.
SiFive P870 and Tenstorrent Ascalon are pretty much Zen 3. Tenstorrent is supposed to be releasing silicon soon. You can license their cores now. SiFive says customers have the P870 already but I am not sure who those are.
1 reply →
With enough effort, you can make a brick fly. X86 proves this. But if you are designing a new flying device, despite the fact that you could make a brick fly, you probably don’t want to design a brick. Why make it harder on yourself?
Riscv took all this information in, and designed a very, very good brick.
the main problem with RISC-V is also the main selling point: there is no single owner company behind steering development and making sweeping decisions
how will that pan out over the long term is really unclear and the reality is performance is actually catching up quickly
> it sounds like there are fundamental issues that prevent performant implementations?
This has always been true, it is just this is one of those projects that gets some people very emotionally invested so such discussions do not happen in public.
See also Android, rust, webassembly, webgpu and so on.
Well the original article is also about RISC-V isn't a great ISA for embedded either, and how that's supremely disappointing because there's no inherent reason why the designers couldn't have learned from decades of ISA research and made it suck even a little less. OP doesn't even defend the ISA committee (unlike HN, somehow...)
As much as people complain about warts in other ISAs like x86, their design decisions made sense back when they were made (or at least, no one really knew better)
> Personally I don't see the benefit of this since you're going to have to recompile your software anyway
The benefit is a unified toolchain. Make a chip, get the entire software toolchain for free.
In the past if you made your own chip you had to write your own assembler, compiler, debugger, etc. Many manufacturers forked gcc but of course it's still a lot of work and the license isn't great (for them, not the user).
This universal compiler toolchain is massive benefit for both the chip makers and the end user.
Different RISC-V dialects might as well be as different from each other as English is from German. Sure, the cognates, family the resemblance, and common(-ish) alphabet make some things easier, but if you're shipping a manual, you still need to do it both in English and auf Deutsch unless you rely on machine translation.
So it is with the family of mutually incomprehensible ISAs called RISC-V.
Yeah I know this mess in PowerPC. There is IBM Power, there is MPC5xx ISA, there is VLE and and several other dialects. Some processors are doing those some doing others, some needs bit to signal if program runs VLE... just crazy chaos.
The huge number of companies building RISC-V chips and really crazy optimizations that they are doing in all kinds of spaces are a very real counterweight to your notion.
And RISC-V is just starting here with shoestring design and fab budget. Wait till all engineering teams really adopt it like Tenstorrent and NextSilicon and so on.
> The huge number of companies building RISC-V chips and really crazy optimizations that they are doing in all kinds of spaces are a very real counterweight to your notion.
I assume this is addressing
> and since all the RISC-V SBCs I'm aware of have significantly worse performance and efficiency than comparably priced ARM SBCs.
If so, could you point at specific SBCs that beat ARM SBC perf?
Take a look at some of the really new ones, like the Milk-V Jupiter 2 based around the SpaceMIT K3[0]. Single core is still lacking but the multi-core isn't all that far behind a pi5 (350 vs 900 single core and 1700 vs 2100 multicore in a geekbench beta version).
And I will note that the other poster didn't say they beat it, just that there are lots of chips being built. I'd imagine that the cores on the tenstorrent cards would blow all the other arm cores out of the water if you could run the benchmarks on them directly, given the much higher core speeds and memory bandwidth etc.
[0] https://youtu.be/vSKA6thLI1U?t=993
1 reply →
> really crazy optimizations that they are doing
Any examples of this?
Here are a few random things I know of:
* Tenstorrent Ascalon has a neat optimization for certain LMUL>1 SIMD operations. LMUL=2 effectively unrolls the SIMD operation making it read two SIMD registers from every source and write two SIMD registers to the destination. There are however some instructions where LMUL=2 only needs to write to one registers, those are narrowing instructions (e.g. 64-bit to 32-bit truncation) and comparisons (which write to a LMUL=1 register with packed bits). When those SIMD instructions have to .vx form, which means one argument comes from a GPR, they now only need to write one SIMD register and need to read two SIMD registers. This matches what regular SIMD instructions need and because the silicon for the execution is much cheaper than register file ports, Ascalon can exexute these instructions in a single operation. So you can compare twice as many SIMD elements against a scalar, then you can against another SIMD register.
* Ventana (now under Qualcomm) talked a tiny bit about their fetch-block-optimizer and something that sounded like a L1i-trace cache. The fetch-block-optimizer would go to certain hot L1i entries and "optimize" them, with agressive instruction fusion including fusion of non-adjacent instructions.
* NextSilicon: Idk any details yet, but they said they handled RVC without increasing latency and that they've found a good solution for implement RVV and especially LMUL, which is a challange in out-of-order designs.
* OpenXiangShan: The fastes open-source CPU, is working on doing 2-ahead instruction fetch (the thing Zen5 added).
Now that being said, Ventana was bought by Qualcomm, we know the RISC-V team is still alive, but who knows if we'll ever see anything from that outside of Qualcomm?
The Tenstorrent Ascalon devboard is way behind schedule and on 12nm TSMC instead of a 4nm node the processor was designed for and is now supposed to clock at 1.38GHz. Though I think the delay has more to do with TT management problems then with the actual design.
While the scalar part of OpenXiangShan looks really good, the RVV imolementation is currently basically unusable. They want to have fix for the problems until the end of the year, but we'll have to see.
4 replies →
There aren't ones that wouldn't be served better by ARM
The improvement is entirely "we don't have to pay ARM"
3 replies →