Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“Risc V greatly underperforms”

gmplib.org

Post reply on HN
Print view View original

121–130 of 365 posts

Re: “Risc V greatly underperforms”

#121

Post by masklinn »

smoldesu wrote: post #72
robert_foss wrote: post #62

Earlier quoted context omitted.

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.

I don't think you're supposed to. The compiler handles that stuff, ideally RISC-V is just another compilation target.

Did you misunderstand the issue entirely?

The context here is the implementation of one of the inner loops of a high-performance infinite-precision arithmetic library (GMP), in RISCV the loop has 3x the instruction count it has in competing architectures.

“The compiler” is not relevant, this is by design stuff that the compiler is not supposed to touch because it’s unlikely to have the necessary understanding to get it as tight and efficient as possible.

Re: “Risc V greatly underperforms”

#122

Post by lvh »

vadfa wrote: post #85
nickez wrote: post #70

Earlier quoted context omitted.

For those use cases you typically have specialised hardware or an FPGA.

So when h266 or whatever comes out you can't watch video anymore because your cpu can't decode it in software even if it tried?

An FPGA can be reprogrammed, and we do really do this for standards with better longevity than video standards (e.g. cryptographic ones like AES and SHA). For standards like video codecs, we just use GPUs instead, which I assume is what OP had in mind for "specialized hardware" (specialization can still be pretty general :-)).

Re: “Risc V greatly underperforms”

#123

Post by Taniwha »

theresistor wrote: post #115
snvzz wrote: post #109

Earlier quoted context omitted.

You seem to be making your whole argument around some facts which you got wrong. The central points of your argument are often used in FUD, thus they are definitely worth tackling here. >Even the hard-to-believe "research" results published by RISC-V developers have always showed worse code density than ARM the code size advantage of RISC-V is not artificial academic bullshit. It is real, it is huge, and it is trivia…

> This is in stark contrast with ARMv7's thumb, which was a literal separate CPU mode. This is disingenuous. arm32's Thumb-2 (which has been around since 2003) supports both 16-bit and 32-bit instructions in a single mode, making it directly comparable to RV32C.

The main distinction is that the 16-bit RISCV-C ISA exactly maps to existing 32-bit RISCV instructions, its implementation only occurs in the decode pipe stage

Re: “Risc V greatly underperforms”

#124

Post by boibombeiro »

bob1029 wrote: post #19
sosodev wrote: post #12

Why do these half baked slam pieces always make it to the top of HN?

I think the reason is that it ultimately encourages deep and thoughtful conversation. If nothing controversial was ever proposed, the motivation for participating and "proving others wrong" is lessened. It might not be the healthiest way, but I certainly find myself putting a lot more thought into my comments if its a contrary point or in some broader controversial context. Overall, I feel HN is most fun when a lot o…

Standing ground, specially when we are wrong, helps to learn a lot more about the subject.

Re: “Risc V greatly underperforms”

#125

Post by audunw »

snvzz wrote: post #34

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. 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…

Yeah, I'm not sure he takes into considered compressed instructions, which can be used anywhere, rather than being a separate mode like Thumb on ARM.

Fusing instructions isn't just theoretical either. I'm pretty sure it is or will be a common optimisation for CPUs aiming for high performance. How exactly is two easily-fused 16-bit instructions worse than one 32-bit one? Is there really a practical difference other than the name of the instruction(s)?

At the same time, the reduced transistor count you get from a simpler instruction set is not a benefit to be just dismissed either. I'm starting to see RISC-V cores being put all over the place in complex microcontrollers, because they're so damn cheap, yet have very decent performance. I know a guy developing a RISC-V core. He was involved with the proposal for a couple of instructions that would put the code density above Thumb for most code, and the performance of his core was better than Cortex-M0 at a similar or smaller gate count. I'm not sure if the instructions was added to the standard or not though.

Even for high performance CPUs, there's a case to be made for requiring fewer transistors for the base implementation. It makes it easier to make low-power low-leakage cores for the heterogeneous architecture (big.little, M1, etc.) which is becoming so popular.

Re: “Risc V greatly underperforms”

#126

Post by adrian_b »

rbanffy wrote: post #81
robert_foss wrote: post #62

Earlier quoted context omitted.

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.

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 the separate compare and branch instructions of Intel/AMD remain longer at 5 bytes, instead of the 4 bytes of RISC-V.

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.

Fusing instructions will not help RISC-V with the code density, but it is the only way available for RISC-V to match the speed of other CPUs.

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

Re: “Risc V greatly underperforms”

#128

Post by btdmaster »

theresistor wrote: post #76
snvzz wrote: post #34

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. 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…

Unfortunately, it seems that, at least for gmp, the shared objects balloon in comparison to all other architectures. It is about three times bigger (6000 instead of 2000kB): https://packages.debian.org/sid/libgmp-dev. I am hopeful that this may improve with extensions, though I know little about the details.

Re: “Risc V greatly underperforms”

#129

Post by lonjil »

snvzz wrote: post #120
theresistor wrote: post #115

Earlier quoted context omitted.

> This is in stark contrast with ARMv7's thumb, which was a literal separate CPU mode. This is disingenuous. arm32's Thumb-2 (which has been around since 2003) supports both 16-bit and 32-bit instructions in a single mode, making it directly comparable to RV32C.

Your statement does not run counter to mine quoted. Thumb-2 is better designed than Thumb was, but it is still a separate CPU mode. And it got far less use than it deserved, because of this. It doesn't do everything, and switching has a significant cost. This cost is in contrast with RISC-V's C extension.

The ARMv8-M profile is Thumb-only, so on ARM microcontroller platforms there is no switching at all, and it does do everything, or at least everything you might want to do on a microcontroller, and has of course gotten a very large amount of use, considering how widely deployed those cores are.

Re: “Risc V greatly underperforms”

#130

Post by masklinn »

Taniwha wrote: post #116
roca wrote: post #91

Earlier quoted context omitted.

Also Rust applications are increasingly going to be built with integer overflow checking enabled, e.g. Android's Rust components are going to ship with integer overflow checking. And unlike say GMP, that poses a potential code density problem because we're not talking about inner loops that can be effectively cached, it's code bloat smeared across the entire binary.

Yeah but the code required for an overflow check is just one extra instruction (3 rather than 2)

For generalised signed addition, the overhead is 3 instructions per addition. It can be one in specific contexts where more is known about the operands (e.g. addition of immediates).

It’s always 1 in x64/ARM64 as they have built-in support for overflow.

Post reply on HN