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

291–300 of 365 posts

Re: “Risc V greatly underperforms”

#291

Post by socialdemocrat »

adrian_b wrote: post #240
dragontamer wrote: post #110

Earlier quoted context omitted.

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

By combining instruction compression and macro-op fusion you get the net effect of looking like you have a bunch of extra higher level opcodes in your ISA.

Compress a shift and load into a 32-bit word and macro-op fuse those and you have in effect an index based load instruction, without sucking up ISA encoding space for it.

Re: “Risc V greatly underperforms”

#292

Post by volta83 »

jhallenworld wrote: post #194
volta83 wrote: post #166

Earlier quoted context omitted.

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

8x 2 byte instructions (16 bytes) lead to smaller code than 4x 8 byte instructions (32 bytes).

Counting number of instructions isn't really a good metric for that either.

Re: “Risc V greatly underperforms”

#293

Post by volta83 »

brutal_chaos_ wrote: post #185
volta83 wrote: post #166

Earlier quoted context omitted.

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

> Faster on which CPU? Perhaps faster means fewer instructions in this instance? Considering number of instructions is what has been discussed.

Right, but all architectures can handle many combinations of instructions in 1 cycle, so this is not really a great proxy for that.

Same for code size. If the instructions are half the size, having 1.5x more instructions still means smaller binaries.

Re: “Risc V greatly underperforms”

#294

Post by mda »

Honestly in my eyes, author loses all credibility after saying this:

"I believe that an average computer science student could come up with a better instruction set that Risc V in a single term project"

Utter horse manure.

Re: “Risc V greatly underperforms”

#295

Post by ksec »

mda wrote: post #286
jaytaylor wrote: post #214

Earlier quoted context omitted.

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…

Try 'risc V instructuin fusion" or "Risc V macro op fusion' Not that hard really. It is a well known subject. I hope people could stop whining everytime they mess up a search query.

>I hope people could stop whining everytime they mess up a search query.

I dont know. I have never seen anyone using the term "Fusion" by itself, may be it is specific to RISC-V crowd? It is always "macro-op fusion". So your parent 's search parameter isn't something out of order for someone how knows very little about hardware. And HN are full of Web developers so abstracted in the hierarchy they knows practically zero about hardware.

And to be quite frankly honest the GP's point about Fusion had me confused for a sec as well.

Re: “Risc V greatly underperforms”

#296

Post by titzer »

aidenn0 wrote: post #281
titzer wrote: post #260

Earlier quoted context omitted.

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

Common Lisp will often have auxiliary return values that are often not needed (e.g. the mathematical floor function returns the remainder as a second value). Unused extra values are silently discarded. So you can do, for example (+ (floor x y) z) without worrying about the second value to floor. A lisp compiler for a register machine will usually return the first N values in registers (for some small value of N), so…

Return values are pushed onto the Wasm operand stack in left-to-right order. Engines use registers for params/returns up to a point in optimized code and then spill to the stack. So at the call site you can just drop the return values you don't want and should end up with machine code that does exactly what you want.

Re: “Risc V greatly underperforms”

#297

Post by ansible »

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…

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

Ah, but where you do put that bit that you got for free?

A condition codes register, global to the processor / core state? That worked terrific for single-issue microcontrollers back in the 1980's. Now you need register renaming, and all the expensive logic around that to track which overflow bit is following which previous add operation. That's what's being done now for old ISAs, and it generally disliked for several reasons (complexity being chief among them).

Well, you could stuff that bit into another general purpose register, but then you kind of want to specify 4 registers for the add command. Now where are the bits to encode a 4th register in a new instruction format. RISC-V has room to grow for extensions, but another 5 bits for another register is a big ask.

Re: “Risc V greatly underperforms”

#298

Post by amelius »

socialdemocrat wrote: post #288
amelius wrote: post #287

Earlier quoted context omitted.

Doesn't decompression imply that there is some extra latency?

No, it is just part of the regular instruction decoding. It is not like it is zip compressed. It is just 400 logic gates added to the decoder… which is nothing.

Yes, but the logic signal needs to ripple through those gates, which takes time.

Re: “Risc V greatly underperforms”

#299

Post by imtringued »

avianes wrote: post #186
snvzz wrote: post #139

Earlier quoted context omitted.

>Unfortunately for RISC-V, this is the only example favorable for it, because for a large number of ARM or Intel/AMD instructions RISC-V needs a pair of instructions or even more instructions. Yet, as many pointed out to you already, RISC-V has the highest code density of all contemporary 64bit architectures. And aarch64, which you seem to like, is beyond bad. >but it is the only way available for RISC-V to match the…

I see that you are pretty active here in debunking anti-RISC-V attacks, thanks for that! There are a bunch of poor criticisms about RISC-V. > This is something you've been told elsewhere in the discussion, but that you chose to ignore, for reasons unknown. I would call it RISC-V bashing. Everyone loves to hate RISC-V, probably because it's new and heavily hyped. It is really common to see irrelevant and uninformed cr…

The more I think about CPU implementations the more I think that what RISC-V is doing isn't as bad as many people think. Everyone is going "more instructions = worse".

But the truth is that if you can build a CPU that fetches an infinite number of instructions per cycle, your biggest bottleneck isn't going to be the number of instructions, it's going to be unpredicted branches, jumps and function calls because fetching the entire function + everything behind it doesn't help, if you're going somewhere else. But the opposite is also true, adding more instructions than you need doesn't hurt as much as many people seem to think.

In practice the code density of RISC-V is not significantly worse than other architectures. So we don't even have to imagine an infinitely large fetcher, a finite fetcher that is bigger than what x86 CPUs have is good enough.

Re: “Risc V greatly underperforms”

#300

Post by imtringued »

adrian_b wrote: post #147
api wrote: post #77

Earlier quoted context omitted.

So this person found a pathological case for the RISC-V instruction set?

This is not a pathological case, it is normal operation. A computer is supposed to compute, but the RISC-V ISA does not provide everything that is needed for all the kinds of computations that exist. The 2 most annoying missing features are the lack of support for multi-word operations, which are needed to compute with numbers larger than 64 bits, but also the lack of support for detecting overflow in the operations…

The assembly code in the email is trivial. You don't seem to understand that the carry bit dependency exists regardless of the architecture. So ultimately, just fetching more instructions is enough to achieve optimal performance. As others said, code density of RISC-V is very reasonable on average. It's not significantly worse than x86 across an entire binary.
Post reply on HN