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

141–150 of 397 posts

Re: RISC-V Is Sloooow

#141

Post by burntoutgray »

adrian_b wrote: post #121
classichasclass wrote: post #80

Earlier quoted context omitted.

As a counterexample, I point to another relatively boring RISC, PA-RISC. It took off not (just) because the architecture was straightforward, but because HP poured cash into making it quick, and PA-RISC continued to be a very competitive architecture until the mass insanity of Itanic arrived. I don't see RISC-V vendors making that level of investment, either because they won't (selling to cheap markets) or can't (no…

I would not call PA-RISC boring. Already at launch there was no doubt that it is a better ISA than SPARC or MIPS, and later it was improved. At the time when PA-RISC 2.0 was replaced by Itanium it was not at all clear which of the 2 ISAs is better. The later failures to design high-performance Itanium CPUs make plausible that if HP would have kept PA-RISC 2.0 they might have had more competitive CPUs than with Itaniu…

ISAs fail to gain traction when the sufficiently smart compilers don't eventuate.

The x86-64 is a dog's breakfast of features. But due to its widespread use, compiler writers make the effort to create compilers that optimize for its quirks.

Itanium hardware designers were expecting the compiler writers to cater for its unique design. Intel is a semi company. As good as some of their compilers are, internally they invested more in their biggest seller and the Itanium never got the level of support that was anticipated at the outset.

Re: RISC-V Is Sloooow

#142

Post by pezezin »

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.

The 32-bit ARM architecture included a barrel shifter as part of its basic design, as in every instruction had a shift field.

If a CPU built in 1985 with a grand total of 26 000 transistors could afford it, I am pretty sure that anything built in this century could afford it too.

Re: RISC-V Is Sloooow

#143

Post by classichasclass »

adrian_b wrote: post #121
classichasclass wrote: post #80

Earlier quoted context omitted.

As a counterexample, I point to another relatively boring RISC, PA-RISC. It took off not (just) because the architecture was straightforward, but because HP poured cash into making it quick, and PA-RISC continued to be a very competitive architecture until the mass insanity of Itanic arrived. I don't see RISC-V vendors making that level of investment, either because they won't (selling to cheap markets) or can't (no…

I would not call PA-RISC boring. Already at launch there was no doubt that it is a better ISA than SPARC or MIPS, and later it was improved. At the time when PA-RISC 2.0 was replaced by Itanium it was not at all clear which of the 2 ISAs is better. The later failures to design high-performance Itanium CPUs make plausible that if HP would have kept PA-RISC 2.0 they might have had more competitive CPUs than with Itaniu…

I mean "boring" in the sense that its ISA was relatively straightforward, no performance-entangling kinks like delay slots, a good set of typical non-windowed GPRs, no wild or exotic operations. And POWER/PowerPC and PA-RISC weren't a lot later than SPARC or MIPS, either.

Re: RISC-V Is Sloooow

#144

Post by HerbManic »

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.

I love the optimisim, but I do thimk your time line is little quick. It will be more like 10 years than 4.

Re: RISC-V Is Sloooow

#145

Post by burntoutgray »

kpil wrote: post #69
gt0 wrote: post #10

Earlier quoted context omitted.

I was really surprised by the s390x performance, but I also don't really understand why there are build time listed by architecture, not the actual processors.

What's fast on Z platforms is typically IO rather than raw CPU - the platform can push a lot of parallell data. This is typically the bottleneck when compiling. The cores are in my experience moderately fast at most. Note that there are a lot of licencing options and I think some are speed-capped - but I don't think that applies to IFL - a standard CPU licence-restricted to only run linux.

I thought I read somewhere that Z CPUs run at 5GHz ??

Re: RISC-V Is Sloooow

#146

Post by [deleted] »

sltkr wrote: post #61

Are you sure you are comparing apples with apples here? The fact that i686 is 14% faster than x86_64 is a little suspicious, because usually the same software runs _faster_ on x86_64 (despite the increased memory use) thanks to a larger register set, an optimized ABI, and more vector instructions. Of course, if you are compiling an i686 binary on i686, and an x86_64 binary on x86_64, then the compilers aren't really…

[deleted]

Re: RISC-V Is Sloooow

#147

Post by saghm »

If I'm reading their chart right, they have barely half as much memory for their RISC-V machine compared to any of the others? I don't know enough to know whether it's actually bottlenecked by memory, but it's a bit odd to claim it's slower, give those numbers, and not say anything about it. I'd hope they ruled that out as the source of the discrepancy, but it's hard to tell without confirmation.

Re: RISC-V Is Sloooow

#148

Post by mkj »

Does that page even say which RISC-V CPUs are being used that are slow? I couldn't see it, which seems a bit of pointless complaining.

Re: RISC-V Is Sloooow

#149

Post by AceJohnny2 »

There was a Mastodon post some time back (~1y?) where someone realized that the fastest RISC-V hardware they could get was still slower than running it on QEMU.

That's not how it usually works :\

RISC-V is certainly spreading across niches, but performant computing is not one of them.

Edit: lol the author mentions the same! Perhaps they were the source of the original Mastodon post I'm thinking of.

Re: RISC-V Is Sloooow

#150

Post by ori_b »

edflsafoiewq wrote: post #111
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…

What about page size?

It's 4k on x86 as well. Doesn't seem to hurt so bad -- at least, not enough to explain the risc-v performance gap.
Post reply on HN