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

231–240 of 397 posts

Re: RISC-V Is Sloooow

#231

Post by IshKebab »

dzaima wrote: post #226
IshKebab wrote: post #210

Earlier quoted context omitted.

I think having separate unaligned load/store instructions would be a much worse design, not least because they use a lot of the opcode space. I don't understand why you don't just have an option to not generate misaligned loads for people that happen to be running on CPUs where it's really slow. You don't need to wait for a profile for that. As for `seed`, if you're running on a microcontroller you can just look up t…

The option to generate or not generate misaligned loads/stores does exist (-mno-strict-align / -mstrict-align). But of course that's a compile-time option, and of course the preferred state would be to have use of them on by default, but RVA23 doesn't sufficiently guarantee/encourage them not being unreasonably-slow, leaving native misaligned loads/stores still effectively-unusable (and off by default on clang/gcc on…

> RVA23 doesn't guatantee them not being unreasonably-slow

Right but it doesn't guarantee that anything is unreasonably slow does it? I am free to make an RVA23 compliant CPU with a div instruction that takes 10k cycles. Does that mean LLVM won't output div? At some point you're left with either -mcpu= and falling back to reasonable assumptions about the actual hardware landscape.

Do ARM or x86 make any guarantees about the performance of misaligned loads/stores? I couldn't find anything.

Re: RISC-V Is Sloooow

#232

Post by saagarjha »

rwmj wrote: post #66
fidotron wrote: post #49

Earlier quoted context omitted.

> RISC-V doesn't have the pitfalls of Sparc (register windows, branch delay slots), You're saying ISA design does have implementation performance implications then? ;) > There's no one that expects it'll be hard to optimize for [Raises hand] > There are at least 2 designs that have taped out in small runs and have high end performance. Are these public? Edit: I should add, I'm well aware of the cultural mismatch betw…

The 2 designs I'm thinking of are (tiresomely) under NDA, although I'm sure others will be able to say what they are. Last November I had a sample of one of them in my hand and played with the silicon at their labs, running a bunch of AI workloads. They didn't let me take notes or photographs. > There's no one that expects it'll be hard to optimize for No one who is an expert in the field, and we (at Red Hat) talk to…

Expert here, are these made for general purpose workloads or do you expect them to be fast for AI only?

Re: RISC-V Is Sloooow

#233

Post by IshKebab »

saagarjha wrote: post #230
IshKebab wrote: post #210

Earlier quoted context omitted.

I think having separate unaligned load/store instructions would be a much worse design, not least because they use a lot of the opcode space. I don't understand why you don't just have an option to not generate misaligned loads for people that happen to be running on CPUs where it's really slow. You don't need to wait for a profile for that. As for `seed`, if you're running on a microcontroller you can just look up t…

RISC-V is not particularly good at using opcode space, unfortunately.

I don't think it's too bad. The compressed extension was arguably a mistake (and shouldn't be in RVA23 IMO), but apart from that there aren't any major blunders. You're probably thinking about how JAL(R) basically always uses x1/x5 (or whatever it is), but I don't think that's a huge deal.

About 1/3 of the opcode space is used currently so there's a decent amount of space left.

Re: RISC-V Is Sloooow

#234

Post by torginus »

tosti wrote: post #195
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.

Regarding misaligned reads, IIRC only x86 hides non-aligned memory access. It's still slower than aligned reads. Other processors just fault, so it would make sense to do the same on riscv. The problem is decades of software being written on a chip that from the outside appears not to care.

Yes, unaligned loads/stores are a niche feature that has huge implications in processor design - loads across cache-lines with different residency, pages that fault etc.

This is the classic conundrum of legacy system redesign - if customers keep demanding every feature of the old system be present, and work the exact same then the new system will take on the baggage it was designed to get rid of.

The new implementation will be slow and buggy by this standard and nobody will use it.

Re: RISC-V Is Sloooow

#236

Post by torginus »

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.

It was the case even 15 years ago when Cortex M0/M3 really started to get traction, that the processor area of ARM cores was small enough to not make a difference in practice.

Re: RISC-V Is Sloooow

#237

Post by imtringued »

pjmlp wrote: post #205
burntoutgray wrote: post #141

Earlier quoted context omitted.

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

I am a firm believer that if AMD wasn't in the position to be able to come up with AMD64 architecture, eventually those Itanium issues would have been sorted out, Windows XP was already there and there was no other way for 64 bit going forward.

I don't know anything about Itanium in particular, but AMD's NPU uses a VLIW architecture and they had to break backwards compatibility in the ISA for the second generation NPU (XDNA2) to get better performance.

Re: RISC-V Is Sloooow

#238

Post by sylware »

The current hardware used is self-hosting mini-server grade, and certainly not on the latest silicon process. "Slow" is expected.

It is not the ISA, but the implementations and those horrible SDKs which needs to be adjusted for RISC-V (actually any new ISA).

RISC-V needs extremely performant implementations, that on the best silicon process, until then RISC-V _will be_ "slow".

Not to mention, RISC-V is 'standard ISA': assembly writted software is more than appropriate in many cases.

Re: RISC-V Is Sloooow

#239

Post by torginus »

newpavlov wrote: post #44
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…

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.

Unaligned load/store is a horrible feature to implement.

Page size can be easily extended down the line without breaking changes.

Re: RISC-V Is Sloooow

#240

Post by dzaima »

IshKebab wrote: post #231
dzaima wrote: post #226

Earlier quoted context omitted.

The option to generate or not generate misaligned loads/stores does exist (-mno-strict-align / -mstrict-align). But of course that's a compile-time option, and of course the preferred state would be to have use of them on by default, but RVA23 doesn't sufficiently guarantee/encourage them not being unreasonably-slow, leaving native misaligned loads/stores still effectively-unusable (and off by default on clang/gcc on…

> RVA23 doesn't guatantee them not being unreasonably-slow Right but it doesn't guarantee that anything is unreasonably slow does it? I am free to make an RVA23 compliant CPU with a div instruction that takes 10k cycles. Does that mean LLVM won't output div? At some point you're left with either -mcpu= and falling back to reasonable assumptions about the actual hardware landscape. Do ARM or x86 make any guarantees ab…

I don't think x86/ARM particularly guarantee fastness, but at least they effectively encourage making use of them via their contributions to compilers that do. They also don't really need to given that they mostly control who can make hardware anyway. (at the very least, if general-purpose HW with horribly-slow misaligned loads/stores came out from them, people would laugh at it, and assume/hope that that's because of some silicon defect requiring chicken-bit-ing it off, instead of just not bothering to implement it)

Indeed one can make any instruction take basically-forever, but 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 (on at least some inputs), else having said instruction is strictly-redundant.

And if any significant general-purpose hardware actually did a 10k-cycle div around the time the respective compiler defaults were decided, I think there's a good chance that software would have defaulted to calling division through a function such that an implementation can be picked depending on the running hardware. (let's ignore whether 10k-cycle-division and general-purpose-hardware would ever go together... but misaligned-mem-ops+general-purpose-hardware definitely do)

Post reply on HN