3 ms·

Yes and no. The GP is counting instructions, which is approximately the same between ARM64 and RV64. Others are talking about code density where RISC-V currentl

Yes and no. The GP is counting instructions, which is approximately the same between ARM64 and RV64. Others are talking about code density where RISC-V currently has a significant advantage due to compressed instructions. ----------------- For the above code segment, though I selected the compile-to-binary option, and the program failed to compile. So I don't know what's up with that. On a relatively short chunk of C++ code, you can see the compressed (16-bit) instructions in the binary output: https://godbolt.org/z/jzjzrrfMP https://godbolt.org/z/jzjzrrfMP Some instructions, such as the ones with a larger immediate load, are 32-bit. Same version of GCC / G++ as the above. The actual code size of the ARM64 is bigger: https://godbolt.org/z/Wq7jKz5rY https://godbolt.org/z/Wq7jKz5rY I'm not sure why all the NOP instructions are in there, but even discounting that, all the generated machine instructions are 32-bit. Is there another option for GCC that will help? Or am I mistaken in thinking there is a Thumb2 equivalent for this target? Edit: Answer: No. A64 is fixed-length: https://developer.arm.com/documentation/den0024/a/An-Introduction-to-the-ARMv8-Instruction-Sets/The-ARMv8-instruction-sets https://developer.arm.com/documentation/den0024/a/An-Introdu...

inkyoto 4y ago
For the sake of savouring a civilised nerdy discourse, may we stick to the same code and set a rule that only compiler switches can be fiddled with? Comparing 3 lines (after discarding empty lines, curly braces, functions and variable declarations) of unrelated code (which is not a C++ code anyway) yielding a 5 or so CPU instructions is boring and is not enlightening in our quest to reveal the light and unveil the path to truth. The piece of C++ code I have uploaded to GodBolt was floated on HN a few years ago as an instance of the template metaprograaming that crashed one C++ compiler and resulted in an OOM process kill for another (for the record, it was clang++ and g++ although I can't remember which one did what). Both compilers have been fixed since then, but the code is still interesting due to it being: a) terse, and b) resulting in a unusually large number of [mostly useless] numeric computations that a C++ compiler yields by virtue of the template expansion. So I have retained a copy of the mischievous code. The template expansion is common in C++ template metaprogramming, and is extensively used in C++ scientific libraries (e.g. BLASS as well as in others). When it comes to the generated code footprint comparison, the numeric computations are a good metric to assess.
- ansible 4y ago
  I compiled that code with slight modifications (needed an actual func1 function) with a cross-compiler I had laying around into actual executables: cross g++ version 8.4.0 for aarch64: 13712 bytes native g++ version 11.3.0-3 for RV64GC: 13968 bytes ... but that includes a bunch of startup stuff, so that's not a good measure. Modifying the code to generate binary on godbolt: ARM64, 3816 bytes: https://godbolt.org/z/vn3de5nEc https://godbolt.org/z/vn3de5nEc RV64GC, 3226 bytes: https://godbolt.org/z/4ovMTaxo9 https://godbolt.org/z/4ovMTaxo9 So an 18% increase in code size for ARM 64-bit vs RISC-V 64-bit. As you can see in the generated code, there are 16-bit compressed instructions by default with the RV64GC binary.
  - inkyoto 4y ago
    This is excellent, thank you. I was under the impression that the compressed instructions set required a dedicated compiler switch, and counted a number of instructions instead. Now that «X is 18% smaller than Y» is quantified, there is the circumstantial evidence, and it gives a clearer idea of the differences between two ISA's. Yet, it does not validate the absolutist and unquantifiable «awful code density» statement. I have also noted that compressed and uncompressed instructions are unevenly interleaved in the generated code, and occur in random sequences, i.e. addresses 0x10a60 ÷ 0x10a72 follow the 16-32-16-16-16-16-32-16 bit sequence whereas most other instructions follow 16-32 bit or 16-32-32 / 16-16-32 bit sequences. I wonder what performance penalty for the instruction decoding unit in hi-perf RISC-V cores is going to be for compressed vs uncompressed instructions code especially if the instruction being decoded spills over into the next L1 i-cache line (or, worse, into another memory page). RISC architectures are generally averse to misaligned memory access.

inkyoto 4y ago

For the sake of savouring a civilised nerdy discourse, may we stick to the same code and set a rule that only compiler switches can be fiddled with? Comparing 3 lines (after discarding empty lines, curly braces, functions and variable declarations) of unrelated code (which is not a C++ code anyway) yielding a 5 or so CPU instructions is boring and is not enlightening in our quest to reveal the light and unveil the path to truth. The piece of C++ code I have uploaded to GodBolt was floated on HN a few years ago as an instance of the template metaprograaming that crashed one C++ compiler and resulted in an OOM process kill for another (for the record, it was clang++ and g++ although I can't remember which one did what). Both compilers have been fixed since then, but the code is still interesting due to it being: a) terse, and b) resulting in a unusually large number of [mostly useless] numeric computations that a C++ compiler yields by virtue of the template expansion. So I have retained a copy of the mischievous code. The template expansion is common in C++ template metaprogramming, and is extensively used in C++ scientific libraries (e.g. BLASS as well as in others). When it comes to the generated code footprint comparison, the numeric computations are a good metric to assess.

ansible 4y ago
I compiled that code with slight modifications (needed an actual func1 function) with a cross-compiler I had laying around into actual executables: cross g++ version 8.4.0 for aarch64: 13712 bytes native g++ version 11.3.0-3 for RV64GC: 13968 bytes ... but that includes a bunch of startup stuff, so that's not a good measure. Modifying the code to generate binary on godbolt: ARM64, 3816 bytes: https://godbolt.org/z/vn3de5nEc https://godbolt.org/z/vn3de5nEc RV64GC, 3226 bytes: https://godbolt.org/z/4ovMTaxo9 https://godbolt.org/z/4ovMTaxo9 So an 18% increase in code size for ARM 64-bit vs RISC-V 64-bit. As you can see in the generated code, there are 16-bit compressed instructions by default with the RV64GC binary.
- inkyoto 4y ago
  This is excellent, thank you. I was under the impression that the compressed instructions set required a dedicated compiler switch, and counted a number of instructions instead. Now that «X is 18% smaller than Y» is quantified, there is the circumstantial evidence, and it gives a clearer idea of the differences between two ISA's. Yet, it does not validate the absolutist and unquantifiable «awful code density» statement. I have also noted that compressed and uncompressed instructions are unevenly interleaved in the generated code, and occur in random sequences, i.e. addresses 0x10a60 ÷ 0x10a72 follow the 16-32-16-16-16-16-32-16 bit sequence whereas most other instructions follow 16-32 bit or 16-32-32 / 16-16-32 bit sequences. I wonder what performance penalty for the instruction decoding unit in hi-perf RISC-V cores is going to be for compressed vs uncompressed instructions code especially if the instruction being decoded spills over into the next L1 i-cache line (or, worse, into another memory page). RISC architectures are generally averse to misaligned memory access.