Addressing Criticism of RISC-V Microprocessors • Hacker News Board

Re: Addressing Criticism of RISC-V Microprocessors

#51

Post by okl » Sun, Mar 20, 2022, 1:58 PM UTC

audunw wrote: post #47

Theres so many armchair specialists when it comes to criticizing RISC-V. I've seen people claim an ISA is better because it has branch delay slots.. which seems clever to someone who knows enough technical details about CPUs to understand what the benefit of that feature is ("free" instruction execution for every branch taken), but is a terrible idea for a truly scalable ISA (huge PITA for out-of-order architectures…

First you complain about "armchair specialists", then you make a blanket assertion about branch delay slots. Believe it or not, there are ISAs for applications where branch delay slots are useful, for example TMS320 DSPs with up to 5 delay slots.

Re: Addressing Criticism of RISC-V Microprocessors

#52

Post by audunw » Sun, Mar 20, 2022, 2:05 PM UTC

dontlaugh wrote: post #23

It’s nice to have an open ISA, don’t get me wrong. However, trade offs matter. Compressing instructions may improve density, but it makes them variable length. This is a big barrier to decoding in parallel, which is very important to high performance cores.

Regular base instructions are always 32-bit, compressed are always 16-bit, and they're always aligned. I don't think there's a problem decoding them in parallel. You always know where the opcodes will be located in a 32-bit word - or set of 32-bit words - you're trying to decode.

What I've been wondering is how difficult it is to fuse instructions when the compressed instructions you're trying to fuse isn't aligned to a 32-bit word.

Re: Addressing Criticism of RISC-V Microprocessors

#53

Post by socialdemocrat » Sun, Mar 20, 2022, 2:13 PM UTC

ribit wrote: post #35

I have difficulty following the points the author is trying to make. - Even with instruction compression the type of code they present will take more space than, say, Aarch64. - The entire section on conditional execution doesn't make any sense. Conditional execution is bad, we know it, that's why modern ARM does not have conditional execution. Overall, author's insistence to compare RISC-V to practically obsolete AR…

Author here: I have tried to clarify this better in the update. The point is that I am talking about AArch32 and AArch64 in the article. Yes, everybody has been going away from conditional instructions, because they don't work well in Out-of-Order superscalar processors, and they are pointless when you got good branch predictors.

HOWEVER, an argument in the ARM camp is that they are very useful when dealing with smaller chips. Remember ARM and RISC-V compete in the low range as well as higher range. AArch32 is not obsolete. It still has uses. There has been ARM fans claiming that conditional instructions make ARM superior for simple chips. The argument here was that RISC-V has way of dealing with simple In-Order chips as well.

Re: Addressing Criticism of RISC-V Microprocessors

#54

Post by pjmlp » Sun, Mar 20, 2022, 2:13 PM UTC

BirAdam wrote: post #41

stonogo wrote: post #7

It doesn't matter how convincing the sales pitch is when the product is not actually for sale. One thing ARM and x86 got right that SPARC and POWER got wrong is widely-available machines available at reasonable prices. All the 'being right' in the world won't help if developers need a five-figure hardware budget to port to your platform. VMs don't cut it for bringup.

$17 64 bit RISC-V https://linuxgizmos.com/17-sbc-runs-linux-on-allwinner-d1-ri... $29 64 bit RISC-V in the same form factor as an RPi CM3 https://www.clockworkpi.com/product-page/copy-of-clockworkpi... If you never look for it, you will believe it doesn’t exist. I was very skeptical of ARM back in the day thinking that it was great for crappy little iTrinkets and Androids but not for “real computing”. I was clearly w…

ARM has proven their place for real computing on Newton OS and Acorn Archimedes, no need to prove it again on crappy little iTrinkets and Androids.

Where is a RISC-V doing “real computing” on a Acorn Archimedes like personal computer?

Re: Addressing Criticism of RISC-V Microprocessors

#55

Post by albanread » Sun, Mar 20, 2022, 2:20 PM UTC

People should zoom right out and think about the whole RISC-V project. When our phones have billions of transistors, are we seriously supposed to believe that RISC philosophy still matters. Personally I greatly prefer the user programmable 68000 family of processors. The marketing of RISC-V is perhaps the most impressive thing about it. Each to their own, I can see why giant SSD manufacturers want to use a license free design and share the cost of compiler development. Is there really anything else?

Re: Addressing Criticism of RISC-V Microprocessors

#56

Post by __s » Sun, Mar 20, 2022, 2:23 PM UTC

okl wrote: post #51

audunw wrote: post #47

Theres so many armchair specialists when it comes to criticizing RISC-V. I've seen people claim an ISA is better because it has branch delay slots.. which seems clever to someone who knows enough technical details about CPUs to understand what the benefit of that feature is ("free" instruction execution for every branch taken), but is a terrible idea for a truly scalable ISA (huge PITA for out-of-order architectures…

First you complain about "armchair specialists", then you make a blanket assertion about branch delay slots. Believe it or not, there are ISAs for applications where branch delay slots are useful, for example TMS320 DSPs with up to 5 delay slots.

You shouldn't assess RISC-V from the viewpoint of a single chip. It's an ISA first. Branch slots are highly target specific

Re: Addressing Criticism of RISC-V Microprocessors

#57

Post by brucehoult » Sun, Mar 20, 2022, 2:29 PM UTC

dontlaugh wrote: post #23

It’s nice to have an open ISA, don’t get me wrong. However, trade offs matter. Compressing instructions may improve density, but it makes them variable length. This is a big barrier to decoding in parallel, which is very important to high performance cores.

This is really not a big deal with RISC-V's 2 instruction lengths and the encoding they use.

If decoding 32 bytes of code (256 bits, somewhere between 8 and 16 instructions) You can figure out where all the actual instructions start (yes, even the 16th instruction) with 2 layers of LUT6.

You can then use those outputs to mux two possible starting positions for 8 decoders that do 16 or 32 bit instructions, plus 8 decoders what will only ever do 16 bit instructions from fixed start positions (and might output a NOP or in some other way indicate they don't have an input).

OR you can use those outputs to mux the outputs of a 8 decoders that only do 32 bit instructions and 8 decoders that do 16 or 32 (all with fixed starting positions), plus again 8 decoders that only do 16 bit instructions from fixed start positions (possibly not used / NOP).

The first option uses less hardware but has higher latency.

That, again, is for decoding between 8 and 16 instructions per cycle, with an average on real code of close to 12.

That is more than is actually useful on normally branchy code.

In short: not a problem. Unlike x86 decoding.

Re: Addressing Criticism of RISC-V Microprocessors

#58

Post by sylware » Sun, Mar 20, 2022, 2:32 PM UTC

RISC-V is technically not bad enough to select arm64 or x86_64 over it, since those have beyond toxic IP tied to them.

From what I read in the comments, I don't expect compressed instructions on future high performance desktop/servers RISC-V CPU cores to be there.

Re: Addressing Criticism of RISC-V Microprocessors

#59

Post by panick21_ » Sun, Mar 20, 2022, 2:32 PM UTC

People over argue these minimal difference. Lets be honest, never in the history of ISA were these things the primary reason for success or failure of instruction sets been a slightly better code size.

Even if by RISC-V is 10% worse then ARM, it wouldn't actually matter that much for adoption.

Adoption happens for business reasons and what is differentiating RISC-V far more then anything else is the chance in license, governance and ecosystem.

RISC-V being better at hitting different verticals optimally because of the molecularity is likely another thing that matters more overall then how perfectly it fits for each vertical.

Re: Addressing Criticism of RISC-V Microprocessors

#60

Post by socialdemocrat » Sun, Mar 20, 2022, 2:32 PM UTC

ribit wrote: post #35

I have difficulty following the points the author is trying to make. - Even with instruction compression the type of code they present will take more space than, say, Aarch64. - The entire section on conditional execution doesn't make any sense. Conditional execution is bad, we know it, that's why modern ARM does not have conditional execution. Overall, author's insistence to compare RISC-V to practically obsolete AR…

> And that bit about GPUs and how they are not good for vector processing... not even sure how to comment on it. Also, at the end of the day, specialised devices will vastly outperform any general-purpose CPU solution. That's why we see, say, Apple M1 matrix accelerators delivering matmul performance on par with workstation CPU solutions, despite using a fraction of power.

Of course CPUs are good for vector processing compared to a general-purpose CPU. That was not the point at all. The point is that unlike older architectures such as Cray, they were not designed specifically for general-purpose vector processing but for graphics processing. That is why solutions such as SOC-1 built specifically for genera-purpose vector processing can compete with graphics cards made by giants like Nvidia.

The article is talking about adding vector processing both to RISC-V chips aimed at general purpose processing as well as to specialized RISC-V cores which are primarily designed for vector-processing. SOC-1 is an example of this. It has 4 general purpose RISC-V cores called ET-Maxion, while also having 1088 small ET-Minion cores made for vector processing. However these are still RISC-V cores, rather than some graphics card SM core.

I don't get your argument about SIMD being great for latency. RISC-V requires that vector registers are at minimum 128-bit you you can use RVV as a SIMD instruction-set with 128-bit registers if you want.