Oh wow, everybody else is debating the specific intricacies of the design decisions, and I'm here wondering why you would complain about not enough instructions in an architecture with "RISC" in the name.
“Risc V greatly underperforms”
131–140 of 365 posts
Re: “Risc V greatly underperforms”
#132I 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…
> I 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. It's perfectly possible to have read the spec and disagree with the rationale provided. RISC-V is in fact the outlier among ISAs in many of these design decisions, so ther…
Perhaps thumb2 makes an 8-wide decide much harder. Plus, then you can't have 32 instead of 16 registers.
Re: “Risc V greatly underperforms”
#133I 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…
I am sorry but saying that RISC-V is a winner in code density is beyond ridiculous. I am familiar with many tens of instruction sets, since the first computers with vacuum tubes until all the important instruction sets that are still in use, and there is no doubt that RISC-V requires more instructions and a larger code size than almost all of them, for doing any task. Even the hard-to-believe "research" results publi…
> I am sorry but saying that RISC-V is a winner in code density is beyond ridiculous.
You have no idea what you're talking about. I've worked on designs with both ARM and RISC-V cores. The RISC-V code outperforms the ARM core, with smaller gate count, and has similar or higher code density in real world code, depending on the extensions supported. The only way you get much lower code density is without the C extension, but I haven't seen it not implemented in a real-world commercial core, and if it wasn't, I'm sure there was because of a benefit (FPGAs sometimes use ultra-simple cores for some tasks, and don't always care about instruction throughput or density)
It should be said that my experience is in embedded, so yes, it's unsafe code. But the embedded use-case is also the most mature. I wouldn't be surprised if extensions that help with safer programming languages would be added for desktop/server class CPUs, if they haven't already (I haven't followed the development of the spec that closely recently)
Re: “Risc V greatly underperforms”
#134A bit off topic, but when did a DWORD implicitly become 64bits?
I heard the bird was DWORD.
Re: “Risc V greatly underperforms”
#135Earlier quoted context omitted.
I don't think there is anything preventing the processor to fuse those instructions into a single operation once they are decoded.
Instruction fusion is the magical rescue invoked by all those who believe that the RISC-V ISA is well designed. Instruction fusion has no effect on code size, but only on execution speed. For example RISC-V has combined compare-and-branch instructions, while the Intel/AMD ISA does not have such instructions, but all Intel & AMD CPUs fuse the compare and branch instruction pairs. So there is no speed difference, but t…
> Even if instruction fusion can enable an adequate speed, implementing such decoders is more expensive than implementing decoders for an ISA that does not need instruction fusion for the same performance
On the other hand just splitting up x86 instructions is very expensive, and decoding in general takes a lot of work before you even start to do fancy tricks.
Re: “Risc V greatly underperforms”
#136What if the multi-precision code is written in C?
You can detect carry of (a+b) in C branch-free with: ((a&b) | ((a|b) & ~(a+b))) >> 31
So 64-bit add in C is:
f_low = a_low + b_low
c_high = ((a_low & b_low) | ((a_low | b_low) & ~f_low)) >> 31
f_high = a_high + b_high + c_high
add a1,a3,a2
or a5,a3,a2
not a7,a1
and a5,a5,a7
and a3,a3,a2
or a5,a5,a3
srli a5,a5,31
add a4,a4,a6
add a4,a4,a5
add ip, r2, r1
orr r3, r2, r1
and r1, r1, r2
bic r3, r3, ip
orr r3, r3, r1
lsr r3, r3, #31
add r2, r2, lr
add r2, r2, r3
Ah! But! There is a gcc macro: __builtin_uadd_overflow() that replaces the first two C lines above: c_high = __builtin_uadd_overflow(a_low, b_low, &f_low);
So with this:
RISC-V:
add a3,a4,a3
sltu a4,a3,a4
add a5,a5,a2
add a5,a5,a4 adds r2, r3, r2
movcs r1, #1
movcc r1, #0
add r3, r3, ip
add r3, r3, r1
EDIT: CLANG has one better: __builtin_addc().
f_low = __builtin_addcl(a_low, b_low, 0, &c);
f_high = __builtin_addcl(a_high, b_high, c, &junk);
addl 8(%rdi), %eax
adcl 4(%rdi), %ecx
adds w8, w8, w10
add w9, w11, w9
cinc w9, w9, hs
add a1, a4, a5
add a6, a2, a3
sltu a2, a2, a3
add a6, a6, a2Re: “Risc V greatly underperforms”
#137Earlier quoted context omitted.
I don't think there is anything preventing the processor to fuse those instructions into a single operation once they are decoded.
Instruction fusion is the magical rescue invoked by all those who believe that the RISC-V ISA is well designed. Instruction fusion has no effect on code size, but only on execution speed. For example RISC-V has combined compare-and-branch instructions, while the Intel/AMD ISA does not have such instructions, but all Intel & AMD CPUs fuse the compare and branch instruction pairs. So there is no speed difference, but t…
> Even if instruction fusion can enable an adequate speed, implementing such decoders is more expensive than implementing decoders for an ISA that does not need instruction fusion for the same performance
I'm very skeptical that a RISC-V decoder would be much more complex than an X86 one, even with instruction fusion. For the simpler fusion pairs, decoding the fused instructions wouldn't be more complex than matching some of the crazy instruction encoding in X86.
For ARM I'm not so sure, but RISC-V does have very significant instruction decoding benefits over ARM too, so my guess would be that they'd be similar enough.
Re: “Risc V greatly underperforms”
#138The original title was "Risc V greatly underperforms", which seems like a far more defensible and less inflammatory claim than "Risc V is a terrible architecture", which was picked from the actual message but still isn't the title.
I would say that "underperforms" is indefensible from such a simple analysis that doesn't touch IPC. "Terrible" is at least openly an opinion.
Re: “Risc V greatly underperforms”
#139Earlier quoted context omitted.
I don't think there is anything preventing the processor to fuse those instructions into a single operation once they are decoded.
Instruction fusion is the magical rescue invoked by all those who believe that the RISC-V ISA is well designed. Instruction fusion has no effect on code size, but only on execution speed. For example RISC-V has combined compare-and-branch instructions, while the Intel/AMD ISA does not have such instructions, but all Intel & AMD CPUs fuse the compare and branch instruction pairs. So there is no speed difference, but t…
>Unfortunately for RISC-V, this is the only example favorable for it, because for a large number of ARM or Intel/AMD instructions RISC-V needs a pair of instructions or even more instructions.
Yet, as many pointed out to you already, RISC-V has the highest code density of all contemporary 64bit architectures. And aarch64, which you seem to like, is beyond bad.
>but it is the only way available for RISC-V to match the speed of other CPUs.
Higher code density and lack of flags helps the decoder a big deal. This means it is far cheaper for RISC-V to keep execution units well fed. It also enables smaller caches and conversely higher clock speeds. It's great for performance.
This, if anything, makes RISC-V the better ISA.
>Even if instruction fusion can enable an adequate speed, implementing such decoders is more expensive than implementing decoders for an ISA that does not need instruction fusion for the same performance
Grasping at straws. RISC-V has been designed for fusion, from the get-go. The cost of doing fusion with it has been quoted to be as low as 400 gates. This is something you've been told elsewhere in the discussion, but that you chose to ignore, for reasons unknown.
Re: “Risc V greatly underperforms”
#140Hmmm... I think this argument is solid. Albeit biased from GMP's perspective, but bignums are used all the time in RSA / ECC, and probably other common tasks, so maybe its important enough to analyze at this level. 2-instructions to work with 64-bits, maybe 1 more instruction / macro-op for the compare-and-jump back up to a loop, and 1 more instruction for a loop counter of somekind? So we're looking at ~4 instructio…
Can you treat the whole vector register as a single bignum on x86? If so, I totally missed that.