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

111–120 of 397 posts

Re: RISC-V Is Sloooow

#111

Post by edflsafoiewq »

weebull wrote: post #98
newpavlov wrote: post #44

Earlier quoted context omitted.

In some cases RISC-V ISA spec is definitely the one to blame: 1) https://github.com/llvm/llvm-project/issues/150263 2) https://github.com/llvm/llvm-project/issues/141488 Another example is hard-coded 4 KiB page size which effectively kneecaps ISA when compared against ARM.

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…

What about page size?

Re: RISC-V Is Sloooow

#112

Post by adgjlsfhk1 »

kevin_thibedeau wrote: post #92
jacquesm wrote: post #73

Earlier quoted context omitted.

Bit manipulation instructions are part and parcel of any curriculum that teaches CPU architecture. They are the basic building blocks for many more complex instructions. https://five-embeddev.com/riscv-bitmanip/1.0.0/bitmanip.html I can see quite a few items on that list that imnsho should have been included in the core and for the life of me I can't see the rationale behind leaving them out. Even the most basic 8 bi…

32-bit barrel shifters consume significant area and RISC-V was developed to support resource constrained low cost embedded hardware in a minimal ISA implementation.

IIUC this is a lot less true in the modern era. Even with 24nm transistors (the cheapest transistor last time I checked), modern microcontrollers have a fairly big transistor budget for the core (since 80+% of the transistors are going to sram anyway).

Re: RISC-V Is Sloooow

#113

Post by LeFantome »

weebull wrote: post #98
newpavlov wrote: post #44

Earlier quoted context omitted.

In some cases RISC-V ISA spec is definitely the one to blame: 1) https://github.com/llvm/llvm-project/issues/150263 2) https://github.com/llvm/llvm-project/issues/141488 Another example is hard-coded 4 KiB page size which effectively kneecaps ISA when compared against ARM.

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…

Ubuntu being RVA23 is looking smarter and smarter.

The RISC-V ecosystem being handicapped by backwards compatibility does not make sense at this point.

Every new RISC-V board is going to be RVA23 capable. Now is the time to draw a line in the sand.

Re: RISC-V Is Sloooow

#114

Post by newpavlov »

weebull wrote: post #98
newpavlov wrote: post #44

Earlier quoted context omitted.

In some cases RISC-V ISA spec is definitely the one to blame: 1) https://github.com/llvm/llvm-project/issues/150263 2) https://github.com/llvm/llvm-project/issues/141488 Another example is hard-coded 4 KiB page size which effectively kneecaps ISA when compared against ARM.

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…

>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 is likely to become heavily entrenched as "the default").

IMO the spec authors should've mandated that the base load/store instructions work only with aligned pointers and introduced misaligned instructions in a separate early extension. (After all, passing a misaligned pointer where your code does not expect it is a correctness issue.) But I would've been fine as well if they mandated that misaligned pointers should be always accepted. Instead we have to deal the terrible middle ground.

>atomic memory operations are made mandatory in Ziccamoa

In other words, forget about potential performance advantages of load-link/store-conditional instructions. `compare_exchange` and `compare_exchange_weak` will always compile into the same instructions.

And I guess you are fine with the page size part. I know there are huge-page-like proposals, but they do not resolve the fundamental issue.

I have other minor performance-related nits such `seed` CSR being allowed to produce poor quality entropy which means that we have bring a whole CSPRNG if we want to generate a cryptographic key or nonce on a low-powered micro-controller.

By no means I consider myself a RISC-V expert, if anything my familiarity with the ISA as a systems language programmer is quite shallow, but the number of accumulated disappointments even from such shallow familiarity has cooled my enthusiasm for RISC-V quite significantly.

Re: RISC-V Is Sloooow

#115

Post by luyu_wu »

classichasclass wrote: post #88
yogthos wrote: post #82

there are projects for making high performance RISC-V chips like this one https://github.com/OpenXiangShan/XiangShan

OK, I'll bite. If this is a truly competitive core - I don't claim enough personal expertise to judge - does anyone fab and sell it? There should be a business case if it is.

If I remember correctly,it was taped out by some company as some embedded core in a GPU?

I guess that may be the true use case for 'Open-Source' cores.

That being said, the advertised SPEC2007 scores are close to a M1 in IPC.

Re: RISC-V Is Sloooow

#116

Post by [deleted] »

weebull wrote: post #98
newpavlov wrote: post #44

Earlier quoted context omitted.

In some cases RISC-V ISA spec is definitely the one to blame: 1) https://github.com/llvm/llvm-project/issues/150263 2) https://github.com/llvm/llvm-project/issues/141488 Another example is hard-coded 4 KiB page size which effectively kneecaps ISA when compared against ARM.

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…

[deleted]

Re: RISC-V Is Sloooow

#117

Post by kllrnohj »

LeFantome wrote: post #106
kllrnohj wrote: post #52

Earlier quoted context omitted.

> Imagine trying to compile this on ARM 10 years ago Cortex A57 is 14 years old and is significantly faster than the 9 year old Cortex A55 these RISC-V cores are being compared against. So yes it's many years behind. Many, many years.

SpacemiT K3 is on par with Rockchip RK3588. So, about 4 years behind ARM. Tenstorrent Atlantis (first Ascalon silicon) should ship in Q2/Q3 and be twice as fast. About as fast as Ryzen5. So, about 5 years behind AMD. But even the K3 has faster AI than Apple Silicon or Qualcomm X Elite. Current trend-lines suggest ARM64 and RISC-V performance parity before 2030.

> SpacemiT K3 is on par with Rockchip RK3588. So, about 4 years behind ARM.

That'd be ~7 years behind, not 4. Cortex A76 came out in late 2018. Also what benchmarks are you looking at?

> Tenstorrent Atlantis (first Ascalon silicon) should ship in Q2/Q3 and be twice as fast. About as fast as Ryzen5. So, about 5 years behind AMD.

Which Ryzen 5? The first Ryzen 5 came out in 2017, which was a lot more than 5 years ago.

> But even the K3 has faster AI than Apple Silicon or Qualcomm X Elite.

Which isn't RISC-V. Might as well brag about a RISC-V CPU with an RTX 5090 being faster at CUDA than a Nintendo Switch. That's a coprocessor that has nothing to do with the ISA or CPU core.

> Current trend-lines suggest ARM64 and RISC-V performance parity before 2030.

L. O. fucking. L. That's not how this works. That's not how any of this works.

Re: RISC-V Is Sloooow

#118

Post by twoodfin »

gt0 wrote: post #45
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 don't think anybody suggests Oracle couldn't make faster SPARC processors, it's just that development of SPARC ended almost 10 years ago. At the time SPARC was abandoned, it was very competitive.

In single-threaded performance? That’s not how I remember it: Sun was pushing parallel throughput over everything else, with designs like the T-Series & Rock.

Re: RISC-V Is Sloooow

#119

Post by LeFantome »

rwmj wrote: post #34
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…

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?

Re: RISC-V Is Sloooow

#120

Post by statusfailed »

jacquesm wrote: post #86
rwmj wrote: post #75

Earlier quoted context omitted.

This is the reason behind the profiles like RVA23 which include bitmanip, vector and a large number of other extensions. Real chips coming very soon will all be RVA23.

Neat. I can't wait to get my hands on a devboard.

The Milk-V Jupiter 2 (coming out in April) is RV23 too
Post reply on HN