6 ms·

> Requiring C (compressed) is necessary to avoid splitting the Linux ecosystem. Chips lacking C would never be able to run binaries compiled with C. Yes that's

by timhh 2mo ago

> Requiring C (compressed) is necessary to avoid splitting the Linux ecosystem. Chips lacking C would never be able to run binaries compiled with C. Yes that's precisely the point of excluding it from the RVA profiles. It would mean that Linux distros don't compile code with C enabled, so chips are free to not support C and therefore can achieve higher performance (probably). And it opens 3/4 of the instruction encoding space for use by other things. > Also the excuse given by Qualcomm - that it would make all instructions fixed length and so much easier to decode - is just wrong. RISC-V supports variable length instructions, even much longer than 32 bits, and you've just got to deal with it. It's not wrong. RISC-V defines a mechanism by which 48/64 bit instructions might be used, but currently none are actually defined. All existing instructions are 16 or 32 bits. Without C all instructions are 32 bits. You don't have to deal with 48 bit instructions because there aren't any. It's possible that they will add some in future, but I'm doubtful of that because a) it would be a huge pain, and b) they didn't for Vector which is where it would have been most useful. > Just because Qualcomm acquired a company with a microarchitecture that could only deal with fixed length instructions is no reason to break the ecosystem. Yeah it was too late to change but that doesn't mean it wasn't a mistake. Zicond looks good - I forgot that exists.

camel-cdr 2mo ago
> Yes that's precisely the point of excluding it from the RVA profiles. It would mean that Linux distros don't compile code with C enabled, so chips are free to not support C and therefore can achieve higher performance (probably). And it opens 3/4 of the instruction encoding space for use by other things. The debate was between 16/32/48/64-bit instructions vs naturally aligned 32-bit and 64-bit instructions + new more complex instructions that require cracking to regain code size (things like load/store pair). > RISC-V defines a mechanism by which 48/64 bit instructions might be used, but currently none are actually defined The long-instruction-SIG just started a few weeks ago, and they are working on defining 48/64-bit encodings for instructions that could be used in future RVA profiles (so with high perf implementations in mind). If you are knowledgeable about this stuff, please get involved, so they don't mess it up. (not "you" specifically, but in general)
rwmj 2mo ago
Compressed is necessary to reduce code size which is important for performance. A bunch of vendors have done high performance server chips which support compressed (Rivos, Ventana, some Chinese vendors), so in actual reality this was only a problem for Qualcomm. And that's only because Qualcomm bought Nuvia and they wanted to do the cheap thing (minimally change the front end) rather than the right thing.
- timhh 2mo ago
  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).
  - camel-cdr 2mo ago
    > 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/unpriv/zijfal.adoc https://github.com/riscv/riscv-isa-manual/blob/zijfal/src/un... [1] https://lists.riscv.org/g/tech-profiles/attachment/321/0/A%20case%20to%20remove%20the%20C%20extension%20from%20app%20profiles,%20part%202%20-%20Profiles%20TG%2020231005.pdf https://lists.riscv.org/g/tech-profiles/attachment/321/0/A%2... [2] https://lists.riscv.org/g/tech-profiles/attachment/353/0/RISCV-20231004-C.pdf https://lists.riscv.org/g/tech-profiles/attachment/353/0/RIS... [3] https://lists.riscv.org/g/tech-profiles/attachment/378/0/Response%20to%20SiFive%20C%20Presentation.pdf https://lists.riscv.org/g/tech-profiles/attachment/378/0/Res... [4] https://lists.riscv.org/g/tech-profiles/attachment/400/0/AOSP%20Compression.pdf https://lists.riscv.org/g/tech-profiles/attachment/400/0/AOS...

by timhh 2mo ago

camel-cdr 2mo ago

> Yes that's precisely the point of excluding it from the RVA profiles. It would mean that Linux distros don't compile code with C enabled, so chips are free to not support C and therefore can achieve higher performance (probably). And it opens 3/4 of the instruction encoding space for use by other things. The debate was between 16/32/48/64-bit instructions vs naturally aligned 32-bit and 64-bit instructions + new more complex instructions that require cracking to regain code size (things like load/store pair). > RISC-V defines a mechanism by which 48/64 bit instructions might be used, but currently none are actually defined The long-instruction-SIG just started a few weeks ago, and they are working on defining 48/64-bit encodings for instructions that could be used in future RVA profiles (so with high perf implementations in mind). If you are knowledgeable about this stuff, please get involved, so they don't mess it up. (not "you" specifically, but in general)

rwmj 2mo ago

Compressed is necessary to reduce code size which is important for performance. A bunch of vendors have done high performance server chips which support compressed (Rivos, Ventana, some Chinese vendors), so in actual reality this was only a problem for Qualcomm. And that's only because Qualcomm bought Nuvia and they wanted to do the cheap thing (minimally change the front end) rather than the right thing.

timhh 2mo ago
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).
- camel-cdr 2mo ago
  > 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/unpriv/zijfal.adoc https://github.com/riscv/riscv-isa-manual/blob/zijfal/src/un... [1] https://lists.riscv.org/g/tech-profiles/attachment/321/0/A%20case%20to%20remove%20the%20C%20extension%20from%20app%20profiles,%20part%202%20-%20Profiles%20TG%2020231005.pdf https://lists.riscv.org/g/tech-profiles/attachment/321/0/A%2... [2] https://lists.riscv.org/g/tech-profiles/attachment/353/0/RISCV-20231004-C.pdf https://lists.riscv.org/g/tech-profiles/attachment/353/0/RIS... [3] https://lists.riscv.org/g/tech-profiles/attachment/378/0/Response%20to%20SiFive%20C%20Presentation.pdf https://lists.riscv.org/g/tech-profiles/attachment/378/0/Res... [4] https://lists.riscv.org/g/tech-profiles/attachment/400/0/AOSP%20Compression.pdf https://lists.riscv.org/g/tech-profiles/attachment/400/0/AOS...