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

21–30 of 365 posts

Re: “Risc V greatly underperforms”

#21

Post by okl »

jpfr wrote: post #2

The idea is to use the compressed instruction extension. Then two adjacent instructions can be handled like a single “fat” instruction with a special case implementation. That allows more flexibility for CPU designs to optimize transistor count vs speed vs energy consumption. This guy clearly did not look at the stated rationale for the design decisions of RISC-V.

Sweet spot seems to be 16-bit instructions with 32/64-bit registers. With 64-bit registers you need some clever way to load your immediates, e.g., like the shift/offset in ARM instructions.

Re: “Risc V greatly underperforms”

#24

Post by rm445 »

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.

Re: “Risc V greatly underperforms”

#25

Post by nynx »

kayamon wrote: post #18
nynx wrote: post #10

If this really is an issue, I imagine risc-v could easily get an extension for adding/subtracting/etc simd vectors together in a way that would expand to the capabilities of underlying processor without requiring hardcoding.

It already has this.

Yes, the simd extension has the flexible vectors thing. I don't think it has a way to treat simd vectors as bigints.

Re: “Risc V greatly underperforms”

#26

Post by CalChris »

TL;DR

  My code snippet results in bloated code for RISC-V RV64I.
I'm not sure how bloated it is. All of those instructions will compress [1].

[1] https://riscv.org/wp-content/uploads/2015/05/riscv-compresse...

It's slower on RISC-V but not a lot on a superscalar. The x86 and ARMv8 snippets have 2 cycles of latency. The RISC-V has 4 cycles of latency.

  1. add  t0, a4, a6  add  t1, a5, a7
  2. sltu t6, t0, a4  sltu t2, t1, a5
  3. add  t4, t1, t6  sltu t3, t4, t1
  4.                  add  t6, t2, t3
I'm not getting terrible from this.

Re: “Risc V greatly underperforms”

#28

Post by msbarnett »

jpfr wrote: post #2

The idea is to use the compressed instruction extension. Then two adjacent instructions can be handled like a single “fat” instruction with a special case implementation. That allows more flexibility for CPU designs to optimize transistor count vs speed vs energy consumption. This guy clearly did not look at the stated rationale for the design decisions of RISC-V.

He literally addressed this, albeit obliquely, in the message

> I have heard that Risc V proponents say that these problems are known and could be fixed by having the hardware fuse dependent instructions. Perhaps that could lessen the instruction set shortcomings, but will it fix the 3x worse performance for cases like the one outlined here?

Macro-fusion can to some extent offset the weak instruction set, but you're never going to get a multiple integer multiplier speedup out of it given the complexity of inter-op architectural state changes that have to be preserved, and instruction boundary limitations involved; it's never going to offset a 3x blowup in instruction count in a tight loop.

Re: “Risc V greatly underperforms”

#29

Post by zozbot234 »

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

They provide recommended insn sequences for overflow checking as commentary to the ISA specification, and this enables efficient implementation in hardware.

Re: “Risc V greatly underperforms”

#30

Post by alerighi »

jpfr wrote: post #2

The idea is to use the compressed instruction extension. Then two adjacent instructions can be handled like a single “fat” instruction with a special case implementation. That allows more flexibility for CPU designs to optimize transistor count vs speed vs energy consumption. This guy clearly did not look at the stated rationale for the design decisions of RISC-V.

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 preprocessed the instructions and fuses some into a single one (the opposite that x86 does). Ad that point, it seems to me that what x86 does makes more sense: have a ton of instruction (and thus smaller programs and thus more code that can fit in cache) and split them, rather than having a ton of instructions (and waste cache space) for then the CPU to combine them into a single one (a thing that a compiler can also do).

Post reply on HN