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

371–380 of 397 posts

Re: RISC-V Is Sloooow

#371

Post by adgjlsfhk1 »

dzaima wrote: post #361
adgjlsfhk1 wrote: post #350

Earlier quoted context omitted.

> 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)

Indeed we shall hope heuristics update; but of course if no compilers emit it hardware has no reason to actually bother making fast misaligned ops, so it's primed for going wrong.

hardware devs traditionally have been pretty good at helping the compiler teams with things like this (because its a lot cheaper to improve the compiler than your chip).

Re: RISC-V Is Sloooow

#372

Post by userbinator »

snvzz wrote: post #358
userbinator wrote: post #354

Earlier quoted context omitted.

Decades of demoscene productions beg to differ. That just means compilers are awful, as they usually are.[1] x86 has far more optimisation opportunities than any RISC. [1] https://news.ycombinator.com/item?id=15720923

In absence of better data, we have to compare compiler output.

Here is your "better data": https://web.eece.maine.edu/~vweaver/papers/iccd09/ll_documen...

Re: RISC-V Is Sloooow

#373

Post by sitharus »

userbinator wrote: post #372
snvzz wrote: post #358

Earlier quoted context omitted.

In absence of better data, we have to compare compiler output.

Here is your "better data": https://web.eece.maine.edu/~vweaver/papers/iccd09/ll_documen...

If I recall my lectures, which were 20odd years ago now.

CISC ISAs were historically designed for humans writing assembly so they have single instructions with complex behaviour and consequently very high instruction density.

RISC was designed to eliminate the complex decoding logic and replace it with compiler logic, using higher throughput from the much reduced decoding logic (or in some cases no decoding at all) to offset the increased number of instructions. Also the transistors that were used for decoding could be used for additional ALUs to increase parallelism.

So RISC by its nature is more verbose.

Does the tradeoff still make sense? Depends who you ask.

Re: RISC-V Is Sloooow

#374

Post by brucehoult »

adgjlsfhk1 wrote: post #349
pseudohadamard wrote: post #347

Earlier quoted context omitted.

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.

Rubbish.

The "G" extension for everything you want to run shrink-wrapped binaries on a standard OS has been there since the May 7 2014 "User Level ISA, Version 2.0", which is before RISC-V started to be promoted outside of Berkeley e.g. at Hot Chips 26 in August 2014, and the first RISC-V workshop in January 2015 in Monterey.

The name "G" has morphed into now (along with the C extension) being called "RVA20", which led to "RVA22" and "RVA23", but the principle is unchanged.

"An integer base plus these four standard extensions (“IMAFD”) is given the abbreviation “G” and provides a general-purpose scalar instruction set. RV32G and RV64G are currently the default target of our compiler toolchains."

pp 4-5 in

https://www2.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-...

Re: RISC-V Is Sloooow

#375

Post by brucehoult »

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.

There is nothing "belated" about it.

The "G" extension for everything you want to run shrink-wrapped binaries on a standard OS has been there since the May 7 2014 "User Level ISA, Version 2.0", which is before RISC-V started to be promoted outside of Berkeley e.g. at Hot Chips 26 in August 2014, and the first RISC-V workshop in January 2015 in Monterey.

The name "G" has morphed into now (along with the C extension) being called "RVA20", which led to "RVA22" and "RVA23", but the principle is unchanged.

"An integer base plus these four standard extensions (“IMAFD”) is given the abbreviation “G” and provides a general-purpose scalar instruction set. RV32G and RV64G are currently the default target of our compiler toolchains."

pp 4-5 in

https://www2.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-...

Re: RISC-V Is Sloooow

#376

Post by BoredomIsFun »

sidewndr46 wrote: post #366
BoredomIsFun wrote: post #357

Earlier quoted context omitted.

> lots of commercial software is now compiled for newer x86 64 extensions. Almost all software I encountered - including Windows 10 and precompiled Debian 13 - needs only SSE4.2, essentially mid-2000s ISA. Intel produced until very recently (early 2020s) Celeron CPUs which did not even support AVX.

People focus on AVX entirely too much, it is stuff like POPCNT that matters more. Which as you pointed out, is part of SSE4.2

...which has been with us almost 20 years.

Re: RISC-V Is Sloooow

#377

Post by eru »

pjmlp wrote: post #222
rbanffy wrote: post #221

Earlier quoted context omitted.

If your hardware is new, you get the nicest extensions though. You just don’t use the bad parts in your code.

Sure, if you are developing software for the computer you own, instead of supporting everyone.

Re-compile?

Re: RISC-V Is Sloooow

#378

Post by snvzz »

userbinator wrote: post #372
snvzz wrote: post #358

Earlier quoted context omitted.

In absence of better data, we have to compare compiler output.

Here is your "better data": https://web.eece.maine.edu/~vweaver/papers/iccd09/ll_documen...

From 2017, it predates RISC-V first ratified spec.

Currently, RISC-V holds the crown of code density in both 64 and 32 bit.

On 32bit, thumb2 is a little behind. On 64bit, x86-64 is not even close, and ARMv8/v9 are even worse.

Re: RISC-V Is Sloooow

#379

Post by sidewndr46 »

BoredomIsFun wrote: post #376
sidewndr46 wrote: post #366

Earlier quoted context omitted.

People focus on AVX entirely too much, it is stuff like POPCNT that matters more. Which as you pointed out, is part of SSE4.2

...which has been with us almost 20 years.

Yet I still have regular conversations explaining "there is no way our customers are running on hardware that doesn't support this, where would they even be getting the hardware from, 2008?". I have a set of requirements in front of me requiring software to run on not only all Intel 64-bit chips, but also all Intel 32-bit chips.

Re: RISC-V Is Sloooow

#380

Post by Findecanor »

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

I don't agree with that comparison.

RyanAir is about exploiting consumers, with bait-and-switch and shitty terms and conditions.

RISC-V's modularity is about giving choice to hardware designers, so they can pick and choose just those features that their solution needs, and even allow for custom extensions.

RISC-V's modularity is for academia. 1) for education, where students learn/use/work on simple processors, 2) for research in new types of hardware and extensions, where ease of implementation or ease of creating a custom extension is important.

Post reply on HN