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

161–170 of 365 posts

Re: “Risc V greatly underperforms”

#161

Post by orra »

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

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.

Re: “Risc V greatly underperforms”

#162

Post by socialdemocrat »

adrian_b wrote: post #126
rbanffy wrote: post #81

Earlier quoted context omitted.

I don't think there is anything preventing the processor to fuse those instructions into a single operation once they are decoded.

Instruction fusion is the magical rescue invoked by all those who believe that the RISC-V ISA is well designed. Instruction fusion has no effect on code size, but only on execution speed. For example RISC-V has combined compare-and-branch instructions, while the Intel/AMD ISA does not have such instructions, but all Intel & AMD CPUs fuse the compare and branch instruction pairs. So there is no speed difference, but t…

You ignore compressed instructions on RISC-V which 64-bit ARM does not have.

And if you compare 32-bit CPUs then RISC-V has twice as many registers reducing the number of instructions needed to read and write from memory.

RISC-V branching takes less space and so does vector instructions. There are many case like that which adds up end results in RISC-V having the most dense ISA in all studies when using compressed instructions.

Re: “Risc V greatly underperforms”

#163

Post by dragontamer »

Teknoman117 wrote: post #140
dragontamer wrote: post #52

Hmmm... I think this argument is solid. Albeit biased from GMP's perspective, but bignums are used all the time in RSA / ECC, and probably other common tasks, so maybe its important enough to analyze at this level. 2-instructions to work with 64-bits, maybe 1 more instruction / macro-op for the compare-and-jump back up to a loop, and 1 more instruction for a loop counter of somekind? So we're looking at ~4 instructio…

Can you treat the whole vector register as a single bignum on x86? If so, I totally missed that.

No.

Which is why I'm sure add / adc will still win at 128-bits, or 256-bits.

The main issue is that the vector-add instructions are missing carry-out entirely, so recreating the carry will be expensive. But with a big enough number, that carry propagation is parallelizable in log2(n), so a big enough bignum (like maybe 1024-bits) will probably be more efficient for SIMD.

Re: “Risc V greatly underperforms”

#165

Post by fwsgonzo »

xondono wrote: post #149

Experimenting with RISC-V is one of those things I keep postponing. For those are more versed, is this really a general problem? I was under the impression that the real bottleneck is memory, and things like this would be fixed in real applications through out of order execution, and that it payed off having simpler instructions because compilers had more freedom to rearrange things.

RISC-V is completely fine, heavily based on research and well thought out. It does have pros and cons like any other architecture, and for what it does well, it does it really well!

Re: “Risc V greatly underperforms”

#166

Post by volta83 »

jhallenworld wrote: post #136

What if the multi-precision code is written in C? You can detect carry of (a+b) in C branch-free with: ((a&b) | ((a|b) & ~(a+b))) >> 31 So 64-bit add in C is: f_low = a_low + b_low c_high = ((a_low & b_low) | ((a_low | b_low) & ~f_low)) >> 31 f_high = a_high + b_high + c_high So for RISC-V in gcc 8.2.0 with -O2 -S -c add a1,a3,a2 or a5,a3,a2 not a7,a1 and a5,a5,a7 and a3,a3,a2 or a5,a5,a3 srli a5,a5,31 add a4,a4,a6 a…

> RISC-V is faster..

I find it funny that you make the same pitfall than the author did.

Faster on which CPU?

The author doesn't measure on any CPU, so here there are dozens of people hypothesizing whether fusion happens or not, and what the impact is.

Re: “Risc V greatly underperforms”

#167

Post by dataflow »

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…

>> RISC-V has an acceptable code size only for unsafe code

> You have no idea what you're talking about.

> It should be said that my experience is in embedded, so yes, it's unsafe code.

Just going based off your reply it certainly sounds like they had at least some idea what they were talking about? In which case omitting that sentence would probably help.

Re: “Risc V greatly underperforms”

#168

Post by jasonhansel »

One thing that bothers me: RISC-V seems to use up a lot of the available instruction set space with "HINT" instructions that nobody has (yet) found a use for. Is it anticipated that all of the available HINTs will actually be used, or is the hope that the compressed version of the instruction set will avoid the wasted space?

Re: “Risc V greatly underperforms”

#169

Post by bpye »

Taniwha wrote: post #123
theresistor wrote: post #115

Earlier quoted context omitted.

> This is in stark contrast with ARMv7's thumb, which was a literal separate CPU mode. This is disingenuous. arm32's Thumb-2 (which has been around since 2003) supports both 16-bit and 32-bit instructions in a single mode, making it directly comparable to RV32C.

The main distinction is that the 16-bit RISCV-C ISA exactly maps to existing 32-bit RISCV instructions, its implementation only occurs in the decode pipe stage

The C extension is that, an extension. A RISC-V core with the C extension should still support the long encoding as well. There is no 16-bit variant specified, only 32, 64 and 128.

There is an E version of the ISA with a reduced register set, but this is a separate thing.

Re: “Risc V greatly underperforms”

#170

Post by pierrebai »

justinpombrio wrote: post #148
adrian_b wrote: post #112

Earlier quoted context omitted.

The size of the files can be very misleading, because a large part of the files can be filled with various tables with additional information, with strings, with debugging information, with empty spaces left for alignment to page boundaries and so on. So the size of the installed files is not necessarily correlated with the code size. To compare the code sizes, you need tools like "size", "readelf" etc. and the data…

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.
Post reply on HN