“Risc V greatly underperforms” • Hacker News Board

Re: “Risc V greatly underperforms”

#321

Post by adrian_b » Fri, Dec 03, 2021, 12:44 PM UTC

FullyFunctional wrote: post #264

adrian_b wrote: post #245

Earlier quoted context omitted.

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.

For competitive performance in 2021 with CPUs that can be used at performance levels at least as high as those required for mobile phones, it is necessary to decode simultaneously at least 8 instructions per clock cycle (actually more for RISC-V, because its instructions do less than those of other CPUs).

The cost in area and power of a decoder for variable-length instructions increases faster with the number of simultaneously-decoded instructions than the cost of a decoder for fixed-length instructions.

This makes the compressed instruction encoding incompatible with high-performance RISC V CPUs.

For the lower performance required in microcontrollers, the compressed encoding is certainly needed for adequate code density.

The goals of minimum code size and of maximum execution speed are contradictory and the right compromise is different for an embedded computer and for a personal computer.

That is why ARM has different ISAs for the 2 domains and why also RISC-V designs must use different sets of extensions, depending on the application intended for them.

Re: “Risc V greatly underperforms”

#322

Post by adrian_b » Fri, Dec 03, 2021, 12:57 PM UTC

mlyle wrote: post #251

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…

> 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 "efficient". 1. There's not multiple additions in the recommended sequences. Unsigned is add,bltu; Signed with one known sign is add, blt; Signed in general is add, slt, slti, bne. 2. These instruction sequences are specified so that an instruction decoder can…

Even if a dedicated comparator can be a little cheaper than a full adder, all CPUs already have full adders/subtractors, so all the comparisons are done by subtraction in the same adder/subtractor.

So your recommended sequence has 4 additions done in the adder/subtractor of the ALU, because all comparisons, including the compare-and-branch instructions, count as additions, from the point-of-view of the energy consumption and execution time.

Re: “Risc V greatly underperforms”

#323

Post by socialdemocrat » Fri, Dec 03, 2021, 1:20 PM UTC

adrian_b wrote: post #321

FullyFunctional wrote: post #264

Earlier quoted context omitted.

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

For competitive performance in 2021 with CPUs that can be used at performance levels at least as high as those required for mobile phones, it is necessary to decode simultaneously at least 8 instructions per clock cycle (actually more for RISC-V, because its instructions do less than those of other CPUs). The cost in area and power of a decoder for variable-length instructions increases faster with the number of simu…

RISC-C compressed instructions cannot be compared to CISC variable length instructions. The instruction boundaries are easy to determine in parallel for multiple decoders. Something which is hard for e.g. x86. Compressed instructions don’t have arbitrary length. It is two instructions fitted in a 32-bit word.

Decompression is part of the instruction decoding itself. It only requires a minuscule 400 logical gates to do.

In fact RISC-V is very well designed for doing out-of-order execution of multiple instructions as instructions have been specifically designed to share as little state as possible. No status registers or conditional execution bits. Thus most instructions can run in separate pipelines without influencing each other.

Re: “Risc V greatly underperforms”

#324

Post by avianes » Fri, Dec 03, 2021, 1:32 PM UTC

foxfluff wrote: post #310

avianes wrote: post #186

Earlier quoted context omitted.

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

> Some critique may come from wrong assumptions, but being critical is not just bashing

Focusing criticism only on this architecture, producing criticism without any solid argument, putting aside all the positive aspects, criticism when you clearly lack of expertise, sending similar criticisms in several conversations when already debunked on multiple occasions.. This is really systematic on discussion about RISC-V. That's what I call bashing, I cannot call that legitimate, correct or constructive criticism.

> The ISA specification was released in 2011! In one year! [...] 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.

I encourage anyone to open the original document published in 2011 [1] and compare it with current RISC-V specification documents [2].

There is very little left from the 3 month student work, it mainly remains the philosophy which is probably highly influenced by project supervisors. Moreover, it mainly consists of the basic RISC-V ISA which is indeed designed to be simple and minimalist, whereas the current RISC-V full spec. consists of a multitude of extensions.

At this stage your statement and the statement from the email is not just exaggerated, it is pure misinformation.

> Not an ISA designed by industry experts for high performance cores

Okay, the industry wasn't involved as much as today in the beginning. But RISC-V is really the product of experts in the field of high performance architectures

[1] https://www2.eecs.berkeley.edu/Pubs/TechRpts/2011/EECS-2011-...

[2] https://riscv.org/technical/specifications/

Re: “Risc V greatly underperforms”

#325

Post by socialdemocrat » Fri, Dec 03, 2021, 1:36 PM UTC

theresistor wrote: post #4

jpfr wrote: post #2

The idea is to use the compressed instruction extension. Then two adjacent instructions can be handled like a single “fat” instruction with a special case implementation. That allows more flexibility for CPU designs to optimize transistor count vs speed vs energy consumption. This guy clearly did not look at the stated rationale for the design decisions of RISC-V.

Compressed instructions and macro-fusion aren't magical solutions. It's not always possible to convince the compiler to generate the magical sequence required, and it actually makes high-performance implementations (wide superscalar) more difficult thanks to the variable width decoding. Beyond that, compressed instructions are not a 1:1 substitute for more complex instructions, because a pair of compressed instructio…

I don’t see why offsets larger than 16-bit are important. Are you implying that most fusion candidate pairs would need this? In tight inner loops why would you need large offsets?

Of course you discard architectural state changes in fusion. If I have a bunch of instructions which end up reading from memory into register x10, then I can fuse with all previous instructions which wrote into x10, as their results get clobbered anyway.

Disclaimer: I may have misunderstood the point you made. However you don’t seem to make it clear how fusion is bad for performance.

What performance tricks are you giving up by doing fusion?

Re: “Risc V greatly underperforms”

#326

Post by panick21_ » Fri, Dec 03, 2021, 1:42 PM UTC

ddingus wrote: post #250

panick21_ wrote: post #192

Earlier quoted context omitted.

There is a trade-off but there is overall far more value in having it be unified. The trade-offs are mostly very small or non existent once you consider the standard extensions that different use cases will have. Overall having a unified open instruction set is far better then hand designing many different instruction sets just to get marginal improvement. Some really extreme application might require that, but for t…

>overall far more value in having it be unified. >[...] >If integer checking is really the be all end all and without it RISC-V can not be successful without it, it will be added and it will be pulled into all the profiles. If it is not actually that relevant then it wont. If it is very useful for some verticals and not others, it will be in those profiles and not in others. So which is it? Unified or something else?

The goal is that there is a unified core that runs the majority code. The majority of ecosystem and tooling works of a common base. Lots of code can be used in a way to be very universal.

Some verticals that will be special like deep embedded will likely be different enough that it will be slightly different, but it still profits from all the work going into the overall ecosystem.

RISC-V allows 'the market' to decide between uniformity and specialty in a orthogonal way. My bet is that this will actually lead to a lot of uniformity in most verticals.

Re: “Risc V greatly underperforms”

#327

Post by stephencanon » Fri, Dec 03, 2021, 1:48 PM UTC

AshamedCaptain wrote: post #303

brandmeyer wrote: post #248

Earlier quoted context omitted.

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

> it is rather similar to the cost of a function call.

It literally is a function call, most of the time.

And yeah, thumb-2 was the preferred encoding for 32b iOS and Android, and the only supported encoding for Windows phone, so it was used on billions of devices.

Re: “Risc V greatly underperforms”

#328

Post by kortex » Fri, Dec 03, 2021, 1:55 PM UTC

phkahler wrote: post #238

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…

>> But ultimately, the gist of their argument is this... Funny, I thought the whole thing was bitching that RISC V has no carry flag which obviously causes multi word arithmetic to take more instructions. The obvious workaround is to use half-words and use the upper half for carry. There may be better solutions, but at twice the number of instructions this "dumb" method is better than what the author did. Flags were…

So if I'm understanding this particular tussle correctly, carry flags are problematic for optimization because they create implicit mutable shared global state, which isn't necessarily reflected in the machine code.

Risc-v basically says "lets make the implicit, explicit" and you have to essentially use registers to store the carry information when operating on bigints. Which for the current impl means chaining more instructions.

Is that correct?

That sounds like what the FP crowd is always talking about - eschewing shared state so it's easier to reason about, optimize, parallelize, etc.

Re: “Risc V greatly underperforms”

#329

Post by evilos » Fri, Dec 03, 2021, 1:59 PM UTC

imtringued wrote: post #308

evilos wrote: post #301

Earlier quoted context omitted.

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

Seems to me that the parent comment was claiming to know.

Re: “Risc V greatly underperforms”

#330

Post by foxfluff » Fri, Dec 03, 2021, 1:59 PM UTC

mhh__ wrote: post #217

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.

That's the difficulty here, people are already arguing past each other because nobody seems to agree what the ISA is for.

If you look at the early history of RISC-V, it does indeed look like as something built for teaching. But I don't think that use case warrants all the hype around it.

So how did all the hype form, and why is it that there are people seemingly hyping it as the next-gen dream-come-true super elegant open developed-with-hindsight ISA that will eventually displace crufty old x86 and proprietary ARM while offering better performance and better everything? Of course that just baits you into arguing about its potential performance. And don't worry if it doesn't have all the instructions you need for performance yet, we'll just slap it with another extension and it totally won't turn into a clusterfuck with a stench of legacy and numerous attempts at fixing it (coz' remember, hindsight)!

And then if you question its potential, you'll get someone else arguing that no no, it's not a high performance ISA for general use in desktops / servers, it's just an extensible ISA that companies can customize for their special sauce microcontrollers or whatever.

Of course it's all armchair speculation because there are no high performance real world implementations and there aren't enough experts you can trust.