Hacker News Reader

Comment by andai | Hacker News Reader

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!

View on HN

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/

You aren't disagreeing with the existence of the roadblock, just how hard it is to overcome.

And yes, there is a bunch of funding being pumped into it. I do have hope that some kind of RISC-V linux workstation will be viable in the next 5 years, without sacrificing too much performance or my wallet. I just wouldn't expect that to translate into making inroads into existing markets where x86 and arm have moats, like android/apple smartphones and more typical desktop/laptop workloads (even on linux).

I wouldn't count the AI/GPU stuff, those are generally pretty simple RISC pipelines with large vector units. Though TensTorrent do actually have a high-performance out-of-order rva23 core [1] that would be able to compete in this space. They are currently selling it as a "core for agentic workloads"

[1] https://tenstorrent.com/en/ip/risc-v-cpu9719654910d.pdf

The XuanTie C950 looks pretty beefy for a RISC-V chip with integrated TPE. But it isn’t available commercially. They are moving fast in China, wouldn’t be surprised if they offer a breaking integrated solution in the near future. There aren’t any benchmarks available for the C950 but the comparisons go towards early Apple M-Series performance.

the x86 is just an abstraction layer at this point

> China was investing heavily in RISC-V, which implies that either they're going to have to settle for permanently crippled perf

Not quite. RISC-V application class processors are a new development. They are starting from behind but they are improving faster than the competition. The SpacemiT K3 is 4 times faster than the K1 for example. The Alibaba C950 will be about Apple M1 level performance. And even faster designs are already in the works.

RISC-V is not “permenantly crippled”. It will catch up and maybe surpass ARM. It is more an economy of scale issue than anything.

My understanding is that RISC-V needs both economies of scale AND chips that are manufactured at the bleeding edge fabs (smallest dies, etc) which is a lot more expensive. It's a chicken and egg problem as there's not (yet?) demand. The architectural limitations will remain until there's incentive to work on it.

In many ways it's not much different than Linux was in the 1990s. It was cheap and useful, but often not as performant as commercial OSes (UNIX or even windows) until big corporate money came in and started piling resources into it. Distribution fragmentation was also an issue, which could still cause headaches for RISC-V (especially if some companies start adding proprietary performance extensions that others can't). So I think it remains to be seen how RISC-V will pan out (eg will the cloud vendors see enough of an ROI supporting it for higher end computing than buying ARM licences).

> RISC-V needs both economies of scale AND chips that are manufactured at the bleeding edge fabs (smallest dies, etc) which is a lot more expensive. It's a chicken and egg problem as there's not (yet?) demand

Whatever leading-edge fab capacity (mostly TSMC) was available, is now tied up to supply the ongoing AI boom. And will remain so for the foreseeable future. Even if you'd have a RISC-V product for which demand/economics work out, chances are those fabs' order books are filled.

Also: design is done in many places, but actual fabrication of RISC-V SoCs in largely centered in China. Which (afaik) doesn't lack IC fabrication capacity. But does lag in leading-edge fab capacity. So: off to older nodes. Which may hurt perf/W, cost effectiveness or transistor budget. Or pay a premium (pricing products out of markets), limited production, or long lead times.

Of course this affects ARM based & other products too. But they've been in the optimization / mass fabrication / distribution pipeline much longer than most RISC-V based products. Catching up takes time, and top-tier fab capacity being swiped by Nvidia & co doesn't help to shorten that process.

I don't think it's a demand problem. Consumers don't care what powers their phone/tablet/laptop as long as it does its job. So in principle the market is there (yeah.. I understand issues like Google still working on Android-RISC-V, Windows users probably wanting x86 for legacy software etc).

It can be a demand problem. People/companies aren't going to spend the time optimizing (including compilers/code) if there's no payoff that's greater than the delta for an arm chip.

That being said, demand from and via China (which has a geopolitical case for wanting to see risc-v succeed) will probably end up being what drives it forward.

The SiFive, Tenstorrent, Rivos (Meta), and Qualcomm RISC-V chips are not fabricated in China. I mean, Chinese suppliers may license their cores of course. But even Chinese RISC-V makers were going to use TSMC until US sanctions got in the way.

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.

Are they on the latest silicon process?

Because, without neglecting the micro-architecture, we all know how critical the silicon process is for high-end performance.

The first Ascalon silicon, Atlantis, will not be the latest process. As you say, that will impact performance. But there are plans for other chips to use newer process, and of course you can license and do what you like.

The point is that RISC-V is not limited to lower performance by the ISA.

So RISC-V is 'dragged down' because it cannot access the best silicon process (hardware big tech is hogging production capacity... how convenient...)

I think it will be closer to Zen 1/2

I've seen this claimed before, and just going by SiFive's specint claims the P870 at 2.6GHz should match Zen 3.

But for SiFive's last silicon, the HiFive Premier P550, they claimed a specint2006 of 8.65/GHz. That should put the silicon only about 20% slower than an intel i5-6400. But if you look at geekbench scores it's about an order of magnitude slower.

Correct me if I'm wrong, but Tenstorrent has yet to ship any of their own cores? They do make very similar claims to SiFive.

Personally I'm very skeptical that these cores will be anywhere near Zen 3. I recon their performance claims are based on best-case CPU simulation, rather than a real measurement. I'd expect Raspberry Pi 4 levels of performance, a bit over double SiFive's current state of the art. An impressive improvement, but nowhere near Zen 3.

The P870 is probably faster than the Cortex-X1 in my phone, which would put it on a similar per level to Zen1.

When I had brief access to a very early P870 devboard running at 2GHz it scored 2% worse than an 2.86GHz Cortex-X1 in the 7-zip benchmark compression (it was a 40% worse in decompression, but that has NEON optimized Arm assembly path and non for RISC-V). Because this was very early hardware still in bringup I expect them to get closer to the announced 2.7GHz.

But yeah, the RISC-V geekbench scores of publically available RISC-V processors are suprizingly low and idk why. Part of it is the lack of RVV support is certain workloads, but that doesn't explain the entire gap. When I looked at ST scalar performance my self it looked more comparible to similarly sized Arm CPUs.

I think I'll have to order a Pi5 (Cortex-A76) and investigate where it performes different to the SpacemiT K3 (SpacemiT X100).

On paper they should be very similar, both 2.4GHz, 4-wide decode, 3xALU, 1xBranch, (although the A76 has those on 4 execution units, while the X100 has 3 with one sharing ALU and Branch support), 2x load/store, 2xFP. The biggest obvious difference (appart from ISA), may be the cache setup after L1, with the K3 having a 4Mib L2 shared between 8 cores (no L3) and the Pi5 having a 512KiB L2 and a 2MB L3 shared between 8 cores.

> I'd expect Raspberry Pi 4 levels of performance

Well, there is some speculation regarding these chips so no sense arguing too much about it.

That said, the SpacemiT K3 is already faster than a Pi 4 and even substantially faster than a Pi 5 for multi-core and vector stuff. And that is before counting the other 8 “AI cores” it has.

These chips will be quite a bit faster than a K3, so certainly much faster than a Pi 4.

Neat! Hopefully these new architectures can beat the Pi5, though even that's still far away from Zen 1 let alone Zen 3.

> and even substantially faster than a Pi 5 for multi-core and vector stuff

I'll push back a little on this. It can be faster under certain workloads, but is not universally. It's behind in geekbench https://browser.geekbench.com/v7/cpu/compare/146501?baseline..., and in compilation workloads: https://www.phoronix.com/review/spacemit-k3-pico-itx/3

> 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?

Yes, the fundamental problem is the fact that everybody involved in RISC-V wants to sell IP instead of a chip.

The problem with the RISC-V chips in non-embedded contexts (ie desktop or server) has absolutely nothing to do with the instruction set architecture (not entirely true but a really good first approximation). The problem is that performance is strongly dependent upon your high speed interfaces--memory, graphics, PCI, etc. And those blocks need to be strongly integrated in with your CPU interfaces.

However, if you buy a whole bunch of IP blocks and then just wire them together, your performance is going to be sub-par. And this is what every single RISC-V chip that I know of currently is.

It's not beyond someone to sit down and do the required integration like Apple did for ARM. There's just insufficient money in it so nobody is going to expend the engineers.

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.

Wait, so RiscV is still also a brick, like x86?

in my opinion, yes. Given that it was a clean-sheet design with no legacy to support, and that it was done so recently as to have easily had the benefit of all the lessons of x86, mips, arm, sparc, powerpc, etc, yes, it left a lot of obvious improvements on the table.

When everyone is trying to make bricks fly, having the most aerodynamic brick probably isn't a bad thing.

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

History tells us that open standards pretty much always beat out proprietary ones in the end.

You cannot buy the company backing RISC-V to take out the competition. And if a RISC-V company stumbles, the ecosystem carries on. But if even one RISC-V company is in the right place at the right time, RISC-V can surge ahead. It is hard to imagine it does not dominate eventually.

Which is really the subtext to Grinberg's rant. It has technical flaws that he dislikes, but those won't stop RISC-V from dominating in the market.

You get these kinds of responses when something is too close to perfection. It suddenly gets judged in a much different light.

I don't agree with history telling us that at all. HDMI, MP3, MPEG, .docx, DirectX, CUDA, I'm sure there are more. History tells us that money wins.

But I also think this is an example of a slight disingenuity in RISC-V being referred to as open-source. It's borrowing the clout of open-source software projects where the end user has the freedom to compile them at home. I can't fabricate a CPU at home, I'm still beholden to whatever patents the manufacturer chooses to license. SiFive have a >billion dollar valuation, for a business based on selling licences.

Those standards are adopted because they work. And they work because someone poured in tons of RnD to make them work. And those people are incentivised to do the RnD because they get paid (patents).

Nowadays nobody will want to work on foundational open source work for free only to enrich everyone else that builds on top of it.

What I see is that you'll get low end chips for embedded applications, because you tend to specifically build and compile programs for things as small as that. You'll also get the large sever and massive super-computer scale systems, because yet again you'll compile code specifically for those systems.

What you're less likely to get is the consumer level PC and Laptop systems, as you'll need one large company to set the standard and others to adhere to it. So you could feasibly compile a program for a certain level of RISCV chip and have it run on many vendors processors. As it is there's several companies trying to push ARM for some sort of high end consumer PCs/Laptops but they all require different OSes and the chips aren't equivalent, so you have to compile software separately for those different platforms.

So far the vast majority of complaints have been nothing burgers.

The biggest valid complaint is the lack of dedicated mask registers for vector processing, that's a huge design flaw in the vector instructions since it makes register renaming and shadow registers mandatory. In other words, the problem here is that they didn't stick with the RISC philosophy of making everything explicit.

Compressed instructions are mostly wasted encoding space, but from a performance perspective they don't matter. If they are slow then compilers will treat them as slow legacy instructions and stop using them or they will only emit aligned compressed instructions.

> 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.

Reply on news.ycombinator.com