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

351–360 of 397 posts

Re: RISC-V Is Sloooow

#351

Post by brucehoult »

dzaima wrote: post #344
brucehoult wrote: post #343

Earlier quoted context omitted.

> RISC-V hardware with slow misaligned mem ops does exist to non-insignificant extent Only U74 and P550, old RV64GC CPUs. SiFive's RVA23 cores have fast misaligned accesses, as do all THead and SpacemiT cores. I can't imagine that all the Tenstorrent and Ventana and so forth people doing massively OoO 8-wide cores won't also have fast misaligned accesses. As a previous poster said: if you're targeting RVA23 then just…

P550 is, like, what, only a year old? I suppose there has been some laughing at it at least. Also Kendryte K230 / C908, but only on vector mem ops, which adds a whole another mess onto this. I'd hope all the massive OoO will have fast misaligned mem ops, anything else would immediately cause infinite pain for decades. But of course there'll be plenty of RVA23 hardware that's much smaller eventually too, once it becom…

> P550 is, like, what, only a year old?

No, it was released to customers in June 2021, almost five years ago.

https://www.sifive.com/press/sifive-performance-p550-core-se...

It has take a while for this core to appear in an SoC suitable for SBCs, as Intel was originally announced as doing that and got as far as showing a working SoC/Board at the Intel Innovation 2022 event in September 2022.

Someone who attended that event was able to download the source code for my primes benchmark and compile and run it, at the show, and was kind enough to send me the results. They were fine.

For reasons known only to Intel, they subsequently cancelled mass production of the chip.

ESWIN stepped up and made the EIC7700X, as used in the Milk-V Megrez and SiFive HiFive Premier P550, which did indeed ship just over a year ago.

But technically we could have had boards with the Intel chip three years ago.

Heck we should have had the far better/faster Milk-V Oasis with the P670 core (and 16 of them!) two years ago. Again, that was business/politics that prevented it, not technology.

Re: RISC-V Is Sloooow

#352

Post by snvzz »

rwmj wrote: post #257
userbinator wrote: post #186

Earlier quoted context omitted.

Contrast with x86: add eax, ecx jo overflow

Neither x86-64 nor RISC-V is implemented by running each single instruction. They both recognize patterns in the code and translate those into micro-ops. On high performance chips like Rivos's (now Meta's) I doubt there'd be any difference in the amount of work done. Code size is a benefit for x86-64 however - no one is arguing that - but you have to trade that against the difficulty of instruction decoding.

>Code size is a benefit for x86-64 however

Except it isn't. Code isn't one single pattern repeating again and again; on large enough bodies of code, RISC-V is the most dense, and it's not even close.

Re: RISC-V Is Sloooow

#353

Post by sitharus »

userbinator wrote: post #345
rwmj wrote: post #257

Earlier quoted context omitted.

Neither x86-64 nor RISC-V is implemented by running each single instruction. They both recognize patterns in the code and translate those into micro-ops. On high performance chips like Rivos's (now Meta's) I doubt there'd be any difference in the amount of work done. Code size is a benefit for x86-64 however - no one is arguing that - but you have to trade that against the difficulty of instruction decoding.

I thought the main distinction of RISC-V (and MIPS before it, along with RISCs in general) is that the instructions are themselves of equivalent complexity (or lack thereof) as x86 uops. E.g x86 can add a register to memory, which splits into 3 load / add / store uops, but a RISC would execute those 3 instructions directly.

The main distinction now is RISC-descended designs use a load-modify-store instruction set with all ALU functions being register-register, and consequently have a lot more (visible) registers than CISC-descended ISAs (mostly just x86 really).

Historically RISC instructions were 1:1 with CPU operations, in theory allowing the compiler to better optimise logic, but this isn't really true anymore. High performance ARM CPUs use µOPs and macro-op fusion, though not to the extent of x86 CPUs.

This document from ARM has some details on how they use micro-ops, https://developer.arm.com/documentation/102160/latest

Re: RISC-V Is Sloooow

#354

Post by userbinator »

snvzz wrote: post #352
rwmj wrote: post #257

Earlier quoted context omitted.

Neither x86-64 nor RISC-V is implemented by running each single instruction. They both recognize patterns in the code and translate those into micro-ops. On high performance chips like Rivos's (now Meta's) I doubt there'd be any difference in the amount of work done. Code size is a benefit for x86-64 however - no one is arguing that - but you have to trade that against the difficulty of instruction decoding.

>Code size is a benefit for x86-64 however Except it isn't. Code isn't one single pattern repeating again and again; on large enough bodies of code, RISC-V is the most dense, and it's not even close.

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

Re: RISC-V Is Sloooow

#355

Post by purplesyringa »

camel-cdr wrote: post #339
adrian_b wrote: post #71

Earlier quoted context omitted.

RISC-V does not have the pitfalls of experimental ISAs from 45 years ago, but it has other pitfalls that have not existed in almost any ISA since the first vacuum-tube computers, like the lack of means for integer overflow detection and the lack of indexed addressing. Especially the lack of integer overflow detection is a choice of great stupidity, for which there exists no excuse. Detecting integer overflow in hardw…

OK, look. Since my previous attempt to measure the impact of trap on signed overflow didn't seem to have moved your position one bit, I thought I'd give it a go in the most representable way I could think of: I build the same version of clang on a x86, aarch64 and RISC-V system using clang. Then I build another version with the `-ftrapv` flag enabled and compared the compiletimes of compiling programs using these cla…

I suspect that LLVM is optimized for compiling with `-ftrapv`, perhaps for cheap sanitizing or maybe just due to design decisions like using unsigned integers everywhere (please correct me if I'm wrong). I'm personally interested in how RISC-V behaves on computational tasks where computing carry is a known bottleneck, like long addition. Maybe looking at libgmp could be interesting, though I suspect absolute numbers will not be meaningful, and there's no baseline to compare them to.

Re: RISC-V Is Sloooow

#356

Post by pjmlp »

CyberDildonics wrote: post #340
pjmlp wrote: post #205

Earlier quoted context omitted.

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.

It has never happened that a compiler was able to do static scheduling of general purpose instructions over the long term. Every CPU changes the cycles it takes for many instructions, adds new instructions etc. Out of order execution is a huge dividing line in performance for a reason. The CPU itself needs to figure these things out to minimize memory latency, cache latency, pipelining, prefetching and all that stuff…

I haven't said that, I said that I am a firm beliver that Itanium would have prevailed without AMD being able to push their AMD64 alternative.

Maybe compilers would get better, maybe Itanium would have needed some redesign, after all it isn't as if a Raptor Lake Refresh execution units are the same as an Xeon Nocona, yet both execute x64 instructions.

Re: RISC-V Is Sloooow

#357

Post by BoredomIsFun »

sidewndr46 wrote: post #287
BoredomIsFun wrote: post #207

Earlier quoted context omitted.

1. Yes, but most of the code would run on anything older than 2007. 20 years of stable ISA. 2. Also, fundamentally all modern CPUs are still 64-bit version of 80386. MMU, protection, low level details are all same.

This isn't really accurate, lots of commercial software is now compiled for newer x86 64 extensions. If you're using OSS it doesn't really matter as you can compile it for whatever you want.

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

Re: RISC-V Is Sloooow

#358

Post by snvzz »

userbinator wrote: post #354
snvzz wrote: post #352

Earlier quoted context omitted.

>Code size is a benefit for x86-64 however Except it isn't. Code isn't one single pattern repeating again and again; on large enough bodies of code, RISC-V is the most dense, and it's not even close.

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.

Re: RISC-V Is Sloooow

#359

Post by panick21_ »

userbinator wrote: post #346
panick21_ wrote: post #302

Earlier quoted context omitted.

The original ARM 32 stuff is clearly out of patents and is not being copied. And it doesn't require new extensions to be commercially viable.

and is not being copied Are you sure, especially considering China? I doubt there is any legal barrier, because there are a few existing projects with x86 cores on an FPGA, as well as some SoCs. Here's a 486: https://opencores.org/projects/ao486

Ok if China is doing something only for China market that tells you something.

As for opencores, yes you can design them, but do any companies making commercial products sell them?

Re: RISC-V Is Sloooow

#360

Post by dzaima »

brucehoult wrote: post #351
dzaima wrote: post #344

Earlier quoted context omitted.

P550 is, like, what, only a year old? I suppose there has been some laughing at it at least. Also Kendryte K230 / C908, but only on vector mem ops, which adds a whole another mess onto this. I'd hope all the massive OoO will have fast misaligned mem ops, anything else would immediately cause infinite pain for decades. But of course there'll be plenty of RVA23 hardware that's much smaller eventually too, once it becom…

> P550 is, like, what, only a year old? No, it was released to customers in June 2021, almost five years ago. https://www.sifive.com/press/sifive-performance-p550-core-se... It has take a while for this core to appear in an SoC suitable for SBCs, as Intel was originally announced as doing that and got as far as showing a working SoC/Board at the Intel Innovation 2022 event in September 2022. Someone who attended that…

> No, it was released to customers in June 2021, almost five years ago.

Ah, okay. (still, like, at least a couple decades newer than the last x86-64 chip with slow unaligned mem ops, if such ever existed at all? Haven't heard of / can't find anything saying any aarch64 ever had problems with them either, so still much worse for the RISC-V side).

Well, I suppose we can hope that business/politics messes will all never happen again and won't affect anything RVA23.

Post reply on HN