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

261–270 of 397 posts

Re: RISC-V Is Sloooow

#261

Post by panick21_ »

dbdr wrote: post #244
panick21_ wrote: post #213

Earlier quoted context omitted.

Its not about patents. Believe what you want but there is a reason nobody else is doing x86 or ARM chips unless they are allowed by the owner.

You're probably right. It would be helpful to say what the reason is, if it's not patents.

I'm not a lawyer but I would assume its copyright. Kind of like API in software. In software somehow this does not apply most of the time. But it seems in hardware this is very real. But I would appreciate a lawyer jumping in.

I know for example that Berkley when thinking pre-RISC-V that they had a deal with Intel about using x86-64 for research. But they were not able to share the designs.

Re: RISC-V Is Sloooow

#262

Post by rwmj »

jacquesm wrote: post #124
statusfailed wrote: post #120

Earlier quoted context omitted.

The Milk-V Jupiter 2 (coming out in April) is RV23 too

Nice board but very low on max RAM.

The Milk-V Titan (https://milkv.io/titan) can take up to 64GB which is fine considering the number of cores and the cost of RAM. If you needed and could afford more RAM you'd be better off distributing the work across more than one board.

Re: RISC-V Is Sloooow

#263

Post by newpavlov »

IshKebab wrote: post #255
dzaima wrote: post #240

Earlier quoted context omitted.

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

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

>So just use misaligned loads if Zicclsm is supported.

LLVM and GCC developers clearly disagree with you. In other words, re-iterating the previously raised point: Zicclsm is effectively useless and we have to wait decades for hypothetical Oilsm.

Most programmers will not know that the misaligned issue even exists, even less about options like -mno-strict-align. They just will compile their project with default settings and blame RISC-V for being slow.

RISC-V could've easily avoided all this mess by properly mandating misaligned pointer handling as part of the I extension.

Re: RISC-V Is Sloooow

#264

Post by dzaima »

IshKebab wrote: post #255
dzaima wrote: post #240

Earlier quoted context omitted.

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

> 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 started, and started wrong. I suppose we'll see what happens with real RVA23 hardware; at the very least, even if it takes a decade for most hardware to support misaligned well, software could retroactively change its defaults while still remaining technically-RVA23-compatible, so I suppose that's good.

Re: RISC-V Is Sloooow

#265

Post by jabl »

ori_b wrote: post #150
edflsafoiewq wrote: post #111

Earlier quoted context omitted.

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.

x86 has decades of knowhow and a zillion transistors to spend on making the memory pipeline, TLB caching & prefetching etc. etc. really really good. They work as well as they do despite the 4k base page size, not because of it.

If you'd start from a clean sheet today you'd probably end up with a somewhat bigger base page size. Not hugely larger though, as that wastes a lot of memory for most applications. Maybe 16k like some ARM chips use?

Re: RISC-V Is Sloooow

#266

Post by orangeboats »

throwa356262 wrote: post #258
mrbluecoat wrote: post #138

> Random mumblings of ARM developer ... RISC-V is sloooow Old news. See also: > Random mumblings of x86_64 developer ... ARM is sloooow

What kind or ancient arm hardware are they using here? On a related note, SoC companies needs to get their act together and start using the latest arm cores. Even the mid range cores of 1-2 years ago show a huge leap in performance: https://sbc.compare/56-raspberry-pi-500-plus-16gb/101-radxa-...

>What kind or ancient arm hardware are they using here?

I think that's the point being made here. ARM in the 2000s was not known to be fast, now it is.

RISC-V being slow isn't an inherent characteristic of the ISA, it only tells you about the quality of its implementations. And said implementations will only improve if corporations are throwing capitals at it (see: Apple, Qualcomm, etc.)

Re: RISC-V Is Sloooow

#267

Post by ahartmetz »

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.

I mean, that is often what you do in embedded computing: you (re)sell hardware with one particular application.

Re: RISC-V Is Sloooow

#268

Post by kashyapc »

userbinator wrote: post #179
kashyapc wrote: post #137

Arm had 40 years to be where it is today. RISC-V is 15 years old. Some more patience is warranted. Assuming they will keep their word, later this year Tenstorrent is supposed to ship their RVA23-based server development platform[1]. They announced[2] it at the last year's NA RISC-V Summit. Let's see. The ball is in the court of hardware vendors to cook some high-end silicon. [1] https://tenstorrent.com/ip/risc-v-cpu…

MIPS, which RISC-V is closely modeled after, is also roughly 4 decades old and was massively hyped in the early 90s as well.

Great point; I only know about MIPS legacy vaguely. As you imply, don't listen to the "hype-sters" but pay attention to what silicon is being produced.

Re: RISC-V Is Sloooow

#270

Post by dzaima »

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

>So just use misaligned loads if Zicclsm is supported. LLVM and GCC developers clearly disagree with you. In other words, re-iterating the previously raised point: Zicclsm is effectively useless and we have to wait decades for hypothetical Oilsm. Most programmers will not know that the misaligned issue even exists, even less about options like -mno-strict-align. They just will compile their project with default setti…

Well, we don't necessarily have to wait for Oilsm; software that wants to could just choose to be opinionated and run massively-worse on suboptimal hardware. And, of course, once Oilsm hardware becomes the standard, it'd be fine to recompile RVA23-targeting software to it too.

> RISC-V could've easily avoided all this mess by properly mandating misaligned pointer handling as part of the I extension.

Rather hard to mandate performance by an open ISA. Especially considering that there could actually be scenarios where it may be necessary to chicken-bit it off; and of course the fact that there's already some questionability on ops crossing pages, where even ARM/x86 are very slow.

Post reply on HN