Tuesday @ 1130 ISA Shootout – a Comparison of RISC V, ARM, and x86 Chris Celio, UC Berkeley V2
Why Hacker News recommends it
Cited as primary-source evidence that RISC-V code density is competitive with or better than ARM and x86.
What it is
Chris Celio of UC Berkeley compares the RISC-V, ARM and x86 instruction sets, with quantitative data on instruction counts and code density. It examines how the compressed extension fares against Thumb and x86.
Recommended by 2 HN commenters across 2 different months, 2016 to 2020.
What Hacker News said
Strong rec legulere · 2016-08 · on “Intel Licenses ARM Technology to Boost Foundry Business”
> If you look at functionality per instruction byte, RISC is fairly low. You should watch this video: [this video] The most important information therein is that the difference in code density is minuscule between x86, ARM and RISC-V. The differences between GCC versions is even bigger. > The equations that you have to resolve to issue an X86 instruction are simply more complex than for ARM, and all that bit-flipping consumes power. It's actually just 3-10% of power consumption [1] and I even heard it claimed that the instruction decoding on ARM is larger than x86 [1] [LINK]
Recommends dkjaudyeqooe · 2020-12 · on “Apple M1 foreshadows Rise of RISC-V”
At best, that's a simplistic and misleading view, see the following talk for an in depth analysis: "Comparison of RISC V, ARM, and x86" [this video]
Cites rwmj · 2016-12 · on “Ask HN: What's the value proposition of RISC-V?”
RISC-V has a compressed extension that compares favourably to even x86. See [this video] (bottom of the slide).
Cites nickik · 2017-12 · on “Boom v2: Open-source out-of-order RISC-V core [video]”
> because it turns out that getting high performance from an ISA with only simple and relatively large instructions is actually rather difficult That is not the reason. Its actually far easier to build a fast MISP or RISC-V Out-of-order CPU then it is a x86. Even if you do it for both the MIPS/RISC-V will run with lower energy and less area. If you look at a ISA countsy you will see that MISP on 64 Bit is not that far behind x86 and RISC-V is actually ahead in instruction count specially when including the C extension that is in the standard for the Linux ABI. See: [this video]
Cites nickik · 2018-07 · on “Ask HN: Does anyone have something negative to say about RISC-V?”
> poor vector instruction implementations All I have heard is that the people who know about vectors absolutely love the extension. Why is your problem with it? > bad code density That is just plain false. Its actually extremely good, RV32C and RV64C easily beat every other ISA. Even without the 'C' extension the difference to the other ISA are minimal. See: [this video] > The other general point I really dislike is their focus on ISA as if that matters so much compared to uArch. You don't like that the people who are designing an ISA focus on the ISA? That seems an incredible strange argument. It is well known and the RISC-V people often repeat that ISA don't matter much for performance. That's
Cites rwmj · 2018-11 · on “HiFive1 – Arduino RISC-V Dev Board”
Code density is claimed to be similar to x86 and better than ARM with thumb, see the bottom of this slide: [this video] More information on the original design (not quite the final design) of the Compressed extension can be found in the original research paper: [LINK] And ... SPARC. Seriously? Register windows were a failed experiment.
Cites microcolonel · 2019-02 · on “RISC-V on the Verge of Broad Adoption”
As of early 2016, with the GCC port at that time, RV32GC was as dense as Thumb, and RV64GC was denser than AArch64 and every other major 64-bit ISA, including AMD64. Though RV64G (no C) was in some extreme cases up to 50% larger than AArch64 (due to inlining memcpy and memset, which are a bit larger without compressed instructions), but usually around the same (except MIPS64, which is way larger than the other 64-bit ISAs, probably because of exposed delay slots). [0] There's some indication that density should have increased somewhat since then, but I haven't looked at it myself. [0]: [this video]