A Third World Embedded Engineer Responds to "RISC-V: They Should Have Known Better"
37 points by Corbin
37 points by Corbin
Hear hear. <3 Author, thank you for writing this!
I think a lot of the point is that, at some level, it doesn't really matter how good or bad an ISA is for a given task anymore. It does matter, but the delta between a good ISA and terribly mediocre one is really not so big that some hardware and software work can't overcome it. Sucks for the hardware or software makers sure, but the benefits of their work scale nearly indefinitely. The Ky X1 CPU on the Orange Pi RV2 might be 10% better or cheaper if it used an ISA better for big out-of-order chips, but... you can't buy those chips because they don't exist, so the 10% really doesn't matter to the end user. What does that 10% overhead buy you? The ability to use basically the same compilers, debuggers, docs, debugging hardware, etc for a huge variety of chips. That 10% overhead is apparently far, far less than the cost of ARM licensing.
Actual blog post submitted yesterday: https://lobste.rs/s/pu3yzg/risc_v_they_should_have_known_better
Shows a rate limit error for me (no VPN, residential connection).
I was (initially) so confused by this article as I missed the first one, and then misread the title as "A Third World Embedded Engineer Responds to RISC-V: They Should Have Known Better" - e.g. essentially picking up the title of the article it was rebutting.
I am a highly skilled reader :D
(There's a bit on x86 at that end :D)
That said it remains weird to me that people continue to put far so much emphasis on the ISA as the thing that determines "is this performance or is this lower power". The ISA itself has negligible impact on that. The implementation of the ISA is what drives it.
This is why Big.Little (or I thing on some Qualcomm cores: Big.Medium.Little?) is possible: it's the exact same ISA from the highest power to the lowest, and the size of the high performance variance is gigantic compared to the low power cores because the performance/power tradeoff is overwhelmingly the result of the implementation of the ISA.
Anything high power is going to have longer and wider pipelines, long OoO buffers, larger ücode catches, more complex ücode implementations, can fuse a wider array of üops, etc, etc. A low power variants does not need any of these at all.
At the very lowest end of the power spectrum code density starts to become a significant portion of total power usage than decoding. This is one of the reasons RISCV and ARM introduced 16bit instructions (note: RISCV does not have the arm 32bit alignment guarantees as the base unit of the ISA encoding is 16 bits) - the other reason of course being in low power environments you want minimal ram due to cost, capacity(In ultra low power environments SRAM is better, but limits available ram), and power usage (see footnote).
Anyway, once you're at this point the user facing ISA simply does not matter.
Footnote on x86:
You can of course design an ISA with the intent of making it expensive, and x86 is an example of an ISA that is expensive (though obviously not by intent) - the instruction decoding is unavoidably expensive (RISCV's variable length encoding includes the instruction length explicitly in the first packet of the instruction), and then has to converts the small number of registers into a ücode program operating on a larger set of registers.
But assuming you aren't in that position the relative cost is negligible.
Foot note on DRAM refresh power usage: In a laptop for example, while idle, with the screen on, dram refresh can exceed 10% of total power usage, in the deep sleep modes it generally exceeds 50% of the total power draw. I don't know the current LPDDR power usage, but back in the DDR4 generation going from 16-32gb of ram resulted in around a 30 to 45minute reduction in deep sleep battery life.
The ISA can have a big effect on performance in the medium-to-medium-high complexity range, before you get into "intel/amd/apple" implementation quality but after you have OoO and a complex cache hierarchy and instruction cracking/fusing and microcode etc. Mostly in terms of how painful it is on memory/cache pressure and how many weird pipeline stalls there are (that a sufficiently complex or sufficiently simple design would avoid). RV avoids a lot of weird pipeline stalls but then it turns around and makes a lot of cache-hostile decisions; lots of really common patterns that are super short in x86/64 and arm are really long in RV. When you dig into the specifics of these patterns, IMO it ends up not looking well-earned why they look the way they do instead of having shorter first-class features. It might be a strawman, but it looks like designing for "freshman academic toy (as in, literal bottom tier entry level)" MCUs that don't have the frontend features that even the weakest real-world deployed MCUs have (modern ones, not ones from 20+ years ago, and not weird task-specific chips like the ones for solar panel calculators) allowed weird imagined constraints to negatively affect the design of common features.
But it's not a BIG problem. It's basically marginal. It just looks bad. But IMO it really does look bad, and qualcomm's idea for how compressed instructions could have been done instead is an example of how much better the situation could have been. We could've had "almost-perfect ISA for every category", instead we have "different categories fighting for support and leading to weird compromises". Not having the next 2 shift-add sizes is an example of this. 16-byte arrays are super ultra incredibly common today, but RV has the same performance cliff between 8-byte and 16-byte array access that x86 has, for seemingly no good reason.
We always need more of this: positivity, perspective, and possibilities. This is how open source and royalty free wins. Let's build each other up and make something special with what we have, empowering people in all parts of the world. I'm excited to check out their videos and learn more about what they've been working on!
It just feels good, y'know?
This is a fantastic, articulate response that exhibits the kind of rhetorical good faith I criticized the original article for lacking.