Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RISC-V Is Sloooow

marcin.juszkiewicz.com.pl

Post reply on HN
Print view View original

291–300 of 397 posts

Re: RISC-V Is Sloooow

#291

Post by fancyfredbot »

pseudohadamard wrote: post #243
newpavlov wrote: post #114

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…

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,…

So it's modular. This is normally considered a good thing. It means you don't have to pay for features you don't need.

The ISA is open so there's no greedy corporation trying to upsell you. I mean there's an implementation and die area cost for each extension but it's not being set at an artificial level by a monopolist.

Re: RISC-V Is Sloooow

#292

Post by 0x000xca0xfe »

torginus wrote: post #279
0x000xca0xfe wrote: post #260

Earlier quoted context omitted.

Unaligned load/store is crucial for zero-copy handling of mmaped data, network streams and all other kinds of space-optimized data structures. If the CPU doesn't do it software must make many tiny conditional copies which is bad for branch prediction. This sucks double when you have variable length vector operations... IMO fast unaligned memory accesses should have been mandatory without exceptions for all applicatio…

I think you can do this fairly efficiently with SSE for x86 - SSE/AVX has shift and shuffle. Encoding/Decoding packed data might even be faster this way. I'm not familiar with RISC-V but from what I've seen here, they're also trying to solve this similarly with vector or bit extraction instructions.

Yes because unaligned load is no problem with SSE/AVX. On my RISC-V OrangePi unaligned vector loads beyond byte-granularity fault so you have to take extra care.

AVX shift and shuffle is mostly limited to 128 bits unfortunately for historical reasons (even for 256-bit instructions) and hardware support for AVX512/AVX10 where they fixed that is a complete mess so it's hard to rely on when you care about backwards compatibility for consumer devices, e.g. in game development.

RISC-V vector has excellent mask/shuffle/permute but the performance in real silicon can be... questionable. See the timings for vrgather here for example: https://camel-cdr.github.io/rvv-bench-results/spacemit_a100/...

For working with packed data structures where fields are irregular/non-predictable/dependent on previous fields etc. unaligned load/store is a godsend. Last time I worked on a custom DB engine that used these patterns the generated x86 code was so much nicer than the one for our embedded ARM cores.

Re: RISC-V Is Sloooow

#293

Post by dzaima »

newpavlov wrote: post #254
pseudohadamard wrote: post #243

Earlier quoted context omitted.

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,…

>Multiply and divide And where it actually mattered they did not introduce a separate extension. Integer division is significantly more complex than multiplication, so it may make sense for low-end microcontrollers to implement in hardware only the latter.

There is Zmmul for multiplication-but-not-divide.

Re: RISC-V Is Sloooow

#294

Post by dzaima »

camel-cdr wrote: post #274
dzaima wrote: post #226

Earlier quoted context omitted.

The option to generate or not generate misaligned loads/stores does exist (-mno-strict-align / -mstrict-align). But of course that's a compile-time option, and of course the preferred state would be to have use of them on by default, but RVA23 doesn't sufficiently guarantee/encourage them not being unreasonably-slow, leaving native misaligned loads/stores still effectively-unusable (and off by default on clang/gcc on…

The cursed thing is that RVA23 does basically guarantees that `vle8.v` + `vmv.x.s` on misaligned addresses is fast.

Yeah, that is quite funky; and indeed gcc does that. Relatedly, super-annoying is that `vle64.v` & co could then also make use of that same hardware, but that's not guaranteed. (I suppose there could be awful hardware that does vle8.v via single-byte loads, which wouldn't translate to vle64.v?)

Re: RISC-V Is Sloooow

#295

Post by fidotron »

cpgxiii wrote: post #57
api wrote: post #12

Earlier quoted context omitted.

A pattern I've noticed for a very long time: A lot of times the path to the highest performing CPU seems to be to optimize for power first , then speed, then repeat. That's because power and heat are a major design constraint that limits speed. I first noticed this way back with the Pentium 4 "Netburst" architecture vs. the smaller x86 cores that became the ancestor of the Core architecture. Intel eventually ran into…

I think the story is a bit more complicated. Core succeeded precisely because Intel had both the low-power experience with Pentium-M and the high-power experience with Netburst. The P4 architecture told them a lot about what was and wasn't viable and at what complexity. When you look at the successor generations from Core, what you see are a lot of more complex P4-like features being re-added, but with the benefits o…

> In comparison, I think Arm is actually a very strong cautionary tale that focusing on power will not get you to performance.

Hugely underappreciated. Someone involved fully understood that "you don't get to the moon by climbing progressively taller trees".

The other two times Arm had great performance were the StrongArm, when it was implemented by DEC people off the Alpha project, and the initial ones, which were quite esoteric and unusually suited to the situation of the late 80s.

Re: RISC-V Is Sloooow

#296

Post by mort96 »

VorpalWay wrote: post #273
mort96 wrote: post #216

Earlier quoted context omitted.

Yocto manages it thanks to the tireless effort of a community of people maintaining patches and unholy hacks for a ton of software to make it cross compilable. And they have nowhere near the amount of recipes that Fedora has.

This is true, but the hacks are mostly in the C and C++ recipes as I understand it. Something like Rust or especially Go or Zig is far easier to cross compile. I personally found cross compiling Rust easy, as long as you don't have C dependencies. If you have C dependencies it becomes way harder. This suggests that spending time to upstream cross compilation fixes would be worth it for everyone, and probably even in…

I wonder if Fedora packages any C and C++ software?

Re: RISC-V Is Sloooow

#297

Post by jacquesm »

rwmj wrote: post #262
jacquesm wrote: post #124

Earlier quoted context omitted.

Nice board but very low on max RAM.

The Milk-V Titan ( https://milkv.io/titan ) can take up to 64GB which is fine considering the number of cores and the cost of RAM. If you needed and could afford more RAM you'd be better off distributing the work across more than one board.

I simply want to replace my desktop with open hardware. That board would be fine, thank you for the pointer.

Re: RISC-V Is Sloooow

#298

Post by Joker_vD »

sehugg wrote: post #280
cmovq wrote: post #168

Earlier quoted context omitted.

But RISC-V is a _new_ ISA. Why did we start out with the wrong design that now needs a bunch of extensions? RISC-V should have taken the learnings from x86 and ARM but instead they seem to be committing the same mistakes.

It's not the wrong design; RISC-V is designed around extensions, and they left room in the instruction encoding for them. They don't have a 800-lb gorilla like Intel shoving the ISA down customers' throats (Canonical is the closet thing) so there is some debate on which combination of extensions are needed for desktop apps.

> They don't have a 800-lb gorilla like Intel shoving the ISA down customers' throats

Nobody really forces you to use x64 if you don't like it, just as nobody forced you to use Itanium — which Intel famously failed to "shove down the customers' throats" btw.

Re: RISC-V Is Sloooow

#299

Post by throwa356262 »

orangeboats wrote: post #266
throwa356262 wrote: post #258

Earlier quoted context omitted.

What kind or ancient arm hardware are they using here? On a related note, SoC companies needs to get their act together and start using the latest arm cores. Even the mid range cores of 1-2 years ago show a huge leap in performance: https://sbc.compare/56-raspberry-pi-500-plus-16gb/101-radxa-...

>What kind or ancient arm hardware are they using here? I think that's the point being made here. ARM in the 2000s was not known to be fast, now it is. RISC-V being slow isn't an inherent characteristic of the ISA, it only tells you about the quality of its implementations. And said implementations will only improve if corporations are throwing capitals at it (see: Apple, Qualcomm, etc.)

I think standard Arm cores are already plenty fast, the issue is the SoC vendors are still using cortex-A57 from 2015 instead of the new designs.

Re: RISC-V Is Sloooow

#300

Post by rwmj »

jacquesm wrote: post #297
rwmj wrote: post #262

Earlier quoted context omitted.

The Milk-V Titan ( https://milkv.io/titan ) can take up to 64GB which is fine considering the number of cores and the cost of RAM. If you needed and could afford more RAM you'd be better off distributing the work across more than one board.

I simply want to replace my desktop with open hardware. That board would be fine, thank you for the pointer.

Unfortunately they found a bug and had to redesign the boards. I've had one of these on pre-order since last year. Latest is I think they're intending to ship them next month (April).

The SpacemiT K3 (https://www.spacemit.com/products/keystone/k3 https://www.cnx-software.com/2026/01/23/spacemit-k3-16-core-...) is the one everyone is waiting for. We have one in house (as usual, cannot discuss benchmarks, but it's good). Unfortunately I don't think there is anyone reputable offering pre-orders yet.

Post reply on HN