3 ms·

Consider the Linux kernel code getting 50% larger when you move from compressed to uncompressed instructions[0]. That puts RISC-V as among the least efficient I

by hajile 3y ago

Consider the Linux kernel code getting 50% larger when you move from compressed to uncompressed instructions[0]. That puts RISC-V as among the least efficient ISAs out there and would make it unsuitable for most applications. [0] https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-1.pdf https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-1.p...

pclmulqdq 3y ago
At the scale of Linux, you don't care about code size very much, but you care a lot about working set size. 2-20% seems to be the range of working set size reductions you see in the literature, and if you compensate with other instructions, you can get back a lot of that code size. The analysis from the SiFive folks generally doesn't include that compensation factor: it just involves a straight find-and-replace in the binary.
- hajile 3y ago
  Your assertion has two major issues. First, you context switch a lot to and from the Linux kernel, so decreased cache pressure does matter. Second, if you have proof that loops predominantly consist of 32-bit instructions, prove your case. To my mind, a loop is likely to use fewer registers and likely to have shorter branches and smaller immediate values. all of these seem to favor compressed instructions actually favoring working code even MORE than general code.
  - pclmulqdq 3y ago
    I think we agree about working set size - that's what actually matters for performance rather than overall code size. Krste from SiFive was relatively insistent on their recent call - without any proof (citing mysterious customer calls) - that people care about code size of the Linux kernel, not working set size. The performance gain he suggested that came from C instructions due to working set size in the Linux kernel is 3%. This is the performance argument coming from the biggest proponent of the C instructions. As to what you suggested, I have actually started putting something together to possibly send to the RISC-V foundation from my own experience implementing RISC-V designs, but pretty much nobody is asserting that loops are predominantly 32-bit instructions. Tight loops are often already sitting in a uop cache once you get to a core of reasonable size, so compressed vs uncompressed is completely irrelevant. Contrary to what you seem to be hoping for, correct arguments about working set size and performance are very subtle. The C instructions aren't free in frequency terms, either. You have significant complexity increases in decoders and cache hierarchies to support them. Making that cost add up to 3% is not that hard.
sweetjuly 3y ago
I keep coming back to this table and wondering why the conclusion was that 16-bit instructions were necessary and not more complex 32-bit instructions were necessary. For example, ARMv8's LDR and LDP instructions are amazing and turn what is often 3-4+ 32-bit RISC-V instructions into just one 32-bit instruction. Making C optional and building a new "code size reduction" extension that is more suitable for large application processors (which can reasonably be assumed to use uops) would help so much more.
- snvzz 3y ago
  > Making C optional and building a new "code size reduction" extension that is more suitable for large application processors (which can reasonably be assumed to use uops) would help so much more. Andrew at SiFive disagrees vehemently[0]. 0. https://lists.riscv.org/g/tech-profiles/message/391 https://lists.riscv.org/g/tech-profiles/message/391
  - sweetjuly 3y ago
    Andrew seems to mostly disagree with Qualcomm in general and is rejecting the idea not so much out of technical merit but because he doesn't believe them. Qualcomm is definitely not alone with its dislike of the C extension and trying to wholesale dismiss criticisms of it because they're coming from Qualcomm is not appropriate.
    - snvzz 3y ago
      SiFive made a technical case[0] on keeping C, too. >Qualcomm is definitely not alone It's also worth noting that they tried to appropriate Rivos's opinion, only to be called out[1]. 0. https://lists.riscv.org/g/tech-profiles/topic/slides_on_retaining_ialign_16/101922590 https://lists.riscv.org/g/tech-profiles/topic/slides_on_reta... 1. https://lists.riscv.org/g/tech-profiles/message/396 https://lists.riscv.org/g/tech-profiles/message/396

by hajile 3y ago

pclmulqdq 3y ago

At the scale of Linux, you don't care about code size very much, but you care a lot about working set size. 2-20% seems to be the range of working set size reductions you see in the literature, and if you compensate with other instructions, you can get back a lot of that code size. The analysis from the SiFive folks generally doesn't include that compensation factor: it just involves a straight find-and-replace in the binary.

hajile 3y ago
Your assertion has two major issues. First, you context switch a lot to and from the Linux kernel, so decreased cache pressure does matter. Second, if you have proof that loops predominantly consist of 32-bit instructions, prove your case. To my mind, a loop is likely to use fewer registers and likely to have shorter branches and smaller immediate values. all of these seem to favor compressed instructions actually favoring working code even MORE than general code.
- pclmulqdq 3y ago
  I think we agree about working set size - that's what actually matters for performance rather than overall code size. Krste from SiFive was relatively insistent on their recent call - without any proof (citing mysterious customer calls) - that people care about code size of the Linux kernel, not working set size. The performance gain he suggested that came from C instructions due to working set size in the Linux kernel is 3%. This is the performance argument coming from the biggest proponent of the C instructions. As to what you suggested, I have actually started putting something together to possibly send to the RISC-V foundation from my own experience implementing RISC-V designs, but pretty much nobody is asserting that loops are predominantly 32-bit instructions. Tight loops are often already sitting in a uop cache once you get to a core of reasonable size, so compressed vs uncompressed is completely irrelevant. Contrary to what you seem to be hoping for, correct arguments about working set size and performance are very subtle. The C instructions aren't free in frequency terms, either. You have significant complexity increases in decoders and cache hierarchies to support them. Making that cost add up to 3% is not that hard.

sweetjuly 3y ago

I keep coming back to this table and wondering why the conclusion was that 16-bit instructions were necessary and not more complex 32-bit instructions were necessary. For example, ARMv8's LDR and LDP instructions are amazing and turn what is often 3-4+ 32-bit RISC-V instructions into just one 32-bit instruction. Making C optional and building a new "code size reduction" extension that is more suitable for large application processors (which can reasonably be assumed to use uops) would help so much more.

snvzz 3y ago
> Making C optional and building a new "code size reduction" extension that is more suitable for large application processors (which can reasonably be assumed to use uops) would help so much more. Andrew at SiFive disagrees vehemently[0]. 0. https://lists.riscv.org/g/tech-profiles/message/391 https://lists.riscv.org/g/tech-profiles/message/391
- sweetjuly 3y ago
  Andrew seems to mostly disagree with Qualcomm in general and is rejecting the idea not so much out of technical merit but because he doesn't believe them. Qualcomm is definitely not alone with its dislike of the C extension and trying to wholesale dismiss criticisms of it because they're coming from Qualcomm is not appropriate.
  - snvzz 3y ago
    SiFive made a technical case[0] on keeping C, too. >Qualcomm is definitely not alone It's also worth noting that they tried to appropriate Rivos's opinion, only to be called out[1]. 0. https://lists.riscv.org/g/tech-profiles/topic/slides_on_retaining_ialign_16/101922590 https://lists.riscv.org/g/tech-profiles/topic/slides_on_reta... 1. https://lists.riscv.org/g/tech-profiles/message/396 https://lists.riscv.org/g/tech-profiles/message/396