4 ms·
> […] aarch64's awful code density […] With all due respect, this is complete nonsense. You keep making this claim, yet have never produced any credible evide
by inkyoto 4y ago
> […] aarch64's awful code density […]
With all due respect, this is complete nonsense. You keep making this claim, yet have never produced any credible evidence other than a single bogus «ls -l /bin/bash» ages ago for three – x86, aarch64 and RISC-V (was it RISC-V 64 or 32?) – Linux distributions where the code was most likely compiled with «-O2 -g». If you want to substantiate your claim, you had better provide an objdump output for the _text/.text section that will reveal the actual (i.e. pure) code size footprint.
Let's pick this apart. The same random C++ code compiled with the same GCC v12.2.0 for 1) aarch64 (a generic 64-bit aarch64), 2) RISC-V (a generic 64-bit target), and let's also throw 3) POWER64 and 4) MIPS64 in for giggles:
– aarch64: https://godbolt.org/z/r4WPPj8nG https://godbolt.org/z/r4WPPj8nG
– RISC-V: https://godbolt.org/z/sr6nb8sTc https://godbolt.org/z/sr6nb8sTc
– ppc64: https://godbolt.org/z/PMrhe5W8z https://godbolt.org/z/PMrhe5W8z
– mips64: https://godbolt.org/z/sdKjncEfq https://godbolt.org/z/sdKjncEfq
If we filter out empty lines, labels, assembly pseudo-instructions and directives, we get the following results (in the ascending order) as the number of actual instructions for each ISA:
aarch64:
$ rg -cv '(^ *\.)|(^$)|(^[ A-Za-z0-9\(\)_]*:)' /tmp/meta.arm64-v8a.S
814
RISC-V 64-bit:
$ rg -cv '(^ *\.)|(^[ A-Za-z0-9\(\)_]*:)' /tmp/meta.risc-v.S
860
ppc64:
$ rg -cv '(^ *\.)|(^$)|(^[ A-Za-z0-9\(\)_]*:)' /tmp/meta.ppc64.S
945
mips64:
$ rg -cv '(^ *\.)|(^$)|(^[ A-Za-z0-9\(\)_]*:)' /tmp/meta.mips64.S
1030
aarch64 has, in fact, the lowest instruction footprint and came out at the top, with RISC-V trailing behind (but being comparable nevertheless). Surprisingly, ppc64 did more than 10% worse than aarch64, and mips64 came in last (unsurprisingly).
Conclusion: aarch64 does not possess the «awful code density» and is comparable to or better than that of the RISC-V 64-bit architecture.
- rwmj 4y agoNumber of assembly instructions is not strongly related to code density. In any case you need to look at dynamic code density to draw any conclusions about I$ pressure. Even if your comparison was valid, it is affected by the quality of the compiler - current compilers are not very good at exploiting RISC-V compressed instructions and generally have not had as much attention as on older architectures.
- inkyoto 4y agoAnd that is why I used the same compiler for all ISA's: gcc 12.2.0. The GIMPLE IR intermediate product is the same for all architectures; however, the ISA backend is specific to each ISA, so code generation peculiarities might or might not be an issue. GCC code output quality is above the average or high for all active mainstream architectures. Also, RISC-V compressed instructions are RISC-V 32-bit, therefore a comparison with 64-bit architectures is not applicable.
- cesarb 4y ago> Also, RISC-V compressed instructions are RISC-V 32-bit, therefore a comparison with 64-bit architectures is not applicable. No, both 32-bit and 64-bit RISC-V have compressed instructions, and they're nearly identical (IIRC, there's one compressed instruction which is different).
- photonbeam 4y agoDoes this account for the ubiquitous riscv compression extension?
- inkyoto 4y agoThe compression extension is RISC-V 32-bit. All code has been compiled for 64-bit architectures for a comparison.
- ansible 4y agoThat is not correct. Compressed instructions are available for 32-bit (RV32) and 64-bit (RV64). The compressed instructions differ slightly between the two though. See my other comment in this thread.
- inkyoto 4y agoI am more than happy to stand corrected, if a correction is warranted. What is the gcc 12.2.0 -march= value to make gcc 12.2.0 emit the compressed 64-bit code? The gcc 12.2.0 rejects all the -march RISC-V values the gcc documentation cites, e.g. rv64i is not accepted, and it is documented. I had presumed it was -march=rv64Zc[…], with […] being a combination of a/b/c/d/f/cmp/cmt, and neither of those was accepted. Also, according to https://wiki.riscv.org/display/HOME/Specification+Status https://wiki.riscv.org/display/HOME/Specification+Status, code size extensions are in a review state slated for a ratification in Q1 2023, with «ABI issues being worked» mentioned in the notes. My interpretation is that the compressed instructions extension is still work in progress, and is a moot point to discuss at this very moment.
- cesarb 4y ago> My interpretation is that the compressed instructions extension is still work in progress, and is a moot point to discuss at this very moment. The compressed instructions extension (the C extension) has been finished and standardized for a long time. In fact, all mainstream desktop Linux distributions which have ported to RISC-V have standardized on RV64GC (aka RV64IMAFDC, with the extensions I, M, A, F, D, C), that is, they require compressed instructions.
- snvzz 4y ago>yet have never produced any credible evidence other than a single bogus «ls -l /bin/bash» ages ago Wait WHAT? I strongly suspect you're confusing me with somebody else I am not. Please use `size` from binutils, if you're trying to compare code size of binaries.