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

81–90 of 365 posts

Re: “Risc V greatly underperforms”

#81

Post by rbanffy »

robert_foss wrote: post #62
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…

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.

Re: “Risc V greatly underperforms”

#82

Post by waterhouse »

vitno wrote: post #65
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.

Any != All. There is a difference between synthetic benchmarks and real world test cases.

(RISC-V fan here) This is a real-world use case. GMP is a library for handling huge integers, and adding two huge integers is one of the operations it performs, and the way to do that is to add-with-carry one long sequence of word-sized integers into another. It's not synthetic; it's extremely specialized, but real.

Re: “Risc V greatly underperforms”

#83

Post by [deleted] »

nickez wrote: post #70
theresistor wrote: post #7

Earlier quoted context omitted.

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.

[deleted]

Re: “Risc V greatly underperforms”

#85

Post by vadfa »

nickez wrote: post #70
theresistor wrote: post #7

Earlier quoted context omitted.

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.

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?

Re: “Risc V greatly underperforms”

#86

Post by rbanffy »

yjftsjthsd-h wrote: post #78
gary_0 wrote: post #54

Earlier quoted context omitted.

I almost skipped this thread because of the flamebait title. This is a debate over CPU instruction set performance details, nobody is going to die.

In fairness, this is Hacker News; flame wars^w^w respectful but intense debate over editors, operating systems, and, yes, ISA details, is somewhat expected. (Although, yes, I'm not sure that I would get too worked up about this particular detail; even if the stated claim is 100% true and unmitigated, it means some kinds of code will have potentially bigger binaries. I understand a math library person caring, I don't…

> I understand a math library person caring, I don't think I care.

Not wasting much sleep on this one. Not sure there's anything on the spec that stops implementations from recognizing the two instructions and fuse them into a single atomic operation for the backends to deal with. It'll occupy more space in the L1 cache, but that's it.

Re: “Risc V greatly underperforms”

#87

Post by jolmg »

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…

I don't know what the design goals of RISC-V were, but I would guess performance is not the key goal or at least not the only goal. It makes more sense that ease of implementation is a more important goal, if they want to make adoption easy. That's another argument for favoring RISC over CISC.

Re: “Risc V greatly underperforms”

#88

Post by lottospm »

theresistor wrote: post #7
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…

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…

I'm not an expert on ISA and CPU internals, but an X86 instruction is not just "an instruction" anymore. Afaik, since the P6 arch Intel is using a fancy decoder to translate x86/-64 CISC into an internal RISC ISA (up to 4 u-ops per CISC instruction) and that internal ISA could be quite close to the RISC-V ISA for all I know.

Instruction decoding and memory ordering can be a bit of nightmare on CISC ISAs and fewer macro-instructions are not automatically a win. I guess we'll eventually see in benchmarks.

Even though Intel has had decades to refine their CPUs I'm quite excited to see where RISC-V is going.

Re: “Risc V greatly underperforms”

#89

Post by monocasa »

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…

If that's the case, you can always stick a uop cache in after the decoder.

Re: “Risc V greatly underperforms”

#90

Post by snvzz »

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…

Amount of instructions matters much less if they can be fused into more complex instructions before execution.

RISC-V was designed with hindsight on fusion, thus it has more opportunities for doing it, and doing it at a lower cost.

And, due to the very high code density RISC-V has, the decoder can do its job while not having to look at a huge window.

Post reply on HN