[timhh]

Of course you can make compressed work. E.g. you fetch 66 bytes instead of 64. Hell, Intel/AMD manage to make x86 fairly fast.

But it's definitely more awkward and has costs throughout the CPU.

I would be really surprised if the lower code density is worse than the improvement due to everything being nicely aligned. Especially because Qualcomm had actual data that it isn't (if you add new instructions with the extra coding space you free up).

[Taniwha]

You don't really fetch 66 bytes instead of 64, what real implementations do is read cache lines (of whatever size) and hold on to 2 bytes from the previous cache line if there was 1/2 a 32-bit instruction at the end of the previous cache line (the ISA has the 16/32-bit tag in the lower byte so you know how big an instruction will be even if you've only seen half of it)

[inkyoto]

> […] and hold on to 2 bytes from the previous cache line if there was 1/2 a 32-bit instruction at the end of the previous cache line […]

Well, and that is the worst case scenario from the performance standpoint since, if a 32-bit instruction is spans a page boundary, it will result in a page fault stalling the instruction decoder.

It might be acceptable in implementations not sensitive to such an overhead (e.g. embedded solutions) but is wholly unacceptable in high performance scenarios.

[brucehoult]

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 that next cache line / page.

The only time it could possibly make a difference is if that spanning instruction is a jump to somewhere else AND that instruction could somehow have fit entirely in the previous page.

If there was no C extension then that next instruction would NOT be entirely in the previous page, it would be somewhere well into the next page, and that next page would have been required to be fetched much sooner. The C extension typically allows 30% to 50% more functionality to fit in each VM page.

Also, Qualcomm's proposed new instructions did not in fact use the freed-up space from not having C. They fit into other unused parts of the ISA.

I don't object to the new instructions Qualcomm suggested. I'd be perfectly happy to see them ratified and added to a future standard (even to RVA23 if they'd chosen to pursue that, but they didn't).

What I and others objected to was dropping the C extension from RVA23, or any future RVA-series, overnight given that RVA20 and RVA22 already existed with the C extension.

There will come a time when some RISC-V extensions will be retired and replaced, and it's entirely possible that C might be one of them, but there is currently no mechanism to do that, and when there is I'd expect that it would be done with a 10 or 12 year deprecation period, minimum.

NEVER overnight between one standard and the next one.

Which wouldn't have helped Qualcomm with their Nuvia core anyway.

Anyway, Qualcomm had now bought Ventana, which has engineers who know how to support the C extension with high performance, and they already had high performance RISC-V cores doing so.

So problem solved.

[inkyoto]

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 code density;

  – Improved code density is conducive of better instruction cache utilisation and reducing the pressure on the TLB;

  – Mixed-width decoding (a trade-off) demonstrably adds front-end work (especially in pathological cases[0]);

  – No publicly benchmarked RISC-V processor is sufficiently contemporary and wide (or very wide) to impart the net effect of that trade-off at the highest performance tier;

  – Performance targets (aarch64 and x86-64) are moving faster than publicly demonstrated performance of existing RISC-V implementations in silicon, and the gap is not closing in.

So purported performance benefits of C may or may not materialise – it remains to be seen and proved, and claims that a future wide RISC-V core will validate design choices such as C remain not yet falsified projections rather than demonstrated engineering results – at this stage.

[0] The second page is not resident, the decoder can't proceed because the second half-word can't be obtained, the access generates a page fault, the CPU eventually vectors to the page-fault handler. Genuine page faults are extremely expensive.

[brucehoult]

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.

[inkyoto]

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.

Given a six year gap between two design (2019 vs 2025), the result is wholly underwhelming.

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.

Another, June 2026, study using production astrophysics codes found the SG2044 roughly 3–6 times slower[1] than an AMD EPYC 9554 system and 3–9 times slower than an Nvidia Grace system, workload depending.

[0] https://arxiv.org/html/2508.13840v1

[1] https://arxiv.org/abs/2508.13840v1

[sylware]

Huh?

There are RISC-V "performant" implementations on the best TSMC silicon process like x86-64 and aarch64?

[inkyoto]

There are not.

[camel-cdr]

> E.g. you fetch 66 bytes instead of 64

Not really, you would fetch fewer bytes with RVC [2, page 9], because the code density is better.

> I would be really surprised if the lower code density is worse than the improvement due to everything being nicely aligned.

This is very hard to quantify.

> Especially because Qualcomm had actual data that it isn't (if you add new instructions with the extra coding space you free up).

I've liked the back and forth slides bellow. Though I want to bring up to things regrading the Qualcomm slides:

    > [RVC] Performance benefit is modest
    > • Best case: 2-3% speedup

I recently benchmark compiling programs with a rva23 clang build and clang compiled for rva23-without-C and got a 10% performance improvement from RVC on the SpacemiT X100.

I also have no idea how they got those numbers. (not that they are wildly implausible, it's just not transparent)

    > Improving Android Code Size

In the last presentation they show how you can add a +-64M 32-bit long jump instruction to improve codesize in large binaries, like those in android.

I want to point out, that the JAL opcode has enough space left (7/8th) to encode a long jump of a same range and there is a proposal for a 32-bit +32M -12M 32-bit long jump: https://github.com/riscv/riscv-isa-manual/blob/zijfal/src/un...

[1] https://lists.riscv.org/g/tech-profiles/attachment/321/0/A%2...

[2] https://lists.riscv.org/g/tech-profiles/attachment/353/0/RIS...

[3] https://lists.riscv.org/g/tech-profiles/attachment/378/0/Res...

[4] https://lists.riscv.org/g/tech-profiles/attachment/400/0/AOS...