Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Addressing Criticism of RISC-V Microprocessors

erik-engheim.medium.com

Post reply on HN
Print view View original

91–100 of 149 posts

Re: Addressing Criticism of RISC-V Microprocessors

#91

Post by wmf »

socialdemocrat wrote: post #84
wmf wrote: post #81

Earlier quoted context omitted.

Agreed, but I think the purpose of these kind of criticisms is to "fix" RISC-V before it becomes yet another worse-is-better design locked in for 50 years.

I think you are really missing the point here. Of course RISC-V has negatives but most of those negatives exist for good reasons. It is a question of tradeoffs. One of the most important goals of RISC-V is to make an architecture which can stand the test of time. In this space adding the wrong kind of instructions is a bigger problem than not adding particular instructions. Whether you look at x86, HTML or just about…

Most of the complaints about RISC-V are extremely basic things like array indexing and conditional execution. These will never not be needed.

Re: Addressing Criticism of RISC-V Microprocessors

#92

Post by FullyFunctional »

avianes wrote: post #19
FullyFunctional wrote: post #11

Earlier quoted context omitted.

EDIT: Hmm, I seem to have picked a bad example. Try this one: int get(int *base, unsigned index) {return base[index];} Arm64: update: ldr w0, [x0, w1, uxtw 2] ret RV64GC (vanilla): update: slli a5,a1,32 srli a1,a5,30 add a0,a0,a1 lw a0,0(a0) ret RV64GC+Zba: update: sh2add.uw a0,a1,a0 lw a0,0(a0) ret Arm64 is able to do some indexed loads in a single instruction that might take two in RISC-V w/Zba (and up to 4+ in reg…

Why using an unsigned? It is obvious here that RISC-V without Zba takes 4 instructions because it manages special cases related to unsigned. If you use a simple int for index: slli a1,a1,2 add a0,a0,a1 lw a0,0(a0) And isolating this code in a small function puts constraints on register allocation, but if we remove this constraint then we can write: slli a1,a1,2 add a1,a1,a0 lw a1,0(a1) Which is very suitable for macr…

Indeed why use unsigned? Go take a look at a lot of C code (hint, look at SPEC benchmarks). They do that. Decades of pointer == int == unsigned have let to a lot of horrific code. But we still compile it.

The sins of the original RISC-V was spending too much time looking at RV32 and not realizing how big a problem this is in practice. Zba (slipped in as it’s not really “bit manipulation”) fixes the worst of this.

ADD: The problem in this HN thread is the same reason we got compressed it in the first place. The vast majority of people aren’t doing high performance wide implementation so the true cost isn’t widely appreciated. The people holding the decision power certainly didn’t understand it. I really think you have to live it to understand it.

Re: Addressing Criticism of RISC-V Microprocessors

#93

Post by zozbot234 »

wmf wrote: post #81
panick21_ wrote: post #59

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…

Agreed, but I think the purpose of these kind of criticisms is to "fix" RISC-V before it becomes yet another worse-is-better design locked in for 50 years.

The only part of RISC-V that is "locked in" to any extent is the minimal set of basic integer instructions. Everything else is defined as part of standardized extensions, and can be superseded simply by defining new custom extensions. Actually even the minimal instruction set admits of some variation, such as the 'E' architectures that dispense with registers R16 to R31, thus saving area in the smallest implementations and potentially freeing up some bits in the encoding.

Re: Addressing Criticism of RISC-V Microprocessors

#94

Post by zozbot234 »

klelatti wrote: post #86
avianes wrote: post #34

Earlier quoted context omitted.

Yes, but RISC-V still has a lot of encoding-space free and the benefit of C extension is huge. It's a trade-off. I don't think RISC-V is perfect or universal, but on this point they do a pretty good job compared to other ISAs

You say that the benefit is 'huge' but why should I care about code density on a modern CPU with gigabytes of memory and large caches? From a performance perspective what is the evidence that this actually provides an advantage?

Because the fastest cache levels are tiny, even in the largest and most advanced CPU's. There's plenty of evidence for the performance benefits of improved density and terseness in both code and data.

Re: Addressing Criticism of RISC-V Microprocessors

#95

Post by avianes »

klelatti wrote: post #86
avianes wrote: post #34

Earlier quoted context omitted.

Yes, but RISC-V still has a lot of encoding-space free and the benefit of C extension is huge. It's a trade-off. I don't think RISC-V is perfect or universal, but on this point they do a pretty good job compared to other ISAs

You say that the benefit is 'huge' but why should I care about code density on a modern CPU with gigabytes of memory and large caches? From a performance perspective what is the evidence that this actually provides an advantage?

To clarify, I'm not saying that RISC-V code density of C extension is a big advantage over its competitors, but it is a huge benefit for RISC-V.

You are right, code density is perhaps not that critical today.

And it is difficult to quantify its relevance as code density is always related to other variables such as instruction expressiveness, numbers of uop emitted, etc.

But I still think that code density is important for RISC-V. Because RISC-V philosophy to reach high performance is to use very simple instructions that can be combined together and take advantage of macro-op fusion. I think RISC-V without macro-op fusion can't reach the performance of other ISA.

But RISC-V with all these simple and not very expressive instructions and without C extension has a pretty bad code density which could cost a lot because it is not at the competitors' level.

So if we think of RISC-V as a macro-op fusion oriented ISA, then the C extension becomes important to be competitive.

I don't know what is better between a "macro-fusion" oriented arch or a "complex-instruction" oriented arch, future will tell us.

Re: Addressing Criticism of RISC-V Microprocessors

#96

Post by tsmi »

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…

I agree mostly with Keller's take but I think he left of one key factor, the quality of the software tool chain.

The x86 tool chains are amazing. They're practically black magic in the kinds of optimizations they can do. Honestly, I think they're a lot of what is keeping Intel competitive in performance. ARM tool chains are also very good. I think they're a lot of the reason behind why ARM can beat RISCV in code space and performance on equivalent class hardware because honestly, like Keller says, they're not all that different for common case software. But frankly x86 and ARM toolchains should dominate RISCV when we just consider the amount of person-hours that have been devoted to these tools.

So for me the real question is, where are the resources that make RISCV toolchains competitive going to come from (and keep in mind x86 and ARM have open source toolchains too)? And, will these optimizations be made available to the public?

If we see significant investment in the toolchains from the likes of Google, Apple and nVidia, or even Intel. ARM needs to be really worried.

Re: Addressing Criticism of RISC-V Microprocessors

#97

Post by klelatti »

zozbot234 wrote: post #94
klelatti wrote: post #86

Earlier quoted context omitted.

You say that the benefit is 'huge' but why should I care about code density on a modern CPU with gigabytes of memory and large caches? From a performance perspective what is the evidence that this actually provides an advantage?

Because the fastest cache levels are tiny, even in the largest and most advanced CPU's. There's plenty of evidence for the performance benefits of improved density and terseness in both code and data.

The M1 has a 192k instruction cache for performance cores which is not ‘tiny’.

If there is lots of evidence for the performance benefits of improved density vs the alternative of fixed instruction width in real world CPUs then I’m sure you’ll be able to cite it.

Re: Addressing Criticism of RISC-V Microprocessors

#98

Post by dontlaugh »

avianes wrote: post #28
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.

You are right but RISC-V variable instruction size is indeed a good trade-off. Unlike x86 where instructions can range from 1 up to 15 byte, current RISC-V ISA only has 2 instruction sizes. Today x86 decoding is limiting because we want to decode more than ~4 instructions each cycle, for RISC-V to cause same decoding difficulty it would probably be required to decode more than ~20 instructions each cycle

I don’t know that it’s a good tradeoff. ARM64 has fixed length instructions with decent density and has proven to allow highly parallel decoding.

Re: Addressing Criticism of RISC-V Microprocessors

#99

Post by avianes »

FullyFunctional wrote: post #87
avianes wrote: post #21

Earlier quoted context omitted.

Variable instruction sizes have a cost, but with only 2 instruction sizes like current RISC-V that cost remains very low as long as we don't have to decode a very large number of instructions each cycle, and it gives a huge code density advantage.

This biggest issue is one instruction spanning two cache lines, and even two pages. This means a bunch of tricky cases that is the source of bugs and overheads. It also means you cannot tell instruction boundaries until you directly fetch instructions, so you cannot do any predecode in the cache that would help you figure out dependencies, branch targets, etc. These things matter when you are trying to fetch 8+ instr…

> This biggest issue is one instruction spanning two cache lines

Even with fixed (32 bit) instruction lengths aligned on 32 bit, when we have to decode a group of 8 instructions you are facing this kind of issue.

So you either have to cut the instruction group (and thus not take full advantage of the 8 way decoder) or you have to implement a more complex prefetch with a longer pipeline. And these special cases can be handled in these pipeline stages.

> It also means you cannot tell instruction boundaries until you directly fetch instructions

I mean, AMD does that on x86, with 14 instruction lengths.

It can be done for RISC-V, it's much cheaper than x86, and it takes significantly less surface area than a bigger cache to compensate.

Re: Addressing Criticism of RISC-V Microprocessors

#100

Post by wmanley »

zozbot234 wrote: post #93
wmf wrote: post #81

Earlier quoted context omitted.

Agreed, but I think the purpose of these kind of criticisms is to "fix" RISC-V before it becomes yet another worse-is-better design locked in for 50 years.

The only part of RISC-V that is "locked in" to any extent is the minimal set of basic integer instructions. Everything else is defined as part of standardized extensions, and can be superseded simply by defining new custom extensions. Actually even the minimal instruction set admits of some variation, such as the 'E' architectures that dispense with registers R16 to R31, thus saving area in the smallest implementatio…

Things get locked in not by standards, but by usage. If your software depends on particular instructions being present you’re not going to buy a processor that has superseded those instructions, even if the new instructions conform to a theoretically cleaner design.

Everything being an extension (and thus removable) is a strength in some specific circumstances, but is a weakness in most.

Post reply on HN