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

81–90 of 149 posts

Re: Addressing Criticism of RISC-V Microprocessors

#81

Post by wmf »

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.

Re: Addressing Criticism of RISC-V Microprocessors

#82

Post by zozbot234 »

adrian_b wrote: post #17
FullyFunctional wrote: post #9

Earlier quoted context omitted.

This comes up a lot and I'm sympathetic to your plea, really (I enjoy fantasizing about a different reality where CPUs weren't just "machines to run C programs"), but in computer architecture, what really matters for one application or a class of applications might not be important when viewed across millions of programs. The fact is that integer operations and floating point are two completely different beasts, so m…

Generating the overflow bit and storing it adds a completely negligible cost to a 64-bit adder, so touting this as a cost saving measure is just a lie, even if indeed this claim has always been present in the RISC-V documentation. Most real cases of overflow checking are of the last type. Tripling the number of instructions over a bad ISA that lacks overflow exceptions, like unfortunately almost all currently popular…

The typical overhead of overflow checking in compiled languages (which, as a reminder, is in the low single-digit %'s at most) has nothing to do with the lack of hardware-sprcific extensions. It's a consistent pattern of missing optimization opportunities, because the compiler now needs to preserve the exact state of intermediate results after some operation fails with an overflow. Adding these new opcodes to your preferred ISA would barely change anything. (If they help at all it's in executing highly dynamic languages as opposed to compiled ones, which makes them a natural target for the in-progress 'J' extension.)

Re: Addressing Criticism of RISC-V Microprocessors

#83

Post by avianes »

JonChesterfield wrote: post #79
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

32 bit, 32 registers, three register code. So add r0 r1 r2 spends fifteen bits on identifying which register to use then another two on the compressed ISA. That's half the encoding space gone before identifying the op. Never thought I'd want fewer registers but here we are. If the compressed extension is great in practice it might be a win. If the early criticism of overfit to gcc -O0 proves sound and in practice com…

The encoding space is not the number of bits used to encode an instruction, the encoding space is the ratio of values that encode a valid instructions over the total number of instructions that could be encoded.

As an example, in an ISA with 8-bits fixed instruction length and 8 registers (reg index encoded on 3 bit):

If the last 2 bits are the opcode and we define 2 instructions (eg. AND, XOR) that manipulate 2 registers (3 bits + 3 bits), then instruction word values 0b00_000_000 to 0b01_111_111 might encode these two instructions (ignore "_" they are separators).

Therefore, instruction word values from 0b10_000_000 to 0b11_111_111 remain free, which represents half of the encoding space. So half of the encoding space remains free.

This means we still have room to put new instructions.

Similarly, RISC-V valid instructions use almost all the available bits, but there is still room in the encoding space because some opcodes remain free.

Re: Addressing Criticism of RISC-V Microprocessors

#84

Post by socialdemocrat »

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.

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 anything the problem is nearly always about having to support old junk which no longer makes sense to support, or lacking the ability to grow. Remember 640K is enough for everyone? RISC-V has a lot of room to grow.

If you want an architecture for the future you would want a minimalist one with room to grow a lot. By keeping the instruction count very low and building in a system for extensions they have made a future proof ISA. Okay we cannot know the future, but it is more likely to survive for decades than something like x86 or maybe even ARM.

Re: Addressing Criticism of RISC-V Microprocessors

#85

Post by socialdemocrat »

jfkimmes wrote: post #25

I get "To keep reading this story, get the free app or log in. (With Facebook or Google)" on mobile. No thanks, Medium. These dark patterns crop up everywhere lately...

It is for authors like me writing on Medium, to have a way of getting paid. There is a need for both paid and free content. But reality is that you cannot produce quality content if everything has to be free. Advertisement is one solution, but one not without its own serious drawbacks.

Medium is a like a magazine with a very large number of journalists which it pays to write for it. Naturally it needs to charge subscribers to make an income.

Re: Addressing Criticism of RISC-V Microprocessors

#86

Post by klelatti »

avianes wrote: post #34
JonChesterfield wrote: post #31

Earlier quoted context omitted.

Iirc compressed instructions are the thing that costs 2 bits per 32 and was criticised as overfitted to naive compiler output. Am I thinking of something else?

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?

Re: Addressing Criticism of RISC-V Microprocessors

#87

Post by FullyFunctional »

avianes wrote: post #21
FullyFunctional wrote: post #13

Earlier quoted context omitted.

I am obviously aware and I'm here to tell you that the overhead of variable length instructions matters more. Arm agrees. M1 has a 192 KiB I$ btw. ADD: had RISC-V just disallowed instructions from spanning cache lines and disallowing jumping into the middle of instructions then almost all of the issues would have gone away. Sigh.

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+ instructions per cycle.

Re: Addressing Criticism of RISC-V Microprocessors

#88

Post by tsmi »

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…

People argue over these minimal differences for good reasons.

If = binary size, and I'm buying ROM in volume to hold that binary, +10% ROM address space can easily cost more than the ARM license.

That can matter quite a lot for adoption. Especially in the short term.

Obviously, priorities differ and change as a function of time but as the saying goes, the only thing worse than making a decision with benchmarks is making a decision without benchmarks.

Re: Addressing Criticism of RISC-V Microprocessors

#89

Post by socialdemocrat »

Someone wrote: post #64
socialdemocrat wrote: post #53

Earlier quoted context omitted.

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

> There has been ARM fans claiming that conditional instructions make ARM superior for simple chips. For those following this only from the sidelines, it would help strengthen the article if the article has links to such claims. I couldn’t easily find them, and would be curious as to their age, given that, reading https://en.wikipedia.org/wiki/Predication_(computer_architec... , ARM has made substantial changes to co…

If there was some good articles to point to I would. However I don't want to single out people ranting against RISC-V. This is more about opinions which keep popping out here in Hacker news, twitter, Quora and other places. I don't want this discussion to be turned personal.

It should be possible to discuss these opinions without singling out anyone.

I am however talking about claims put forth after ARMv8. The argument here has basically been this: Both ARM and RISC-V aims to cover both the low end and high end. Some ARM fans think that by not including conditional instructions RISC-V really only works for high-end CPUs. The idea here is that AArch32 would be better than RV32 for lower-end chips.

Re: Addressing Criticism of RISC-V Microprocessors

#90

Post by tsmi »

damageboy wrote: post #69
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…

Thank you for writing the obvious. Instruction Byte count is the wrong metric here 100%. Instruction Count (given reasonable decoding/timing constraints) is the thing to optimize for and indeed variable length encoding is very bad.

Instruction byte count matters quite a lot when you're buying ROM in volume. And today, the main commercial battleground for RISCV is in the microcontroller space where people care about these things.
Post reply on HN