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

191–200 of 365 posts

Re: “Risc V greatly underperforms”

#191

Post by ncmncm »

user-the-name wrote: post #44
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…

> RISCV also specifies a 128-bit variant that is of course FASTER than these examples Is it actually implemented on any hardware?

No. Mentioning it is only meant to distract.

Re: “Risc V greatly underperforms”

#192

Post by panick21_ »

userbinator wrote: post #103
panick21_ wrote: post #35

Earlier quoted context omitted.

Part of the idea is to create standard ways to do certain things and then hope compiler writers generation code according to that. That will allow more chip designers to take advantage of those if they want to. They spent a lot of time and effort on making sure the decoding pretty good and useful for high performance implementations. RISC-V is designed for very small and very large system. At some point some tradeoff…

RISC-V is designed for very small and very large system That's exactly the problem --- there is no one-size-fits-all when it comes to instruction set design.

There is a trade-off but there is overall far more value in having it be unified.

The trade-offs are mostly very small or non existent once you consider the standard extensions that different use cases will have.

Overall having a unified open instruction set is far better then hand designing many different instruction sets just to get marginal improvement. Some really extreme application might require that, but for the most part the whole indsutry could do just fine with RISC-V. Both on the low and on the high end, and in fact better then most of the alternative all things considered.

If integer checking is really the be all end all and without it RISC-V can not be successful without it, it will be added and it will be pulled into all the profiles. If it is not actually that relevant then it wont. If it is very useful for some verticals and not others, it will be in those profiles and not in others.

Re: “Risc V greatly underperforms”

#193

Post by flatiron »

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.

Oh no. We don’t maintain this site with these types of comments no matter your feelings. It’s the internet. Don’t get heated!

Re: “Risc V greatly underperforms”

#194

Post by jhallenworld »

volta83 wrote: post #166
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.

All other things equal, you would prefer smaller code for better cache use.

Re: “Risc V greatly underperforms”

#195

Post by socialdemocrat »

RISC V is an opinionated architecture and that is always going to get some people fired up. Any technology that aims for simplicity has to make hard choices and trade offs. It isn’t hard to complain about missing instructions when there are less than 100 of them. Meanwhile nobody will complain about ARM64 missing instructions because it had about 1000 of them.

Therein lies the problem. Nobody ever goes out guns blazing complaining about too many instructions despite the fact that complexity has its own downsides.

RISC-V has been designed aggressively to have minimal ISA to leave plenty of room to grow, and require minimal number of transistors for a minimal solution.

Should this be a showstopper down the road, then there will be plenty of space to add an extensions that fixes this problem. Meanwhile embedded systems paying a premium for transistors are not going to have to pay for these extra instructions as only 47 instructions have to be implemented in a minimal solution.

Re: “Risc V greatly underperforms”

#196

Post by adrian_b »

fhood wrote: post #131

Oh wow, everybody else is debating the specific intricacies of the design decisions, and I'm here wondering why you would complain about not enough instructions in an architecture with "RISC" in the name.

The RISC idea was to not include in the ISA instructions so complex that they would require a multi-cycle implementation.

The minimum duration of the clock cycle of a modern CPU is essentially determined by the duration of a 64-bit integer addition/subtraction, because such operations need a latency of only 1 clock cycle to be useful.

Operations that are more complex than 64-bit integer addition/subtraction, e.g. integer multiplications or floating-point operations, need multiple cycles, but they are pipelined so that their throughput remains at 1 per cycle.

So 64-bit addition/subtraction is certainly expected to be included in any RISC ISA.

The hardware adders used for addition/subtraction provide, at a negligible additional cost, 2 extra bits, carry and overflow, which are needed for operations with large integers and for safe operations with 64-bit integers.

The problem is that the RISC-V ISA does not offer access to those 2 bits and generating them in software requires a very large cost in execution time and in lost energy in comparison with generating them in hardware.

I do not see any relationship between these bits and the RISC concepts, omitting them does not simplify the hardware, but it makes the software more complex and inefficient.

Re: “Risc V greatly underperforms”

#197

Post by TheCondor »

ncmncm wrote: post #191
user-the-name wrote: post #44

Earlier quoted context omitted.

> RISCV also specifies a 128-bit variant that is of course FASTER than these examples Is it actually implemented on any hardware?

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

Re: “Risc V greatly underperforms”

#198

Post by User23 »

snvzz wrote: post #113
userbinator wrote: post #100

Earlier quoted context omitted.

Larger caches won't help much either; there's an old article I remember that compares the efficiency of various ARM, x86, and one MIPS CPU, and while x86 and ARM were neck-and-neck, the MIPS was dead last in all the comparisons despite having more cache than the others. RISC-V is very similar to MIPS.

Larger caches, as seen in Apple's M1 L1, are one of many tools to deal with bad code density. RISC-V might, at first glance, look similar to MIPS, but it leads in code density among the 64 bit architectures.

> [RISC-V] leads in code density among the 64 bit architectures.

You keep baldly asserting this in virtually all of your very many replies here, with a vague appeal to your own authority, but you haven't shown anything. Given that the submission is precisely an example of bad code density, if you're really here in the service of intellectual curiosity then please show instead of just telling.

Re: “Risc V greatly underperforms”

#199

Post by brandmeyer »

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 only addresses a subset of the available registers. Small revisions in a function which change the number of live variables will suddenly and dramatically change the compressibility of the instructions.

Higher-level languages rely heavily on inlining to reduce their abstraction penalty. Profiles which were taken from the Linux kernel and (checks notes...) Drystone are not representative of code from higher-level languages.

3/4 of the available prefix instruction space was consumed by the 16-bit extension. There have been a couple of proposals showing that even better density could be achieved using only 1/2 the space instead of 3/4, but they were struck down in order to maintain backwards compatibility.

Re: “Risc V greatly underperforms”

#200

Post by brucehoult »

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…

Note that with the newly-ratified B extension, RISC-V has BIC (called ANDN) as well as ORN and XNOR.

In addition to the actual ALU instructions doing the add with carry, for bignums it's important to include the load and store instructions. Even in L1 cache it's typically 2 or 3 or 4 cycles to do the load, which makes one or two extra instructions for the arithmetic less important. Once you get to bignums large enough to stream from RAM (e.g. calculating pi to a few billion digits) it's completely irrelevant.

Post reply on HN