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

91–100 of 365 posts

Re: “Risc V greatly underperforms”

#91

Post by roca »

sanxiyn wrote: post #6
Taniwha wrote: post #3

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

RISC-V designers optimized for C and found overflow flag isn't used much and got rid of it. It was the wrong choice: overflow flag is used a lot for JavaScript and any language with arbitrary precision integer (including GMP, the topic of OP).

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.

Re: “Risc V greatly underperforms”

#92

Post by xiphias2 »

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…

A company creating embedded risc-v cpus also has some added extra instruction set extensions that conflict with the floating point instructions though.

Re: “Risc V greatly underperforms”

#94

Post by userbinator »

Teknoman117 wrote: post #17

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

Yes, that's exactly my thought every time it comes out; RISC-V is likely to displace MIPS everywhere performance doesn't matter, but it'll have a hard time competing with ARM or x86 on that.

Re: “Risc V greatly underperforms”

#95

Post by rbanffy »

meepmorp wrote: post #27
sosodev wrote: post #12

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

It's not a "slam piece," it's an email from a listserv, send two months ago. Someone realized it'd be catnip for people on HN and posted it.

It's not even a rock-solid critique...

Re: “Risc V greatly underperforms”

#96

Post by adrian_b »

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 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 published by RISC-V developers have always showed worse code density than ARM, the so-called better results were for the compressed extension, not for the normal encoding.

Moreover, the results for RISC-V are hugely influenced by the programming language and the compiler options that are chosen. RISC-V has an acceptable code size only for unsafe code, if the programming language or the compiler options require run-time checks, to ensure safe behavior, then the RISC-V code size increases enormously, while for other CPUs it barely changes.

The RISC-V ISA has only 1 good feature for code size, the combined compare-and-branch instructions. Because there typically is 1 branch for every 6 to 8 instructions, using 1 instruction instead of 2 saves a lot.

Except for this good feature, the rest of the ISA is full of bad features, which frequently require at least 2 instructions instead of 1 instruction in any other CPU, e.g. the lack of indexed addressing, which is needed in any loop that must access some aggregate data structure, in order to be able to implement the loop with a minimum number of instructions.

Re: “Risc V greatly underperforms”

#97

Post by theresistor »

theresistor wrote: post #80
jolmg wrote: post #75

Earlier quoted context omitted.

I don't even see the issue. RISC-V is supposed to be a RISC-type ISA. It's in the very name. That it takes more instructions when compared to a CISC-type ISA like x86 is completely normal. https://en.wikipedia.org/wiki/Reduced_instruction_set_comput...

The argument for RISC instructions (in high performance architectures) is that the faster decode makes up for the increase in instruction count. The problem is that a faster decode has a practical ceiling on how much faster it's going to make your processor, and it's much lower than 3x. If your workload is bottlenecked on an inner loop that got 3x larger in instruction count, no 15% improvement in decode performance…

To everyone who's saying "But macro-fusion!" in response, see my comment here: https://news.ycombinator.com/item?id=29421107

Re: “Risc V greatly underperforms”

#98

Post by rbanffy »

rm445 wrote: post #24
sosodev wrote: post #12

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

Yeah. I'm not qualified to judge the quality of an instruction set, but this writer destroyed all credibility with me by claiming that an undergraduate could design a better architecture (than this enormous collective effort) in a term. It's right up there with claiming you could create Spotify in a weekend or whatever.

I designed an ISA (and a CPU) as an undergrad, and I assure you that, while it was very cool (stack-oriented, ASM looked like Forth), it'd have horrendous performance these days.

Re: “Risc V greatly underperforms”

#99

Post by lordnacho »

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.

How does the instruction fusion work? It seems to be mentioned in the article and by a couple of other commenters.

Re: “Risc V greatly underperforms”

#100

Post by userbinator »

theresistor wrote: post #80
jolmg wrote: post #75

Earlier quoted context omitted.

I don't even see the issue. RISC-V is supposed to be a RISC-type ISA. It's in the very name. That it takes more instructions when compared to a CISC-type ISA like x86 is completely normal. https://en.wikipedia.org/wiki/Reduced_instruction_set_comput...

The argument for RISC instructions (in high performance architectures) is that the faster decode makes up for the increase in instruction count. The problem is that a faster decode has a practical ceiling on how much faster it's going to make your processor, and it's much lower than 3x. If your workload is bottlenecked on an inner loop that got 3x larger in instruction count, no 15% improvement in decode performance…

Larger caches won't help much either; there's an old article I remember that compares the efficiency of various ARM, x86, and one MIPS CPU, and while x86 and ARM were neck-and-neck, the MIPS was dead last in all the comparisons despite having more cache than the others. RISC-V is very similar to MIPS.
Post reply on HN