Live data from Hacker News

RISC-V Is Sloooow

marcin.juszkiewicz.com.pl

241–250 of 397 posts

Re: RISC-V Is Sloooow

#241
post #109

This is why felix has been building the risc-v archlinux repositories[1] using the Milk-V Pioneer. I think the ban of SOPHGO is part to blame for the slow development.[2] They had the most performant and interesting SOCs. I had a bunch of pre-orders for the Milk-V Oasis before it was cancelled. It was supposed to come out a while ago, using the SG2380, supposedly much more performant than the Milk-V Titan mentioned i…

Can you articulate why you think this ban impacted anything and what you think the ban applies to?

I won't pretend to understand the geo-politics or rulings.

What I do know is since the ban, all ongoing products featuring SOPHGO SOCs were cancelled, and I haven't seen any products featuring them since. The SOPHGO forums have also closed down.

The Milk-V Oasis would have had 16 cores (SG2380 w/ SiFive P670), it was replaced by the Milk-V Megrez with just 4 cores (SiFive P550) for around the same price. The new Milk-V Titan has only 8. We're slowly catching up, but the performance is now one or two years behind what it could've been.

The SG2380 would've been the first desktop ready RISC-V SOC at an affordable price. I think it's still the only SOC made that used the SiFive P670 core.

Re: RISC-V Is Sloooow

#242
post #147

If I'm reading their chart right, they have barely half as much memory for their RISC-V machine compared to any of the others? I don't know enough to know whether it's actually bottlenecked by memory, but it's a bit odd to claim it's slower, give those numbers, and not say anything about it. I'd hope they ruled that out as the source of the discrepancy, but it's hard to tell without confirmation.

I think it's mentioned clearly in the article.

> RISC-V builders have four or eight cores with 8, 16 or 32 GB of RAM (depending on a board)

> The UltraRISC UR-DP1000 SoC, present on the Milk-V Titan motherboard should improve situation a bit (and can have 64 GB ram).

RISC-V SOCs just typically don't support much ram. With the exception of the SG2042 which can take 128GB, but it's expensive, buggy and now old.

So I am sure it's a combination of low ram and low clockspeeds.

Re: RISC-V Is Sloooow

#243
post #98

Earlier quoted context omitted.

All of those things are solved with modern extensions. It's like comparing pre-MMX x86 code with modern x86. Misaligned loads and stores are Zicclsm, bit manipulation is Zb[abcs], atomic memory operations are made mandatory in Ziccamoa. All of these extensions are mandatory in the RVA22 and RVA23 profiles and so will be implemented on any up to date RISC-V core. It's definitely worth setting your compiler target appr…

>Misaligned loads and stores are Zicclsm Nope. See https://github.com/llvm/llvm-project/issues/110454 which was linked in the first issue. The spec authors have managed to made a mess even here. Now they want to introduce yet another (sic!) extension Oilsm... It maaaaaay become part of RVA30, so in the best case scenario it will be decades before we will be able to rely on it widely (especially considering that RVA23…

RISC-V truly is the RyanAir of processors: Oh, you want FP maths? That's an optional extra, did you check that when you booked? And was that single or double-precision, all optional extras at an extra charge. Atomic instructions, that's an extra too, have your credit card details handy. Multiply and divide? Yeah, extras. Now, let me tell you about our high-end customer options, packed SIMD and user-level interrupts, only for business class users. And then there's our first-class benefits, hypervisor extensions for big spenders, and even more, all optional extras.

Re: RISC-V Is Sloooow

#244

Earlier quoted context omitted.

The original amd64 came out in 2003. Any patents on the original instruction set have long expired, and even more so for 32-bit x86.

Its not about patents. Believe what you want but there is a reason nobody else is doing x86 or ARM chips unless they are allowed by the owner.

You're probably right. It would be helpful to say what the reason is, if it's not patents.

Re: RISC-V Is Sloooow

#245

There was a Mastodon post some time back (~1y?) where someone realized that the fastest RISC-V hardware they could get was still slower than running it on QEMU. That's not how it usually works :\ RISC-V is certainly spreading across niches, but performant computing is not one of them. Edit: lol the author mentions the same! Perhaps they were the source of the original Mastodon post I'm thinking of.

The Milk-V Pioneer breaks that barrier, it's expensive though. And the risc-v architecture used is now old, the company that developed is was sanctioned by the US and is now dead.

Re: RISC-V Is Sloooow

#246
post #148

Does that page even say which RISC-V CPUs are being used that are slow? I couldn't see it, which seems a bit of pointless complaining.

> RISC-V builders have four or eight cores with 8, 16 or 32 GB of RAM (depending on a board).

Which boards are used specifically should not matter much. There's not much available.

Except for the Milk-V Pioneer, which has 64 cores and 128GB ram. But that's an older architecture and it's expensive.

Re: RISC-V Is Sloooow

#247
post #219

Earlier quoted context omitted.

PDP-11, m68k – to name a few, did not allow misaligned access to anything that was not a byte. Neither are RISC nor modern.

In regards to 68000 I don't remember, only used it during demoscene coding parties when allowed to touch Amiga from my friends. I have only seen PDP-11 Assembly snippets in UNIX related books, wasn't aware of its alignment requirements.

PDP-11 was a major source of inspiration for m68k architecture designers. The influence can be seen in multiple places, starting from the orthogonal ISA design down to instruction mnemonics.

It is quite likely that not allowing the misaligned access was also influenced by PDP-11.

Re: RISC-V Is Sloooow

#248

Earlier quoted context omitted.

>Misaligned loads and stores are Zicclsm Nope. See https://github.com/llvm/llvm-project/issues/110454 which was linked in the first issue. The spec authors have managed to made a mess even here. Now they want to introduce yet another (sic!) extension Oilsm... It maaaaaay become part of RVA30, so in the best case scenario it will be decades before we will be able to rely on it widely (especially considering that RVA23…

I think having separate unaligned load/store instructions would be a much worse design, not least because they use a lot of the opcode space. I don't understand why you don't just have an option to not generate misaligned loads for people that happen to be running on CPUs where it's really slow. You don't need to wait for a profile for that. As for `seed`, if you're running on a microcontroller you can just look up t…

>As for `seed`, if you're running on a microcontroller you can just look up the data sheet to see if it's seed entropy is sufficient.

It's a terrible attitude to have towards programmers, but looking at misaligned ops, I guess we can see a pattern from RISC-V authors here.

Most programmers do not target a concrete microcontroller and develop every line of code from scratch. They either develop portable libraries (e.g. https://docs.rs/getrandom) or build their projects using those libraries.

The whole raison d'être of an ISA is to provide a portable contract between hardware vendors and programmers . RISC-V authors shirk this responsibility with "just look at your micro specs, lol" attitude.

Re: RISC-V Is Sloooow

#249
A couple of corrections (the blog-post is by a colleague, but I'm not speaking for Marcin! :))

First, we do have a recent 'binutils' build[1] with test-suites in 67 minutes (it was on Milk-V "Megrez") in the Fedora RISC-V build system. This is a non-trivial improvement over the 143-minute build time reported in the blog.

Second, the current fastest development machine is not Banana Pi BPI-F3. If we consider what is reasonably accessible today, it is SiFive "HiFive P550" (P550 for short) and an upcoming UltraRISC "DP1000", we have access to an eval board. And as noted elsewhere in this thread, in "several months" some RVA23-based machines should be available. (RVA23 == the latest ISA spec).

FWIW, our FOSDEM talk from earlier this year, "Fedora on RISC-V: state of the arch"[1], gives an overview of the hardware situation. It also has a couple of related poorman's benchmarks (an 'xz' compression test and a 'binutils' build without the test-suite on the above two boards -- that's what I could manage with the time I had).

Edit: Marcin's RISC-V test was done on StarFive "Vision Five 2". This small board has its strengths (upstreamed drivers), but it is not known for its speed!

[1] https://riscv-koji.fedoraproject.org/koji/taskinfo?taskID=91...

[2] Slides: https://fosdem.org/2026/events/attachments/SQGLW7-fedora-on-...

Re: RISC-V Is Sloooow

#250

Earlier quoted context omitted.

Tenstorrent is supposedly taping out 8-wide Ascalon processors as we speak, with devboards projected to be available in Q2/Q3 this year. BTW. Keller is also on the board of AheadComputing — founded by former Intel engineers behind the fabled "Royal Core".

I can't know what Ascalon will actually be, but back in April/May 2025 there were actual performance numbers presented by Tenstorrent, and I analyzed what was shown. I concluded that Ascalon would be the x86_64 equivalent of an i5-9600K. That's useable for many applications, but it's not going to change the world. A lot of "micro PCs" with low power CPUs are well past that now. If that's what Ascalon turns out to be,…

I don't know what bubble you are living in, but the i5-9600K is many steps up beyond "SBC class".

The Raspberry Pi 5 results on Geekbench 6 are all over the place. A score between 500 to 900 in single core and a 2000 multi core score.

Radxa 4 is an SBC based around the N100 and it basically gets the same or slightly higher performance as the Raspberry Pi 5.

Meanwhile the i5-9600K gets a score of 1677 in single core, which is 83% of the performance of the entire Raspberry Pi 5 and gets a score of 6199 when using multiple cores, that's 3x the performance.

I'd call this at least "Laptop class" and you even admitted yourself back in 2025 that you're using a processor on that level.

Post reply on HN