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

261–270 of 365 posts

Re: “Risc V greatly underperforms”

#261

Post by macintux »

flatiron wrote: post #193
voz_ wrote: post #174

Earlier quoted context omitted.

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!

> Be kind. Don't be snarky. Have curious conversation; don't cross-examine. Please don't fulminate. Please don't sneer, including at the rest of the community.

> Comments should get more thoughtful and substantive, not less, as a topic gets more divisive.

> When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."

https://news.ycombinator.com/newsguidelines.html

Re: “Risc V greatly underperforms”

#262

Post by quotemstr »

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

Nevertheless, the ISA speaks for itself. The goal of a technical project is to produce a technical artifact, not to generate good feelings having followed a "solid" process.

If the process you followed brought you to this, of what use was the process?

Re: “Risc V greatly underperforms”

#263

Post by FullyFunctional »

adrian_b wrote: post #239
orra wrote: post #161

Earlier quoted context omitted.

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

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.

Re: “Risc V greatly underperforms”

#264

Post by FullyFunctional »

adrian_b wrote: post #245
zamadatix wrote: post #108

Earlier quoted context omitted.

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

The compressed instruction encoding is very good and it is mandatory for any use of RISC-V in embedded computers. With this extension, RISC-V can be competitive with ARM Cortex-M. On the other hand, the compressed instruction encoding is useless for general-purpose computers intended as personal computers or as servers, because it limits the achievable performance to much lower levels than for ARMv8-A or Intel/AMD.

This of course utter nonsense. There's nothing different about the performance of compressed instructions.

Re: “Risc V greatly underperforms”

#265

Post by quotemstr »

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…

> For x86, cmp/jnz must be 5 bytes for short loops or 9 bytes for long loops, because the REX prefix is normally needed.

It's a shame the x32 architecture didn't catch on. https://en.wikipedia.org/wiki/X32_ABI

Re: “Risc V greatly underperforms”

#266

Post by astrange »

brucehoult wrote: post #229
User23 wrote: post #198

Earlier quoted context omitted.

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

No argument from authority is needed. Anyone is free to download the disk images for a large body of software such as the same versions of Ubuntu or Fedora, and compare the binary sizes -- using the "text" output from "size" command, not raw disk files as there are also things such as debugging info in there. Here's an example, using (ironically) the GMP library itself. https://news.ycombinator.com/item?id=29423324 H…

That could be confounded by gcc not enabling -funroll-loops, alignment of branch targets, etc for some architectures.

Re: “Risc V greatly underperforms”

#267

Post by R0b0t1 »

aidenn0 wrote: post #143
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).

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…

There's a blog page somewhere that's a rant for implementing saturating and other arithmetic modes. Would be a really good idea.

Main one is interrupt on overflow.

Re: “Risc V greatly underperforms”

#268

Post by R0b0t1 »

kannanvijayan wrote: post #234
formerly_proven wrote: post #141

Earlier quoted context omitted.

> It kind of chafed when I excitedly read the ISA docs and found that overflow testing was cumbersome. It just feels backwards to me to increase the cost of these checks in a time where we have realized that unchecked arithmetic is not a good idea in general.

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.

Re: “Risc V greatly underperforms”

#269

Post by astrange »

kelnos wrote: post #189

> My conclusion is that Risc V is a terrible architecture. Kinda stopped reading here. It's a pretty arrogant hot take. I don't know this guy, maybe he's some sort of ISA expert. But it strains credulity that after all this time and work put into it, RISC-V is a "terrible architecture". My expectation here is that RISC-V requires some inefficient instruction sequences in some corners somewhere (and one of these corne…

> Kinda stopped reading here. It's a pretty arrogant hot take. I don't know this guy, maybe he's some sort of ISA expert. But it strains credulity that after all this time and work put into it, RISC-V is a "terrible architecture".

Seems quite balanced with all the other replies here which claim it's the best architecture ever whenever anyone says anything about it.

I don't think its vector extensions would be good for video codecs because they seem designed around large vectors. (and the article the designers wrote about it was quite insulting to regular SIMD)

Post reply on HN