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

251–260 of 365 posts

Re: “Risc V greatly underperforms”

#251

Post by mlyle »

adrian_b wrote: post #154
zozbot234 wrote: post #29

Earlier quoted context omitted.

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

Any hardware adder provides almost for free the overflow detection output (at less than the cost of an extra bit, so less than 1/64 of a 64-bit adder). So anyone who thinks about an efficient hardware implementation would expose the overflow bit to the software. A hardware implementation that requires multiple additions to provide the complete result of a single addition can be called in many ways, but certainly not…

> A hardware implementation that requires multiple additions to provide the complete result of a single addition can be called in many ways, but certainly not "efficient".

1. There's not multiple additions in the recommended sequences. Unsigned is add,bltu; Signed with one known sign is add, blt; Signed in general is add, slt, slti, bne.

2. These instruction sequences are specified so that an instruction decoder can treat these sequences following the add as a "very wide" instruction specifying to check an overflow flag, if a hardware implementation so chooses.

Re: “Risc V greatly underperforms”

#252

Post by kazinator »

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…

> It is enough to grab any Linux distribution that supports RISC-V and look at the size of the binaries across architectures.

Also, the godbolt.org compiler explorer has Risc-V support: useful for someone interested in comparing specific snippets of code.

Re: “Risc V greatly underperforms”

#253

Post by kazinator »

Godbolt:

  typedef __int128_t int128_t;

  int128_t add(int128_t left, int128_t right)
  {
    return left + right;
  }
GCC 10, -O2, RISC-V:

  add(__int128, __int128):
        mv      a5,a0
        add     a0,a0,a2
        sltu    a5,a0,a5
        add     a1,a1,a3
        add     a1,a5,a1
        ret
ARM64:

  add(__int128, __int128):
        adds    x0, x0, x2
        adc     x1, x1, x3
        ret
This issue hurts the wider types that are compiler built-ins.

Even though C has a programming model that is devoid of any carry flag concept, canned types like a 128 bit integer can take advantage of it.

Portable C code to simulate a 128 bit integer will probably emit bad code across the board. The code will explicitly calculate the carry as an additional operand and pull it into the result. The RISC-V won't look any worse, then, in all likelihood.

(The above RISC-V instruction set sequence is shorter than the mailing list post author's 7 line sequence because it doesn't calculate a carry out: the result is truncated. You'd need a carry out to continue a wider addition.)

Re: “Risc V greatly underperforms”

#256

Post by [deleted] »

adrian_b wrote: post #239
orra wrote: post #161

Earlier quoted context omitted.

> the so-called better results were for the compressed extension, not for the normal encoding. Ignoring RISC-V’s compressed encoding seems a rather artificial restriction.

The compressed encoding has good code density, but low speed. The compressed RISC-V encoding must be compared with the ARMv8-M encoding not with the ARMv8-A. The base 32-bit RISC-V encoding may be compared with the ARMv8-A, because only it can have comparable performance. All the comparisons where RISC-V has better code density compare the compressed encoding with the 32-bit ARMv8-A. This is a classical example of ap…

[deleted]

Re: “Risc V greatly underperforms”

#257

Post by rurban »

masklinn wrote: post #130
Taniwha wrote: post #116

Earlier quoted context omitted.

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.

built-in support for overflow is not really builtin. There's only adc, but the C library has no such function, and compilers only got them added a few years ago. Almost nobody uses them, as they introduce a dependency. Most workaround that in much slower ways, worse than RISC-V

Re: “Risc V greatly underperforms”

#258

Post by monocasa »

TheCondor wrote: post #197
ncmncm wrote: post #191

Earlier quoted context omitted.

No. Mentioning it is only meant to distract.

Is there a semi competitive Risc-V core implemented anywhere? It all seem hypothetical to me now, fast cores would fuse the instructions together so instruction count alone isn't adequate for the original evaluation of the ISA. Now I'm not sure that there are any that really do that..

BOOM cores fuse ops already, so the cores don't have to be all that fast to start to see wins from it.

Re: “Risc V greatly underperforms”

#260

Post by titzer »

aidenn0 wrote: post #143
sanxiyn wrote: post #6

Earlier quoted context omitted.

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

Over just the time I've been aware of things, there's been a constant positive feedback loop of "checked overflow isn't used by software, so CPU designers make it less performant" followed by "Checked overflow is less performant so software uses it less." I wish there was a way out. Language features are also often implemented at least partly because they can be done efficiently on the premiere hardware for the langu…

> WASM implemented return values in a way that was different from register hardware, and it makes efficient codegen of Common Lisp more challenging. This was brought to the attention of the committee while WASM was still in flux, and they (perhaps rightfully) decided CL was insufficiently important to change things.

Can you refresh my memory here? What exactly is different about Wasm return values than any other function-oriented language?

Post reply on HN