Rather than glib hand-waving in front of the chalkboard...might there be a decent piece or few of RISC V hardware, which could actually be compared to non-RISC V hardware with similar budgets (for design work, transistor count, etc.) - to see how things work out when running substantial pieces of decently-compiled code?
“Risc V greatly underperforms”
61–70 of 365 posts
Re: “Risc V greatly underperforms”
#62I don't think they even tried to read the ISA spec documents. If they did, they would have found that the rationale for most of these decisions is solid: Evidence was considered, all the factors were weighted, and decisions were made accordingly. But ultimately, the gist of their argument is this: >Any task will require more Risc V instructions that any contemporary instruction set. Which is easy to verify as utter n…
So how would you suggest re-writing their example in less than 6 instructions for RISC-V? X86/arm both have instructions that include the carry operation for long additions, and only require 2 instructions.
Re: “Risc V greatly underperforms”
#63So this is one tiny corner of the ISA, not something that makes ALL instruction sequences longer - essentially RISCV has no condition codes (they're a bit of an architectural nightmare for everyone doing any more than the simplest CPUs, they make every instruction potentially have dependencies or anti-dependencies with every other). It's a trade off - and the one that's been made is one that makes it possible to make…
You can opt in to generating and propagating conditions and rename the predicates as well.
Re: “Risc V greatly underperforms”
#64Doesn't RISC-V have an add-with-carry instruction as part of the vector extension? I see it listed here: https://github.com/riscv/riscv-v-spec/releases/tag/v1.0
Afaict that's only for operations the vector register file. Most of the complaints about the lack of addc/subc are around how they're heavily used in JITs for languages that want to speculatively optimize multi precision arthimetic into the integer register file for their regular integer ops. JavaScript, a lot of Lisps, the MLs all fit into that space.
Re: “Risc V greatly underperforms”
#65I don't think they even tried to read the ISA spec documents. If they did, they would have found that the rationale for most of these decisions is solid: Evidence was considered, all the factors were weighted, and decisions were made accordingly. But ultimately, the gist of their argument is this: >Any task will require more Risc V instructions that any contemporary instruction set. Which is easy to verify as utter n…
So how would you suggest re-writing their example in less than 6 instructions for RISC-V? X86/arm both have instructions that include the carry operation for long additions, and only require 2 instructions.
Any != All. There is a difference between synthetic benchmarks and real world test cases.
Re: “Risc V greatly underperforms”
#66Doesn't RISC-V have an add-with-carry instruction as part of the vector extension? I see it listed here: https://github.com/riscv/riscv-v-spec/releases/tag/v1.0
Afaict that's only for operations the vector register file. Most of the complaints about the lack of addc/subc are around how they're heavily used in JITs for languages that want to speculatively optimize multi precision arthimetic into the integer register file for their regular integer ops. JavaScript, a lot of Lisps, the MLs all fit into that space.
Sure, but this email is in the context of GMP, which should be using the vector extension, no?
Re: “Risc V greatly underperforms”
#67Earlier quoted context omitted.
Even if you do so, the program size is still bigger, and it consumes more disk, RAM and most importantly cache space. Wasting cache for having multiple instructions when on another architecture it's done by only one doesn't make particular sense to me. Also, it's said that x86 is bad because the instructions are then reorganized and translated inside the CPU. But it seems that you are proposing the same, the CPU that…
How many cache misses are for program instructions, versus data misses?
Depends on the application. But even if they are few, it's not a good reason to have them just for having a nice instruction set, that if you are not writing assembly by hand (and nobody does these days) doesn't give you any benefit.
Also don't reason with the desktop or server use case in mind, where you have TB of disk and code size doesn't matter. RISC-V is meant to be used also for embedded systems (in fact their use nowadays is only for these systems), where usually code size matter more than performance (i.e. you typically compile with -Os). In these situations more instructions means more flash space wasted, meaning you can fit less code.
Re: “Risc V greatly underperforms”
#68The unwritten rule of HN:
You do not criticise The Rusted Holy Grail and the Riscy Silver Bullet.
Re: “Risc V greatly underperforms”
#69A bit of a computer history question: I have never looked at the ISA of the Alpha (referenced in post), but RISC V has always struck me as being nearly identical to (early) MIPS, just without the HI and LO registers for multiply results and the addition of variable length instruction support, even if the core ISA doesn't use them. MIPS didn't have a flag register either and depended on a dedicated zero register and s…
[deleted]
Re: “Risc V greatly underperforms”
#70So this is one tiny corner of the ISA, not something that makes ALL instruction sequences longer - essentially RISCV has no condition codes (they're a bit of an architectural nightmare for everyone doing any more than the simplest CPUs, they make every instruction potentially have dependencies or anti-dependencies with every other). It's a trade off - and the one that's been made is one that makes it possible to make…
This isn't an isolated case. RISC-V makes the same basic tradeoff (simplicity above all else) across the board. You can see this in the (lack of) addressing modes, compare-and-branch, etc. Where this really bites you is in workloads dominated by tight loops (image processing, cryptography, HPC, etc). While a microarchitecture may be more efficient thanks to simpler instructions (ignoring the added complexity of compr…
For those use cases you typically have specialised hardware or an FPGA.