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

171–180 of 365 posts

Re: “Risc V greatly underperforms”

#171

Post by hajile »

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

> Except for this good feature, the rest of the ISA is full of bad features What are your thoughts on the way RISC V handled the compressed instructions subset?

It's not too surprising. Load, store, move, add, subtract, shift, branch, jump. These are definitely the most common instructions used.

Put it side-by-side with Thumb and it also looks pretty similar (thumb has a multiply instruction IIRC).

Put it side-by-side with short x86 instructions accounting for the outdated ones and the list is pretty similar (down to having 8 registers).

All in all, when old and new instruction sets are taking the same approach, you can be reasonably sure it's not the absolute worst choice.

Re: “Risc V greatly underperforms”

#172

Post by jepler »

btdmaster wrote: post #128
theresistor wrote: post #76

Earlier quoted context omitted.

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

Unfortunately, it seems that, at least for gmp, the shared objects balloon in comparison to all other architectures. It is about three times bigger (6000 instead of 2000kB): https://packages.debian.org/sid/libgmp-dev . I am hopeful that this may improve with extensions, though I know little about the details.

       text    data     bss     dec     hex filename
     311218    2284      36  313538   4c8c2 arm-linux-gnueabihf/libgmp.so.10
     374878    4328      56  379262   5c97e riscv64-linux-gnu/libgmp.so.10
     480289    4624      56  484969   76669 aarch64-linux-gnu/libgmp.so.10
     511604    4720      72  516396   7e12c x86_64-linux-gnu/libgmp.so.10
Strange, that's not what I see.

Re: “Risc V greatly underperforms”

#173

Post by [deleted] »

audunw wrote: post #146
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).

Which is exactly the right trade-off for embedded CPUs, where RISC-V is most popular right now. If desktop/server-class RISC-V CPUs become more common, it's not unreasonable to think they'll add an extension that covers the needs of managed/higher-level languages like RISC-V. Even for server-class CPUs you could argue that you absolutely want this extension to be optional, as you can design more efficient CPUs for da…

[deleted]

Re: “Risc V greatly underperforms”

#174

Post by voz_ »

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

> I am sorry but saying that RISC-V is a winner in code density is beyond ridiculous. You have no idea what you're talking about. I've worked on designs with both ARM and RISC-V cores. The RISC-V code outperforms the ARM core, with smaller gate count, and has similar or higher code density in real world code, depending on the extensions supported. The only way you get much lower code density is without the C extensio…

Textbook example of the kind of hostility and close-mindedness that is creeping into our beloved site. Why are we dick measuring? why are we comparing experience like this? so much "I" "I" "I"...

I have no horse in the technical race here, but I certainly am put off from reading what should be an intellectually stimulating discussion by the nature of replies like this.

Re: “Risc V greatly underperforms”

#175

Post by jasonhansel »

theresistor wrote: post #102
lottospm wrote: post #88

Earlier quoted context omitted.

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

As someone who is an expert on ISA and CPU internals, this meme of "X86 has an internal RISC" is an over-simplification that obscures reality. Yes, it decodes instructions into micro-ops. No, micro-ops are not "quite close to the RISC-V ISA". Macro fusion definitely has a place in microarchitecture performance, especially when you have to deal with a legacy ISA. RISC-V makes the very unusual choice of depending on it…

Indeed. Also not an expert, but relying on macro-op fusion in hardware is tricky IIRC since different implementors will (likely) choose different macro-ops, resulting in strange performance differences between otherwise-identical chips.

Of course, you could start documenting "official" macro-ops that implementations should support, but at that point you're pretty much inventing a new ISA...

Re: “Risc V greatly underperforms”

#176

Post by lonjil »

Dylan16807 wrote: post #164
lonjil wrote: post #153

Earlier quoted context omitted.

Thumb has both 16-bit and 32-bit instructions.

Oh, you meant thumb and thumb-2.

"thumb-2" isn't really a thing. It's just an informal name from when more instructions were being added to thumb. it's still just thumb.

Re: “Risc V greatly underperforms”

#177

Post by socialdemocrat »

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

Fusing 3 instructions is not unusual, those could also have been compressed. Thus you have no more microcode to execute and only 50% more cache usage rather than 300%

Re: “Risc V greatly underperforms”

#178

Post by socialdemocrat »

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

x86 also does macro fusion. Difference is RISC-V was designed for compressed instruction and fusion from the get go. X86 bolted this on.

Anyway what you gain from this is a very simple ISA, which helps tool writers, those who implement hardware as well in academia for teaching and research.

How does the insanely complex x86 instructions help anyone?

Re: “Risc V greatly underperforms”

#179

Post by snvzz »

voz_ wrote: post #174
audunw wrote: post #133

Earlier quoted context omitted.

> I am sorry but saying that RISC-V is a winner in code density is beyond ridiculous. You have no idea what you're talking about. I've worked on designs with both ARM and RISC-V cores. The RISC-V code outperforms the ARM core, with smaller gate count, and has similar or higher code density in real world code, depending on the extensions supported. The only way you get much lower code density is without the C extensio…

Textbook example of the kind of hostility and close-mindedness that is creeping into our beloved site. Why are we dick measuring? why are we comparing experience like this? so much "I" "I" "I"... I have no horse in the technical race here, but I certainly am put off from reading what should be an intellectually stimulating discussion by the nature of replies like this.

It was likely instigated by its parent trying to inflate himself by giving themselves some credentials, to try and give their voice more weight.

All of it, pretty sad, but I believe we should focus on the technical arguments and try to put everything else aside in order to re-conduct the discussion somewhere more useful.

Re: “Risc V greatly underperforms”

#180

Post by snvzz »

pierrebai wrote: post #170
justinpombrio wrote: post #148

Earlier quoted context omitted.

So (i) the research on RISC-V that shows it has dense code is bunk, and (ii) the fact that it compiles to a smaller binary is irrelevant, and (iii) it sounds like you're saying in advance that it might also have smaller code section sizes within the binary but that's irrelevant too. And yet you're quite confident that RISC-V has poor code density. So you clearly have a source of knowledge that others don't. If it's a…

Re-read what was written. He is saying exactly that the RISCV code size is larger, but to see it you need the right tool used the right way to actually look at the code, not debug info, constant sections, etc.

I would hope there's something more to his reasoning.

There's tables showing values for just the code and RISC-V beating aarch64 and x86-64 with ample margin, in this very discussion.

Post reply on HN