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

281–290 of 365 posts

Re: “Risc V greatly underperforms”

#281

Post by aidenn0 »

titzer wrote: post #260
aidenn0 wrote: post #143

Earlier quoted context omitted.

Over just the time I've been aware of things, there's been a constant positive feedback loop of "checked overflow isn't used by software, so CPU designers make it less performant" followed by "Checked overflow is less performant so software uses it less." I wish there was a way out. Language features are also often implemented at least partly because they can be done efficiently on the premiere hardware for the langu…

> 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 the common case of using only the primary return value generates exactly the same code regardless of how many values are actually returned.

I don't remember the details, but however wasm happens to implement multiple return values, you can't just pretend that a function that returns 2 values only returns one.

Re: “Risc V greatly underperforms”

#282

Post by jillesvangurp »

sosodev wrote: post #12

Why do these half baked slam pieces always make it to the top of HN?

Good question. The answer is that HN is community driven and that what ends up on it reflects on the qualities of its diverse readership.

But I agree that this bit of writing comes across as a bit overly assertive and arrogant; and probably trivially proved wrong by actually running some benchmarks.

By the same reasoning, the Apple M1 would obviously be slower than anything Intel and AMD produce given similar energy and transistor density constraints (i.e. same class of hardware). Except that obviously isn't the case and we have the Macbook air with the M1 more than holding up against much more expensive Intel/AMD chips. Reason: chips don't actually work like this person seems to assume. The whole article is a sandcastle of bad assumptions leading up to an arrogantly worded & wrong conclusion.

Re: “Risc V greatly underperforms”

#284

Post by Dylan16807 »

R0b0t1 wrote: post #268
kannanvijayan wrote: post #234

Earlier quoted context omitted.

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

Shouldn't settle for less than interrupt on overflow tbh.

That would probably be the easiest to add, wouldn't it?

Re: “Risc V greatly underperforms”

#285

Post by usr1106 »

The code given is arbitrary precision addition. How often do you need that in general computing? Hardly often enough to make a measurable difference.

Whether the similar awkwardness applies to a lot of other code or not is not being told by this isolated case.

Re: “Risc V greatly underperforms”

#286

Post by mda »

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…

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.

Re: “Risc V greatly underperforms”

#287

Post by amelius »

FullyFunctional wrote: post #263
adrian_b wrote: post #239

Earlier quoted context omitted.

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

> The compressed encoding has good code density, but low speed. That's 100% nonsense. They have the same performance and in fact, some pipelines can get better performance because they fetch a fixed number of bytes and with compressed instructions, that means more instructions fetched. The rest of the argument falls apart resting on this fallacy.

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

Re: “Risc V greatly underperforms”

#288

Post by socialdemocrat »

amelius wrote: post #287
FullyFunctional wrote: post #263

Earlier quoted context omitted.

> The compressed encoding has good code density, but low speed. That's 100% nonsense. They have the same performance and in fact, some pipelines can get better performance because they fetch a fixed number of bytes and with compressed instructions, that means more instructions fetched. The rest of the argument falls apart resting on this fallacy.

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.

Re: “Risc V greatly underperforms”

#289

Post by [deleted] »

amelius wrote: post #287
FullyFunctional wrote: post #263

Earlier quoted context omitted.

> The compressed encoding has good code density, but low speed. That's 100% nonsense. They have the same performance and in fact, some pipelines can get better performance because they fetch a fixed number of bytes and with compressed instructions, that means more instructions fetched. The rest of the argument falls apart resting on this fallacy.

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

[deleted]

Re: “Risc V greatly underperforms”

#290

Post by klelatti »

socialdemocrat wrote: post #195

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

Fair point but Arm is not just Arm64 - if you want a simple low cost ISA then there is Cortex-M.
Post reply on HN