4 ms·

English is not my native language and I wrote a bit too fast the message: I wanted to say that "everything pushing forward RISC-V is good". I code RISC-V assem

by sylware 3mo ago

English is not my native language and I wrote a bit too fast the message: I wanted to say that "everything pushing forward RISC-V is good". I code RISC-V assembly, I don't use C machine instructions (I don't even use the pseudo-instructions, ABI register names and dodge nearly all ISA extensions, I try to stick to core as much as I can). I run my code on x86_64 linux with a small interpreter written in x86_64 assembly (thx to the 'R' in RISC). I wonder if there are some 'broad and not niche, real-life' speed benchmark numbers to show how much C machine instructions are worth. For the moment, I see those C machine instructions more as a marketing extension to match their arm equivalent: you know, for those key deciding people who care more about the amount of features and not their contextual pertinent usage. To say an ISA is "good" is related to some set of technical sweet spots based on compromises based on projected usages. RVA from my point of view is mostly preparing RISC-V hardware for some level of x86_64/arm compatibility. I wonder if there are RISC-V implementations using the latest silicon process from TSMC.

rwmj 3mo ago
Aarch64 dropped thumb instructions. I don't think you're going to find a single benchmark on the effectiveness of compressed instructions since it really depends deeply on both the workload and the whole system. For example, memory bandwidth and cache pressure are both important for whether smaller text sizes matter, and that may depend on what else is running at the same time. Note your assembler may be automatically compressing instructions without you asking. You'll have to disassemble the binary to find out.
- camel-cdr 3mo ago
  You can benchmark stuff with and without RVC. Once there is faster hardware I want to do such a comparison with a full gentoo build for both sides. However, quantifying what the result will actually mean is nearly impossible, because you don't know what the hardware cost was.
- sylware 3mo ago
  Maybe the best approach is to remove C from RVA while keeping it around in the specs for niche applications where text size _really_ matters (with current silicon processes, I wonder how weird those niche applications have to be to require C). But it seems some would remove C even from the specs to free some ISA space. If arm removed thumb... Don't worry, I would know if the assembler is producing C machine instructions, my rv64 interpreter on x86_64 does not support the C instructions at all.
  - brucehoult 3mo ago
    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.
    - sylware 3mo ago
      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 only be better to fix it asap. After reading the comments and documents provided here, I am the first to be suprised by how much doing 'performant C' is not that easy and has a significant hardware cost. "arm removing thumb" should have been a strong signal. Again, I am coding rv64 assembly almost every day, a good part could be C-ized to shrink text size, but based on various numbers provided here, why bother, better keep the 'R' of RISC as faithfull to its goal than anything else.
      - brucehoult 3mo ago
        > "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 clocks

by sylware 3mo ago

rwmj 3mo ago

Aarch64 dropped thumb instructions. I don't think you're going to find a single benchmark on the effectiveness of compressed instructions since it really depends deeply on both the workload and the whole system. For example, memory bandwidth and cache pressure are both important for whether smaller text sizes matter, and that may depend on what else is running at the same time. Note your assembler may be automatically compressing instructions without you asking. You'll have to disassemble the binary to find out.

camel-cdr 3mo ago
You can benchmark stuff with and without RVC. Once there is faster hardware I want to do such a comparison with a full gentoo build for both sides. However, quantifying what the result will actually mean is nearly impossible, because you don't know what the hardware cost was.
sylware 3mo ago
Maybe the best approach is to remove C from RVA while keeping it around in the specs for niche applications where text size _really_ matters (with current silicon processes, I wonder how weird those niche applications have to be to require C). But it seems some would remove C even from the specs to free some ISA space. If arm removed thumb... Don't worry, I would know if the assembler is producing C machine instructions, my rv64 interpreter on x86_64 does not support the C instructions at all.
- brucehoult 3mo ago
  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.
  - sylware 3mo ago
    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 only be better to fix it asap. After reading the comments and documents provided here, I am the first to be suprised by how much doing 'performant C' is not that easy and has a significant hardware cost. "arm removing thumb" should have been a strong signal. Again, I am coding rv64 assembly almost every day, a good part could be C-ized to shrink text size, but based on various numbers provided here, why bother, better keep the 'R' of RISC as faithfull to its goal than anything else.
    - brucehoult 3mo ago
      > "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 clocks