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

211–220 of 365 posts

Re: “Risc V greatly underperforms”

#211

Post by snvzz »

bubblethink wrote: post #210
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…

>There's not even a need to look at the research, which shows RISC-V as the clear winner in code density. It is enough to grab any Linux distribution that supports RISC-V and look at the size of the binaries across architectures. Wait, if we are talking about actual ISA instructions, why is it hard to believe that RISC-V would have more of them ? The argument in favor of RISC is to simplify the frontend because even…

Code density is about requiring the least amount of bytes of code to get something done, on average.

Doing it using a small pool of instructions, too (as RISC-V does), is the cherry on top.

Re: “Risc V greatly underperforms”

#212

Post by bpye »

brucehoult wrote: post #187
bpye wrote: post #169

Earlier quoted context omitted.

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.

You are mixing up integer register size and instruction length. RISC-V has variants with 32 bit, 64 bit, or (not yet fully specified or implemented) 128 bit registers. RISC-V has instructions of length 32 bits and, optionally but almost universally, 16 bit length.

Ah yes, I misunderstood the original comment as implying that RISC-V C had 16 bit register length, rather than opcode length.

Re: “Risc V greatly underperforms”

#213

Post by brucehoult »

orra wrote: post #161
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…

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

Indeed.

The "C" extension is technically optional, but I'm not aware of anyone who has made or sold a production chip without it -- generally only student projects or tiny cores for FPGAs running very simple programs don't have it.

My estimate is if you have even 200 to 300 instructions in your code it's cheaper to implement "C" than to build the extra SRAM/cache to hold the bigger code without it.

Re: “Risc V greatly underperforms”

#214

Post by jaytaylor »

snvzz wrote: post #109
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…

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 like a incomplete explanation with a polarized view than anything useful for understanding what fusion means in this context.

Overall is give the ranking a score of D-.

Re: “Risc V greatly underperforms”

#215

Post by pcwalton »

monocasa wrote: post #207
pcwalton wrote: post #204

Earlier quoted context omitted.

I'm a bit confused. First, JavaScript doesn't use bignum arithmetic much. JS Numbers are doubles. JavaScript JITs do speculatively use integers where possible, but this workload doesn't need add-with-carry, just efficient overflow detection (which is a problem with RISC-V, but not the problem we're discussing here). It could be a problem for Lisp and ML, but these are hardly common languages. And as for crypto, could…

JS numbers speculatively using integers in practice rely on the carry flag for cheap overflow bailout checks. Maybe if the overflow check didn't have the same problem, they'd look at that instead, but I don't see why they should have to switch if it doesn't gain them anything. And there's tons of reasons why using one lane of vector units as scalar ops is an issue. Power, lack of ubiquitous vector units, their pipeli…

Overflow bailout is 1 instruction in RISC-V (same as x86/ARM) if either the addition is unsigned or you know the sign of one of the operands, one of which is usually the case. (If neither is the case, it's 3 instructions.) And I believe RISC-V supports 1-lane vectors through its variable-width vector feature, which an implementation could optimize if it wanted to (though I agree with you that RISC-V should just grow a proper add-with-carry instruction).

Re: “Risc V greatly underperforms”

#216

Post by mhh__ »

TheCondor wrote: post #197
ncmncm wrote: post #191

Earlier quoted context omitted.

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

SiFive have a new thing which is roughly as fast as a low-power CPU from Intel or Apple (e.g. IceStorm).

Obviously not really competitive, but I think they are still mostly making hardware so there is hardware at-all stage.

Re: “Risc V greatly underperforms”

#217

Post by mhh__ »

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…

Calling it terrible is definitely something from the book of Linus T.

Bad? Quite possible, it was meant as a teaching ISA initially IIRC, but terrible? Who knows.

Re: “Risc V greatly underperforms”

#218

Post by cpeterso »

volta83 wrote: post #158
lordnacho wrote: post #99

Earlier quoted context omitted.

How does the instruction fusion work? It seems to be mentioned in the article and by a couple of other commenters.

The CPU executes the two (or more) dependent instructions "as if" they were one, e.g., in 1 cycle. The CPU has a frontend, which has a decoder, which is the part that "reads" the program instructions. When it "sees" certain pattern, like "instruction x to register r followed by instruction y consuming r", it can treat this "as if" it was a single instruction if the CPU has hardware for executing that single instructi…

Do RISC-V specs document which instruction combinations they recommend be fused? Sounds like the fused instructions are an implementation detail that must be well-documented for compiler writers to know to emit the magic instruction combinations.

Re: “Risc V greatly underperforms”

#219

Post by mhh__ »

ksec wrote: post #68

The unwritten rule of HN: You do not criticise The Rusted Holy Grail and the Riscy Silver Bullet.

Rust is pretty well regarded technically here, but RISC-V is mostly a "wouldn't it be nice" rather than something most commenters seem to be super knowledgeable about.

Many people still think that RISC-V implies an open source implementation, for example.

Re: “Risc V greatly underperforms”

#220

Post by meepmorp »

rbanffy wrote: post #95
meepmorp wrote: post #27

Earlier quoted context omitted.

It's not a "slam piece," it's an email from a listserv, send two months ago. Someone realized it'd be catnip for people on HN and posted it.

It's not even a rock-solid critique...

It's a cranky programmer yelling into an email pillow for a bit.
Post reply on HN