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

271–280 of 397 posts

Re: RISC-V Is Sloooow

#271

Post by izacus »

rbanffy wrote: post #2

Don't blame the ISA - blame the silicon implementations AND the software with no architecture-specific optimisations. RISC-V will get there, eventually. I remember that ARM started as a speed demon with conscious power consumption, then was surpassed by x86s and PPCs on desktops and moved to embedded, where it shone by being very frugal with power, only to now be leaving the embedded space with implementations optimi…

If you make a spec that the wider industry cannot effectively implement into quality products, it's the spec that's wrong. And that's true for anything - whether it's RISC-V, ipv6, Matter, USB-C and so on.

That's what makes writing specs hard - you need people who understand implementation challenges at the table, not dreaming architects and academics.

Re: RISC-V Is Sloooow

#272

Post by haerwu »

I updated blog post after reading comments from Matrix/Slack/Phoronix/HN/Lobster/etc. places.

- mentioned which board had 143 minutes, added info about time on Milk-V Megrez board

- added section 'what we need hw-wise for being in fedora'

- added link to my desktop post to point that it is aarch64, not x86-64

- wording around qemu to show that I use it locally only

Re: RISC-V Is Sloooow

#273

Post by VorpalWay »

mort96 wrote: post #216
VorpalWay wrote: post #208

Earlier quoted context omitted.

Yocto, which we use at work, manages it just fine to build a whole embedded Linux distro. So I don't see why Fedora couldn't make it work if they wanted. You could even scp over the test suites to run that on native systems if you wanted.

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 the C world, 20% of the packages need 80% of the effort.

Re: RISC-V Is Sloooow

#274

Post by camel-cdr »

dzaima wrote: post #226
IshKebab wrote: post #210

Earlier quoted context omitted.

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…

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.

Re: RISC-V Is Sloooow

#275

Post by camel-cdr »

IshKebab wrote: post #231
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…

> RVA23 doesn't guatantee them not being unreasonably-slow Right but it doesn't guarantee that anything is unreasonably slow does it? I am free to make an RVA23 compliant CPU with a div instruction that takes 10k cycles. Does that mean LLVM won't output div? At some point you're left with either -mcpu= and falling back to reasonable assumptions about the actual hardware landscape. Do ARM or x86 make any guarantees ab…

Exactly, I 100% agree, and IMO toolchains should default to assuming fast misaligned load/store for RISC-V.

However, the spec has the explicit note:

> Even though mandated, misaligned loads and stores might execute extremely slowly. Standard software distributions should assume their existence only for correctness, not for performance.

Which was a mistake. As you said any instruction could be arbitrarily slow, and in other aspects where performance recommendations could actually be useful RVI usually says "we can't mandate implementation".

Re: RISC-V Is Sloooow

#277

Post by haerwu »

LeFantome wrote: post #119
rwmj wrote: post #34

Earlier quoted context omitted.

Marcin is working with us on RISC-V enablement for Fedora and RHEL, he's well aware of the problem with current implementations. We're hopeful that this'll be pretty much resolved by the end of the year.

If he expects it to be resolved by the end of the year (and I agree it likely will be), why is he writing a post like this? Is this because Fedora 44 is going to beta?

Because I can.

Is it good enough answer?

Re: RISC-V Is Sloooow

#278

Post by fidotron »

lizknope wrote: post #94
fidotron wrote: post #40

Earlier quoted context omitted.

> RISC-V will get there, eventually. Not trolling: I legitimately don't see why this is assumed to be true. It is one of those things that is true only once it has been achieved. Otherwise we would be able to create super high performance Sparc or SuperH processors, and we don't. As you note, Arm once was fast, then slow, then fast. RISC-V has never actually been fast. It has enabled surprisingly good implementations…

I think the bigger question is does RISC-V need to be fast? Who wants to make it fast? I'm a chip designer and I see people using RISC-V as small processor cores for things like PCIE link training or various bookkeeping tasks. These don't need to be fast, they need to be small and low power which means they will be relatively slow. Most people on tech review sites only care about desktop / laptop / server performance…

> I think the bigger question is does RISC-V need to be fast? Who wants to make it fast?

Honestly, the initial reaction is it sounds like cope, and I know this because I've been saying it for ages to angry reactions. RISC-V looks for all the world like it is designed for competing with the 32 bit Arm ecosystem but that the designers didn't, and still don't, understand what 64 bit Arm is about.

Secondly, it's been necessary to claim such things are forever on the way in order to maintain hype and get software support. Without it you wouldn't see nearly so much Linux buildchain work. (See the open source SuperH implementations for what happens if you admit you don't go for high performance).

Finally though, as process nodes get smaller you can afford to put much more complex blocks in the same area, which can then burst through a series of operations and power off again, many times a second. (Edit to add: of course you know that, but it's still counter intuitive the extent to which it changes things over time. People have things like floating point support in places that not too long ago would have been completely minimalist, and there are some really extreme examples around).

> I'll add that there are companies that COULD make a fast RISC-V implementation.

Again, there is no proof of this until it actually happens. When Qualcomm were trying they wanted to change the spec of RISC-V, and I strongly suspect that is actually necessary.

Re: RISC-V Is Sloooow

#279

Post by torginus »

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

Earlier quoted context omitted.

Yes, unaligned loads/stores are a niche feature that has huge implications in processor design - loads across cache-lines with different residency, pages that fault etc. This is the classic conundrum of legacy system redesign - if customers keep demanding every feature of the old system be present, and work the exact same then the new system will take on the baggage it was designed to get rid of. The new implementati…

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.

Re: RISC-V Is Sloooow

#280

Post by sehugg »

cmovq wrote: post #168
weebull wrote: 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…

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.
Post reply on HN