2 HN users recommended this talk2 months2016–2020score 2.5
Years with an HN recommendation, 2007–2026
Cited as primary-source evidence that RISC-V code density is competitive with or better than ARM and x86.
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.
> 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]
Shows code density differences among x86, ARM and RISC-V are minuscule.
> 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]
> 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 why it makes 0 sense not to have an open one that is not restricted so that you can have competition and open source implementations.
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.
Slide showing code density similar to x86 and better than Thumb.
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]
Source for RV64GC density versus AArch64 and AMD64.
Video list and Hacker News comment labels from HackerTube (prompted by @karpathy), released under ODC-By 1.0, built on the open-index/hacker-news archive. Hacker News data is provided by Y Combinator; comments remain the work of their authors. Video titles, channel names and thumbnails belong to their creators and are shown via YouTube. HackerTube Watch is an unofficial edition. Data export of 2026-10-31.
Plays via YouTube's privacy-enhanced embed
7 Hacker News comments
From the HN archive; up to 20 kept per video, favoring different commenters. Recommendations first.
Citations, criticism and jokes
Read more