“Risc V greatly underperforms” • Hacker News Board

Re: “Risc V greatly underperforms”

#231

Post by mananaysiempre » Fri, Dec 03, 2021, 12:42 AM UTC

jaytaylor wrote: post #214

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…

I was surprised to find the top gOggle hits for "RISC-V fusion" (because I don't know WTF it even is) point to HN threads. Is this not discussed prominently elsewhere on the 'net? https://news.ycombinator.com/item?id=25554865 https://news.ycombinator.com/item?id=25554779 Is the Googrilla search engine really is starting to suck more and more, or is there something else going on in this case? The threads read more lik…

> ... is there something else going on in this case?

There is: the term comes from general CPU design terminology and is not specific to RISC-V, although Google does find some RISC-V-specific materials for me given your query[1–3]. Look for micro- and macro-op fusion in Agner Fog’s manuals[4] or Wikichip[5], for example.

[1]: https://riscv.org/wp-content/uploads/2016/07/Tue1130celio-fu...

[2]: https://reviews.llvm.org/D73643

[3]: https://erik-engheim.medium.com/the-genius-of-risc-v-micropr...

[4]: https://www.agner.org/optimize/#manuals

[5]: https://en.wikichip.org/wiki/macro-operation_fusion

Re: “Risc V greatly underperforms”

#232

Post by brucehoult » Fri, Dec 03, 2021, 12:45 AM UTC

masklinn wrote: post #121

smoldesu wrote: post #72

Earlier quoted context omitted.

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…

An actual arbitrary-precision library would have a lot of loops with loops control and load and stores. Those aren't shown here. Those will dilute the effect of a few extra integer ALU instructions in RISC-V.

Also, an high performance arbitrary-precision library would not fully propagate carries in every addition. Anywhere that a number of additions are being done in a row e.g. summing an array or series, or parts of a multiplication, you would want to use carry-save format for the intermediate results and fully propagate the carries only at the final step.

Re: “Risc V greatly underperforms”

#233

Post by brucehoult » Fri, Dec 03, 2021, 12:50 AM UTC

kccqzy wrote: post #226

Taniwha wrote: post #151

Earlier quoted context omitted.

you have to include the branch instruction too in any comparison

In x86 it is still one instruction: jc or jo after an addition.

And in RISC-V it's a "BLT sum,summand" after an unsigned addition, and a single branch instruction after a signed addition if you know the sign of one of them e.g. adding or subtracting a constant.

Re: “Risc V greatly underperforms”

#234

Post by kannanvijayan » Fri, Dec 03, 2021, 12:52 AM UTC

formerly_proven wrote: post #141

kannanvijayan wrote: post #73

Earlier quoted context omitted.

It kind of chafed when I excitedly read the ISA docs and found that overflow testing was cumbersome. That said, I think it's less of an issue these days for JS implementors in particular. It might have mattered more back in the day when pure JS carried a lot of numeric compute load and there weren't other options. These days it's better to stow that compute code in wasm and get predictable reliable performance and mo…

> It kind of chafed when I excitedly read the ISA docs and found that overflow testing was cumbersome. It just feels backwards to me to increase the cost of these checks in a time where we have realized that unchecked arithmetic is not a good idea in general.

I think I agree it was a mistake/wart. I can understand the frustration of the GMP dev in the text - they get hit hard by this. The omission feels arbitary and capricious and a bit ideologically motivated. The defense of the choice seems like post-hoc rationalization.

RiscV looks like a nice ISA otherwise.

I wouldn't be surprised if it was eventually extended to add a set of variant instructions that wrote flags to an explicitly specified register.

Re: “Risc V greatly underperforms”

#235

Post by SavantIdiot » Fri, Dec 03, 2021, 1:00 AM UTC

veltas wrote: post #202

SavantIdiot wrote: post #48

A bit off topic, but when did a DWORD implicitly become 64bits?

Lots of ISAs consider 32-bit to be a 'word'. And now they have the same problem that Intel already encountered that it's easier to start referring to a new larger native word size as a 'double-word' and the cycle continues...

Clearly I'm stuck in late-1980's-x86-ASM-land. BYTE, WORD, DWORD[, QWORD].

Re: “Risc V greatly underperforms”

#236

Post by __init » Fri, Dec 03, 2021, 1:01 AM UTC

cpeterso wrote: post #218

volta83 wrote: post #158

Earlier quoted context omitted.

The CPU executes the two (or more) dependent instructions "as if" they were one, e.g., in 1 cycle. The CPU has a frontend, which has a decoder, which is the part that "reads" the program instructions. When it "sees" certain pattern, like "instruction x to register r followed by instruction y consuming r", it can treat this "as if" it was a single instruction if the CPU has hardware for executing that single instructi…

Do RISC-V specs document which instruction combinations they recommend be fused? Sounds like the fused instructions are an implementation detail that must be well-documented for compiler writers to know to emit the magic instruction combinations.

It generally goes the other way around -- programmers and compilers settle on a few idiomatic ways to do something, and new cores are built to execute those quickly. Because RISC-V is RISC, it seems likely that those few ways would be less idiomatic and more 'the only real way to do x', which would aid in the applicability of the fusions.

Re: “Risc V greatly underperforms”

#237

Post by wyldfire » Fri, Dec 03, 2021, 1:01 AM UTC

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

Is it worth the encoding space to define new ALU instructions with overflow flag semantics? Or could there be an executive format that implies a different mode?

Re: “Risc V greatly underperforms”

#238

Post by phkahler » Fri, Dec 03, 2021, 1:12 AM UTC

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…

>> But ultimately, the gist of their argument is this...

Funny, I thought the whole thing was bitching that RISC V has no carry flag which obviously causes multi word arithmetic to take more instructions. The obvious workaround is to use half-words and use the upper half for carry. There may be better solutions, but at twice the number of instructions this "dumb" method is better than what the author did.

Flags were removed because they cause a lot of unwanted dependencies and contention in hardware designs and they aren't even part of any high level language.

I still think instead of compare-and-branch they should have made "if" which would execute the following instruction only if true. But that's just just an opinion. I also hate the immediate constants (12 bits?) Inside the instruction. Nothing wrong with 16 32 or 64bit immediate data after the opcode.

I hope RISC 6 will come along down the road (not soon) and fix a few things. But I like the lack of flags...

Re: “Risc V greatly underperforms”

#239

Post by adrian_b » Fri, Dec 03, 2021, 1:15 AM UTC

orra wrote: post #161

adrian_b wrote: post #96

Earlier quoted context omitted.

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

> 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 apples-to-oranges, because the compressed encoding will never have a performance in the same league with ARMv8-A.

When the comparisons are matched, 16-bit RISC-V encoding with 16-bit ARMv8-M and 32-bit RISC-V with 32-bit ARMv8-A, RISC-V always loses in code density in both comparisons, because only the RISC-V branch instructions are frequently shorter than those of ARM, while all the other instructions are frequently longer.

There are good reasons to use RISC-V for various purposes, where either the lack of royalties or the easy customization of the instruction set are important, but claiming that it should be chosen not because it is cheaper, but because it were better, looks like the story with the sour grapes.

The value of RISC-V is not in its instruction set, because there are thousands of people who could design better ISAs in a week of work.

What is valuable about RISC-V is the set of software tools, compilers, binutils, debuggers etc. While a better ISA can be done in a week, recreating the complete software environment would need years of work.

Re: “Risc V greatly underperforms”

#240

Post by adrian_b » Fri, Dec 03, 2021, 1:35 AM UTC

dragontamer wrote: post #110

adrian_b wrote: post #96

Earlier quoted context omitted.

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

> 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. Which isn't really a big advantage, because ARM and x86 macro-op fuse those instructions together. (That is, those 2-instructions are decoded and executed as 1x macro-op in practice). cmp /jnz on x86 is li…

The fusion influences only the speed, not the code size and the discussion was about the code size.

For x86, cmp/jnz must be 5 bytes for short loops or 9 bytes for long loops, because the REX prefix is normally needed. x86 does not have address modes with auto-update, like ARM or POWER, so for a minimum number of instructions the loop counter must also be used as an index register, to eliminate the instructions for updating the indices.

Because of that, the loop counter must use the full 64-bit register even if it is certain that the loop count would fit in 32-bit. That needs the REX prefix, so the fused instruction pair needs either 5 bytes (for 7-bit branch offsets) or 9 bytes, in comparison with 4 bytes for RISC-V.

So RISC-V gains 1 byte about at every 20 bytes from the branch instructions, i.e. about 5%, but then it loses more than this at other instructions so it ends at a code size larger than Intel/AMD by between 10% and 50%.