3 ms·

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

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.

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.