Earlier quoted context omitted.
Huh? There are RISC-V "performant" implementations on the best TSMC silicon process like x86-64 and aarch64?
There are not.
I thought so.
But I want that :)
Book: RISC-V System-on-Chip Design
71–80 of 80 posts
Re: Book: RISC-V System-on-Chip Design
#72Earlier quoted context omitted.
When the top perf per watt or perf per MHz machine is RISCV, we'll talk. Until then, lol.
Many here wish for the non IP-locked RISC-V to get performant micro-achitectures for embedded/server/desktop/mobile that on the latest silicon process (without that, you can have a very good micro-architecture, that won't probably make the difference). If some RISC-V high performance CPU manufacturers are being bought by big hardware actors: either they are scared of its competition and want to scrap it or they want…
False dichotomy. They are also quite possibly aqui-hires which then put the good engineers unto actually useful projects.
Re: Book: RISC-V System-on-Chip Design
#73Earlier quoted context omitted.
When the top perf per watt or perf per MHz machine is RISCV, we'll talk. Until then, lol.
Self-evidently, you therefore won't be the person building this machine.
Nope. I don’t want to work on systems that self-handicap in dumb and predictable ways. Mistakes happen. But mistakes that were preventable and knowable at design time … they are inexcusable, and RISCV is chock-full of those.
Re: Book: RISC-V System-on-Chip Design
#74Earlier quoted context omitted.
x86 seems to get by. And how is an instruction spanning a page boundary and causing a page fault any worse than an instruction NOT spanning a page boundary and the next instruction causing the page fault instead? As Paul said, if a 4 byte instruction spans a cache line/page boundary then you just hang on to the last 2 bytes of the page (first 2 bytes of that instruction) and decode them along with the instructions in…
x86 is an ancient design mired in legacy and problems, so Intel/AMD Intel and AMD had to make it work for a modern world even if that involved kludges, band-aids, and crutches. Whilst you do have a point there, personally I do not find x86 particularly interesting to discuss. I did not have Qualcomm and their latest bout of theatrical shenanigans concerning C in mind, either. Back onto C. – C demonstrably improves co…
The performance gap between RISC-V and x86 or Arm is in fact closing.
The SpacemiT K3 machines which most people who ordered in early May have now received are comparable to the RK3588 and Pi 5, with Rock 5 delivered to customers in mid 2022, Orange Pi 5 at the end of that year, and Pi 5 in October 2023.
So that's at most a 4 year gap, less than 3 years in the cast of the Pi 5.
That is the highest performance Arm64 machine most SBC users have. The faster CIX P1 exists but it seems that very few people actually have Orion O2 or Orange Pi 6 Plus.
Before the launch of the K3, the previous gen early 2022 to early 2024 JH7110, TH1520, K1 were somewhere around 6 years behind Arm SBCs.
RISC-V machines expected late this year (let's say early next year) will be similar to CIX P1, so just a 1-2 year gap.
Vs x86 the previous generation RISC-V was something like one of the last Pentium III or PowerPC G4, while the K3 is mid range Core 2 verging on early i5/i7 in many regards. So that's caught up on Intel by something close to ten years in four years. And the next gen will be somewhere around Zen 2 or whichever Skylake iteration is in the same ballpark.
Even more importantly than the gap, once that SkyLake to Zen 2 to Apple M1 performance band is reached, that is a performance level that remains "good enough" in 2026 for most users of computing devices for their everyday web browsing, media consumption, productivity/business app uses. I'm typing this on an M1 that I sit at all day every day (using it to access some faster machines for heavy work), and I have a lightweight Zen 2 laptop that I use for travel.
Re: Book: RISC-V System-on-Chip Design
#75Earlier quoted context omitted.
Self-evidently, you therefore won't be the person building this machine.
Nope. I don’t want to work on systems that self-handicap in dumb and predictable ways. Mistakes happen. But mistakes that were preventable and knowable at design time … they are inexcusable, and RISCV is chock-full of those.
I disagree.
Re: Book: RISC-V System-on-Chip Design
#76Earlier quoted context omitted.
You can't remove C from future RVA because a large part of the value of RVA is that each version can run all the shrink-wrapped (binary distribution) code built for the previous versions.
Well, I said that because based on the documents provided here, it seems there are key people considering its removal even from the specs. From my point of view, just do like all the others: clearly deprecate it, namely say that "from RVAx, don't create new machine code with the C extension". It is like in the linux kernel, it will then be removed very far in the future. But RISC-V is all about the far future, it can…
> "arm removing thumb" should have been a strong signal.
I don't see any reason to think that Arm ISA designers are any more skilled and knowledgable than RISC-V ISA designers. Given the relative number of people and the amount of academic and industry expertise you'd rather expect the opposite! Retired Arm ISA designers such as Dave Jaggar who designed Thumb and Thumb2 are on record as saying that the RISC-V designers have done a fine job, and that RISC0V is the current state of the art.
When I tested my Primes benchmark on a Pi 4, the variable-length Thumb 2 version was the fastest as well as, of course, the smallest.
11.190 sec Pi4 Cortex A72 @ 1.5 GHz T32 232 bytes 16.8 billion clocks
12.115 sec Pi4 Cortex A72 @ 1.5 GHz A64 300 bytes 18.2 billion clocks
12.605 sec Pi4 Cortex A72 @ 1.5 GHz A32 300 bytes 18.9 billion clocksRe: Book: RISC-V System-on-Chip Design
#77Earlier quoted context omitted.
Many here wish for the non IP-locked RISC-V to get performant micro-achitectures for embedded/server/desktop/mobile that on the latest silicon process (without that, you can have a very good micro-architecture, that won't probably make the difference). If some RISC-V high performance CPU manufacturers are being bought by big hardware actors: either they are scared of its competition and want to scrap it or they want…
False dichotomy. They are also quite possibly aqui-hires which then put the good engineers unto actually useful projects.
This is another way to say they are scared ofe competition and want to scrap them.
Re: Book: RISC-V System-on-Chip Design
#78Earlier quoted context omitted.
Well, I said that because based on the documents provided here, it seems there are key people considering its removal even from the specs. From my point of view, just do like all the others: clearly deprecate it, namely say that "from RVAx, don't create new machine code with the C extension". It is like in the linux kernel, it will then be removed very far in the future. But RISC-V is all about the far future, it can…
> "arm removing thumb" should have been a strong signal. I don't see any reason to think that Arm ISA designers are any more skilled and knowledgable than RISC-V ISA designers. Given the relative number of people and the amount of academic and industry expertise you'd rather expect the opposite! Retired Arm ISA designers such as Dave Jaggar who designed Thumb and Thumb2 are on record as saying that the RISC-V designe…
But on the overall, based of the documents and information provided here, and what I think I managed to understand about them: it is not surprising some want to start the deprecation of C from RVA (some would even start its deprecation from the core specs to free some machine instruction encoding space).
It is a bit like compilers: 90% of the complexity/size is for 30% of the code optimization speed gain, which has mostly a significant and pertinent impact in specific work loads on our modern hardware. Basically it is "better" (since you get rid of 90% of the complexity/size of compilers) to combine pure assembly coding with less complex/bigger compilers ("10%") (and look at dav[12]d, not to mention ffmpeg, here the main issue is feature creep of ISO C new things and GCC extensions... and abuse of the nasm pre-preprocessor). For instance, with bzip2, with cproc/qbe (zero assembly though), I get 70% of the speed of modern gcc/clang. But what's really worrying: I talked (I think it was here on HN a long time ago) to one of TheHeavyThing assembly coders, and he said that with a brutal and naive hand-compilation of the corresponding C code, he got 15-20% faster than the best compiler could provide at the time on gzip compression. Something is up here, and I already did mention dav[1]d and ffmpeg.
We are in a 101 case of 'compromise', and here, it seems the more I read about it the more I think we are facing a case of 'benefits are not worth it in the end', well the apparent 'competent' people who are in the sauce seems to agree more and more about it, through the infos I have been getting from HN.
As for the 'compilation' benchmarks provided here, we know gcc/clang are heavily x86-64 oriented, namely goes into optimizations which should favor 'C' like machine instructions (destination register same than some source register), so the 1-2% "real" speed increase from some documents provided here sounds more like the real neutral/overall thing to me.
Re: Book: RISC-V System-on-Chip Design
#79Earlier quoted context omitted.
x86 is an ancient design mired in legacy and problems, so Intel/AMD Intel and AMD had to make it work for a modern world even if that involved kludges, band-aids, and crutches. Whilst you do have a point there, personally I do not find x86 particularly interesting to discuss. I did not have Qualcomm and their latest bout of theatrical shenanigans concerning C in mind, either. Back onto C. – C demonstrably improves co…
The performance gap between RISC-V and x86 or Arm is in fact closing. The SpacemiT K3 machines which most people who ordered in early May have now received are comparable to the RK3588 and Pi 5, with Rock 5 delivered to customers in mid 2022, Orange Pi 5 at the end of that year, and Pi 5 in October 2023. So that's at most a 4 year gap, less than 3 years in the cast of the Pi 5. That is the highest performance Arm64 m…
Performance gap is not closing in specimens commercially available today, and the promises of it «happening any moment from now» are now indistinguishable from monthly horoscopes.
For example, Zen 2 is a 2019 design, and the 64-core SG2044 C920v2, which was released in May 2025, a three-decode, four-dispatch core at about 2.6 GHz, with 128-bit vectors is still approximately[0]:
– 9 times slower in the block tridiagonal solver at 64 cores;
– 2.05 times slower in the lower-upper Gauss-Seidel solver;
– 2.05 times slower in the scalar pentadiagonal solver.
The reason why those three solvers are particularly interesting, especially in the HPC scenario, is because all three exercise substantial amounts of (unlike hobbyist and similar synthetic benchmarks):
– Floating-point computation;
– Memory hierarchy behaviour;
– Cache utilisation;
– Synchronisation;
– Compiler optimisation;
– Overall processor throughput.
Re: Book: RISC-V System-on-Chip Design
#80Earlier quoted context omitted.
I like RISC-V (it's been my job for the last 7 years) but this is nonsense. Not everything RISC-V is good. CLIC was awful (thankfully it has been abandoned). The spec is not especially well written - the style is inconsistent due to being written by many authors, and it is waaaay too much of a textbook rather than a proper spec. (There is some ongoing work to improve this tbf.) There's a practically unending list of…
> CLIC was awful (thankfully it has been abandoned) Could you expand a little on what made it a bad design? I'm not much up on RISC-V.
Mostly the specification was just poorly written with many ambiguities. But also the design was complex, weird, invasive and IIRC not backwards compatible with standard RISC-V.