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

301–310 of 365 posts

Re: “Risc V greatly underperforms”

#301

Post by evilos »

theresistor wrote: post #102
lottospm wrote: post #88

Earlier quoted context omitted.

I'm not an expert on ISA and CPU internals, but an X86 instruction is not just "an instruction" anymore. Afaik, since the P6 arch Intel is using a fancy decoder to translate x86/-64 CISC into an internal RISC ISA (up to 4 u-ops per CISC instruction) and that internal ISA could be quite close to the RISC-V ISA for all I know. Instruction decoding and memory ordering can be a bit of nightmare on CISC ISAs and fewer mac…

As someone who is an expert on ISA and CPU internals, this meme of "X86 has an internal RISC" is an over-simplification that obscures reality. Yes, it decodes instructions into micro-ops. No, micro-ops are not "quite close to the RISC-V ISA". Macro fusion definitely has a place in microarchitecture performance, especially when you have to deal with a legacy ISA. RISC-V makes the very unusual choice of depending on it…

> "X86 has an internal RISC" is an over-simplification that obscures reality

Is it misleading though? I don't mind simplifications unless they are misleading. Would like to hear your criticisms of this meme.

Re: “Risc V greatly underperforms”

#302

Post by imtringued »

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…

It reminds me of nutrition advice. The 70s said X is evil or bad. Then we discover, X doesn't matter.

I think in 10-20 years everyone will agree that all the "bad" RISC-V decisions don't matter. The same way x86 (CISC) was supposed to be bad because of legacy/backwards compatibility.

Re: “Risc V greatly underperforms”

#303

Post by AshamedCaptain »

brandmeyer wrote: post #248
snvzz wrote: post #120

Earlier quoted context omitted.

Your statement does not run counter to mine quoted. Thumb-2 is better designed than Thumb was, but it is still a separate CPU mode. And it got far less use than it deserved, because of this. It doesn't do everything, and switching has a significant cost. This cost is in contrast with RISC-V's C extension.

Comparing RISC-V's "C" extension to classic Thumb when Thumb-2 is 17 years old is like comparing RISC-V's "V" extension to classic SSE when AVX-512 and SVE2 are already available. Its an insidious form of straw-man attack that preys on the reader's ignorance. > [Thumb-2] doesn't do everything, and switching has a significant cost. Technically true, but irrelevant. Cortex-M is thumb-only and can't switch. Cortex-A pro…

> Cortex-A processors that support both Thumb and ARM instructions almost never actually switch at all.

That is not correct. At least before ARMv8, most processors that could run both Thumb and ARM switch very frequently, up the point some libraries could be Thumb while others were ARM (i.e. within the same task!). A lot (but not all) of Android for ARMv7 is actually Thumb(-2). This is why "interworking" is such a hot topic.

Also, contrary to what the above poster says, switching does not have a "high cost", it is rather similar to the cost of a function call.

Re: “Risc V greatly underperforms”

#304

Post by imtringued »

bArray wrote: post #244

> I believe that an average computer science student could come up with a better instruction set that Risc V in a single term project. When you hear the " could make a better in " - call them out. Do it. The world will not shun a better open license ISA. We even have some pretty awesome FPGA boards these days that would allow you to prototype your own ISA at home. In terms of the market - now is an exceptionally grea…

>As I see it, lower numbers of transistors could also be a good thing. It seems blatantly obvious at this point that multi-core software is not only here to stay, but is the future. Lower numbers of transistors means squeezing more cores onto the same silicon, or implementing larger caches, etc.

How about some 32 way SMT GPUs... No more divergence!

Re: “Risc V greatly underperforms”

#305

Post by imtringued »

kbelder wrote: post #272
bArray wrote: post #244

> I believe that an average computer science student could come up with a better instruction set that Risc V in a single term project. When you hear the " could make a better in " - call them out. Do it. The world will not shun a better open license ISA. We even have some pretty awesome FPGA boards these days that would allow you to prototype your own ISA at home. In terms of the market - now is an exceptionally grea…

Yeah. I don't have a dog in this fight... I don't have strong opinions either way, and this is one of those arguments that will be settled by reality after some time goes by. But the author making an argument like that... > I believe that an average computer science student could come up with a better instruction set that Risc V in a single term project. Pretty much blew their credibility. It's obviously wrong, and a…

This student gets an A because he added the "adcs" instruction to his ISA. Everyone else gets an F because they didn't.

Re: “Risc V greatly underperforms”

#306

Post by imtringued »

R0b0t1 wrote: post #267
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…

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.

I agree. A lot of software only wants protection against overflows but does not depend on them for functionality. If something wants to read out the carry bit, it should be explicit and although it is unfortunate, indicating that requires a full instruction.

Re: “Risc V greatly underperforms”

#307

Post by imtringued »

ansible wrote: post #297
adrian_b wrote: post #154

Earlier quoted context omitted.

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

I have no clue about flags but why not just store the flags with the register? Each register would have 32+r bits where r is the number of flags.

Re: “Risc V greatly underperforms”

#308

Post by imtringued »

evilos wrote: post #301
theresistor wrote: post #102

Earlier quoted context omitted.

As someone who is an expert on ISA and CPU internals, this meme of "X86 has an internal RISC" is an over-simplification that obscures reality. Yes, it decodes instructions into micro-ops. No, micro-ops are not "quite close to the RISC-V ISA". Macro fusion definitely has a place in microarchitecture performance, especially when you have to deal with a legacy ISA. RISC-V makes the very unusual choice of depending on it…

> "X86 has an internal RISC" is an over-simplification that obscures reality Is it misleading though? I don't mind simplifications unless they are misleading. Would like to hear your criticisms of this meme.

X86 processors could have an internal VLIW for all we know. The instruction length would be very small by Itanium standards but still. It could be anything.

Re: “Risc V greatly underperforms”

#309

Post by imtringued »

lvh wrote: post #122
vadfa wrote: post #85

Earlier quoted context omitted.

So when h266 or whatever comes out you can't watch video anymore because your cpu can't decode it in software even if it tried?

An FPGA can be reprogrammed, and we do really do this for standards with better longevity than video standards (e.g. cryptographic ones like AES and SHA). For standards like video codecs, we just use GPUs instead, which I assume is what OP had in mind for "specialized hardware" (specialization can still be pretty general :-)).

SystemC bloat will require you to upgrade to a bigger FPGA!

Re: “Risc V greatly underperforms”

#310

Post by foxfluff »

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…

> How can anyone say such a thing about a collaborative project of more than 10 years, fed by many scientific works and projects and many companies in the industry?

Well the statement you quoted might be exaggerating things quite a bit but you're also just handwaving. The base ISA isn't a result of 10 years of industry experts doing their best; it's an academic project and a large proportion of it carried out by students:

> Krste Asanović at the University of California, Berkeley, had a research requirement for an open-source computer system, and in 2010, he decided to develop and publish one in a "short, three-month project over the summer" with several of his graduate students. [..] At this stage, students provided initial software, simulations, and CPU designs

The ISA specification was released in 2011! In one year! Of course there's been revisions since then, the most substantial being 2.0 in 2014 (I think). But if you look at the changes and skip anything that isn't just renaming / reordering / clarifying things, it always fits on half a page. It's by and large the same ISA, with some nice finetuning.

And here's the thing, a lot of people who originally read the spec felt like it is what it looks like, a "textbook isa", very much the kind of thing a group of students might come up with (I wonder why?).. just taken to completion. And what I remember from the spec (I read it long ago) is that cost of implementation was almost always a primary concern (and that high performance inmplementations would have to work harder but shrug itsnobigdealright?): it smelled like a small academic ISA tuned specifically for cheap microcontrollers. Not an ISA designed by industry experts for high performance cores. But the hype party is trying to sell it as a solution for all your computing needs, and almost seem to claim that no tradeoffs have been made against performance? And this is on a submission about performance, which is of course a subject a lot of people find interesting...

So I think there's very much reason to be critical of and discuss the ISA. Some critique may come from wrong assumptions, but being critical is not just bashing, and calling (attempts at) technical criticism uninformed & irrelevant and handwaving it away with 10 years of hype isn't helping the discussion. Better contribute that better analysis you refer to. (Unfortunately it seems like mostly everyone is just arguing without posting technical analysis)

Post reply on HN