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

311–320 of 397 posts

Re: RISC-V Is Sloooow

#311

Post by dzaima »

newpavlov wrote: post #306
dzaima wrote: post #270

Earlier quoted context omitted.

Well, we don't necessarily have to wait for Oilsm; software that wants to could just choose to be opinionated and run massively-worse on suboptimal hardware. And, of course, once Oilsm hardware becomes the standard, it'd be fine to recompile RVA23-targeting software to it too. > RISC-V could've easily avoided all this mess by properly mandating misaligned pointer handling as part of the I extension. Rather hard to ma…

I am not saying that RISC-V should mandate performance. If anything, we wouldn't had the problem with Zicclsm if they did not bother with the stupid performance note. I would be fine with any of the following 3 approaches: 1) Mandate that store/loads do not support misaligned pointers and introduce separate misaligned instructions (good for correctness, so its my personal preference). 2) Mandate that store/loads alwa…

2 is basically infeasible with RISC-V being intended for a wide range of use-cases. 1 might be ok but introduces a bunch of opcode space waste.

Indeed extremely sad that Zicclsm wasn't a thing in the spec, from the very start (never mind that even now it only lives in the profiles spec); going through the git history, seems that the text around misaligned handling optionality goes all the way back to the very start of the riscv/riscv-isa-manual repo, before `Z*` extensions existed at all.

More broadly, it's rather sad that there aren't similar extensions for other forms of optional behavior (thing that was recently brought up is RVV vsetvli with e.g. `e64,mf2`, useful for massive-VLEN>DLEN hardware).

Re: RISC-V Is Sloooow

#312

Post by NetMageSCW »

fancyfredbot wrote: post #291
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,…

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.

But that means a port of Linux can’t be to RISC-V, it has to be to a specific implementation of RISC-V, or if sufficient (which seems still debatable) to a specific common RISC-V profile.

Re: RISC-V Is Sloooow

#314

Post by craftkiller »

NetMageSCW wrote: post #308
LeFantome wrote: post #192

Earlier quoted context omitted.

First, x86-64 also has “extensions” such as avx, avx2, and avx512. Not all “x86-64” CPUs support the same ones. And you get things like svm on AMD and avx on Intel. Remember 3DNow? X86-64 also has “profiles” which tell you what extensions should be available. There is x86-64v1 and x86-64v4 with v2 and v3 in the middle. RVA23 offers a very similar feature-set to x86-64v4. You do not end up with a mess of extensions. Y…

>Anybody can build a RISC-V chip. You do not need permission. No, anybody can’t build a RISC-V chip. That’s the same mistake OSS proponents make. Just because something is open source doesn’t mean bugs will be found. And just because bugs are found doesn’t mean they will be fixed. The vast majority of people can’t do either. The number of people who can design a chip implementation of the RISC-V ISA is much, much sma…

I think it was clear that they were saying anybody is permitted to build a RISC-V chip, not that anybody has the skills.

> The number of people who can design a chip implementation

Thankfully you don't have to start from scratch. There are loads of open source RISC-V chip implementations you can start from.

> get or own a FAB to manufacture the chips

There is always FPGAs and also this:

https://fossi-foundation.org/blog/2020-06-30-skywater-pdk

Re: RISC-V Is Sloooow

#315

Post by prompt_artisan »

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

Yes, adding instructions to your ISA has a cost

Re: RISC-V Is Sloooow

#316

Post by craftkiller »

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

Then x86_64 is the cable television service of processors. "Oh, you want channel 5? Then you have to buy this bundle with 40 other channels you will never watch, including 7 channels in languages you do not speak."

Re: RISC-V Is Sloooow

#317

Post by NetMageSCW »

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 how much of Fedora is written in Rust?

Re: RISC-V Is Sloooow

#318

Post by NetMageSCW »

hackerInnen wrote: post #28
IshKebab wrote: post #15

Yeah it's a few years behind ARM, but not that many. Imagine trying to compile this on ARM 10 years ago. It would be similarly painful.

This. While I doubt that there will be a good (whatever that means) desktop risc-v CPU anytime soon, I do think that it will eventually catch up in embedded systems and special applications. Maybe even high core count servers. It just takes time, people who believe in it and tons of money. Will see where the journey goes, but I am a big risc-v believer

Why? They have yet to show anything to believe in except perhaps the embedded space.

Re: RISC-V Is Sloooow

#319

Post by newpavlov »

dzaima wrote: post #311
newpavlov wrote: post #306

Earlier quoted context omitted.

I am not saying that RISC-V should mandate performance. If anything, we wouldn't had the problem with Zicclsm if they did not bother with the stupid performance note. I would be fine with any of the following 3 approaches: 1) Mandate that store/loads do not support misaligned pointers and introduce separate misaligned instructions (good for correctness, so its my personal preference). 2) Mandate that store/loads alwa…

2 is basically infeasible with RISC-V being intended for a wide range of use-cases. 1 might be ok but introduces a bunch of opcode space waste. Indeed extremely sad that Zicclsm wasn't a thing in the spec, from the very start (never mind that even now it only lives in the profiles spec); going through the git history, seems that the text around misaligned handling optionality goes all the way back to the very start o…

>1 might be ok but introduces a bunch of opcode space waste.

I wouldn't call it "waste". Moreover, it's fine for misaligned instructions to use a wider encoding or be less rich than their aligned counterparts. For example, they may not have the immediate offset or have a shorter one. One fun potential possibility is to encode the misaligned variant into aligned instructions using the immediate offset with all bits set to one, as a side effect it also would make the offset fully symmetric.

Re: RISC-V Is Sloooow

#320

Post by kbolino »

adgjlsfhk1 wrote: post #133
nine_k wrote: post #123

Earlier quoted context omitted.

Fewer than two is exactly one instruction. Which?

dammmit I meant https://godbolt.org/z/4WxeW58Pc sltu or snez for add/multiply respectively.

This result is misleading.

First, the code claims to be returning "unsigned long" from each of these functions, but the value will only ever be 0 or 1 (see [1]). The code is actually throwing away the result and just returning whether overflow occurred. If we take unsigned long *c as another argument to the function, so that we actually keep the result, we end up having to issue an extra instruction for multiplication (see [2]; I'm ignoring the sd instruction since it is simply there to dereference the *c pointer and wouldn't exist if the function got inlined).

Second, this is just unsigned overflow detection. If we do signed overflow detection, now we're up to 5 instructions for add and mul (see [3]). Considering that this is the bigger challenge, it compares quite unfavorably to architectures where this is just 2 instructions: the operation itself and a branch against a condition flag.

[1]: https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins...

[2]: https://godbolt.org/z/7rWWv57nx

[3]: https://godbolt.org/z/PnzKaz4x5

Post reply on HN