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

341–350 of 397 posts

Re: RISC-V Is Sloooow

#341

Post by brucehoult »

kashyapc wrote: post #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 r…

> VisionFive 2

It's a good solid reliable board, but over three years old at this point (in a fast-moving industry) and the maximum 8 GB RAM is quite challenging for some builds.

Binutils is fine, but on recent versions of gcc it wants to link four binaries at the same time, with each link using 4 GB RAM. I've found this fails on my 16 GB P550 Megrez with swap disabled, but works quickly and uses maybe 50 or 100 MB of swap if I enable it.

On the VisionFive 2 you'd need to use `-j1` (or `-j2` with swap enabled) which will nearly double or quadruple the build time.

Or use a better linker than `ld`.

At least the LLVM build system lets you set the number of parallel link jobs separately to the number of C/C++ jobs.

Re: RISC-V Is Sloooow

#342

Post by brucehoult »

veltas wrote: post #218
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.

Relatively new, we're about 16 years down the road.

16 years from the START of getting an idea "why don't we make a new ISA?".

Less than 7 years from ratification of the initial RV{32,64}GC spec.

Less than 5 years from the first mass-produced roughly original Raspberry Pi level $100 SBC: AWOL Nezha, shipped June 2021.

Re: RISC-V Is Sloooow

#343

Post by brucehoult »

dzaima wrote: post #264
IshKebab wrote: post #255

Earlier quoted context omitted.

> if general-purpose HW with horribly-slow misaligned loads/stores came out from them How is that different for RISC-V? > I think it's a fairly reasonable expectation that all supported hardware instructions/behaviors (at least non-deprecated ones) are not slower than a software implementation I agree! So just use misaligned loads if Zicclsm is supported. As you observed there's a feedback loop between what compilers…

> How is that different for RISC-V? RISC-V hardware with slow misaligned mem ops does exist to non-insignificant extent, and it seems not enough people have laughed at them, and instead compilers did just surrender and default to not using them. > As you observed there's a feedback loop between what compilers output and what gets optimised in hardware. Well, that loop needs to start somewhere, and it has already star…

> RISC-V hardware with slow misaligned mem ops does exist to non-insignificant extent

Only U74 and P550, old RV64GC CPUs.

SiFive's RVA23 cores have fast misaligned accesses, as do all THead and SpacemiT cores.

I can't imagine that all the Tenstorrent and Ventana and so forth people doing massively OoO 8-wide cores won't also have fast misaligned accesses.

As a previous poster said: if you're targeting RVA23 then just assume misaligned is fast and if someone one day makes one that isn't then sucks to be them.

Re: RISC-V Is Sloooow

#344

Post by dzaima »

brucehoult wrote: post #343
dzaima wrote: post #264

Earlier quoted context omitted.

> How is that different for RISC-V? RISC-V hardware with slow misaligned mem ops does exist to non-insignificant extent, and it seems not enough people have laughed at them, and instead compilers did just surrender and default to not using them. > As you observed there's a feedback loop between what compilers output and what gets optimised in hardware. Well, that loop needs to start somewhere, and it has already star…

> RISC-V hardware with slow misaligned mem ops does exist to non-insignificant extent Only U74 and P550, old RV64GC CPUs. SiFive's RVA23 cores have fast misaligned accesses, as do all THead and SpacemiT cores. I can't imagine that all the Tenstorrent and Ventana and so forth people doing massively OoO 8-wide cores won't also have fast misaligned accesses. As a previous poster said: if you're targeting RVA23 then just…

P550 is, like, what, only a year old? I suppose there has been some laughing at it at least.

Also Kendryte K230 / C908, but only on vector mem ops, which adds a whole another mess onto this.

I'd hope all the massive OoO will have fast misaligned mem ops, anything else would immediately cause infinite pain for decades.

But of course there'll be plenty of RVA23 hardware that's much smaller eventually too, once it becomes a general expectation instead of "cool thing for the very-top-end to have".

I do agree that it'd be reasonable to just assume fast misaligned ops, but for whatever reason gcc and clang just don't, and that's what we have for defaults.

Re: RISC-V Is Sloooow

#345

Post by userbinator »

rwmj wrote: post #257
userbinator wrote: post #186

Earlier quoted context omitted.

Contrast with x86: add eax, ecx jo overflow

Neither x86-64 nor RISC-V is implemented by running each single instruction. They both recognize patterns in the code and translate those into micro-ops. On high performance chips like Rivos's (now Meta's) I doubt there'd be any difference in the amount of work done. Code size is a benefit for x86-64 however - no one is arguing that - but you have to trade that against the difficulty of instruction decoding.

I thought the main distinction of RISC-V (and MIPS before it, along with RISCs in general) is that the instructions are themselves of equivalent complexity (or lack thereof) as x86 uops. E.g x86 can add a register to memory, which splits into 3 load / add / store uops, but a RISC would execute those 3 instructions directly.

Re: RISC-V Is Sloooow

#346

Post by userbinator »

panick21_ wrote: post #302
MarsIronPI wrote: post #286

Earlier quoted context omitted.

I don't know why there aren't independent X86-64 manufacturers. Patents on the extensions maybe? But as I understand copyright, APIs can't be copyrighted so it's not that.

The original ARM 32 stuff is clearly out of patents and is not being copied. And it doesn't require new extensions to be commercially viable.

and is not being copied

Are you sure, especially considering China?

I doubt there is any legal barrier, because there are a few existing projects with x86 cores on an FPGA, as well as some SoCs. Here's a 486: https://opencores.org/projects/ao486

Re: RISC-V Is Sloooow

#347

Post by pseudohadamard »

snvzz wrote: post #322
Symmetry wrote: post #310

Earlier quoted context omitted.

It's a good thing in many cases but not if you're going to be running applications distributed as binaries. Maybe if we go the Gentoo route of everybody always recompiling everything for their own system?

Then you stick to RVA23, which is comparable to ARMv9 and x86-64v4.

RVA23 is, finally, the belated admission that maybe we shouldn't have everything as optional extras. Hopefully it'll take off, I can't imagine what sort of a headache it is for maintainers of repos who have to track a dozen different variants of binaries depending on which flavour of RISC-V the apt-get is coming from.

Re: RISC-V Is Sloooow

#348

Post by pseudohadamard »

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.

There's a good chance you're actually paying more for the features you don't need. Preparing an EUV mask set costs something like 30 million dollars (that figure may be out of date, i.e. it could be more now). So instead of a single mask set with everything on the device, whether you need it or not, you're paying $30 million for each special-snowflake variant. This is why vendors do a one-size-fits-all version of many of their products and then disable the extra functionality for the cheaper market segments, because it's much, much cheaper than making separate reduced-functionality devices.

Re: RISC-V Is Sloooow

#349

Post by adgjlsfhk1 »

pseudohadamard wrote: post #347
snvzz wrote: post #322

Earlier quoted context omitted.

Then you stick to RVA23, which is comparable to ARMv9 and x86-64v4.

RVA23 is, finally, the belated admission that maybe we shouldn't have everything as optional extras. Hopefully it'll take off, I can't imagine what sort of a headache it is for maintainers of repos who have to track a dozen different variants of binaries depending on which flavour of RISC-V the apt-get is coming from.

RVA23 (and RVA20 before it) aren't an admission that Risc-V got it wrong. It's a necessary step to make Risc-V competetive in the desktop space as opposed to micro-controllers where the flexibility is hugely valuable.

Re: RISC-V Is Sloooow

#350

Post by adgjlsfhk1 »

dzaima wrote: post #344
brucehoult wrote: post #343

Earlier quoted context omitted.

> RISC-V hardware with slow misaligned mem ops does exist to non-insignificant extent Only U74 and P550, old RV64GC CPUs. SiFive's RVA23 cores have fast misaligned accesses, as do all THead and SpacemiT cores. I can't imagine that all the Tenstorrent and Ventana and so forth people doing massively OoO 8-wide cores won't also have fast misaligned accesses. As a previous poster said: if you're targeting RVA23 then just…

P550 is, like, what, only a year old? I suppose there has been some laughing at it at least. Also Kendryte K230 / C908, but only on vector mem ops, which adds a whole another mess onto this. I'd hope all the massive OoO will have fast misaligned mem ops, anything else would immediately cause infinite pain for decades. But of course there'll be plenty of RVA23 hardware that's much smaller eventually too, once it becom…

> I do agree that it'd be reasonable to just assume fast misaligned ops, but for whatever reason gcc and clang just don't, and that's what we have for defaults.

This very much has a "for now" on it. Once there is actually widespread hardware with the feature, I would be very surprised if the compilers don't update their heuristics (at least for RVA23 chips)

Post reply on HN