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

111–120 of 149 posts

Re: Addressing Criticism of RISC-V Microprocessors

#111

Post by ansible »

tsmi wrote: post #96
BirAdam wrote: post #41

Earlier quoted context omitted.

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

I don't know that such a heavy investment in the toolchains for RISC-V are actually needed.

If you look at generated code, it seems fairly straightforward. There aren't a lot of tricks or anything.

Re: Addressing Criticism of RISC-V Microprocessors

#112

Post by monocasa »

IshKebab wrote: post #105
monocasa wrote: post #67

Earlier quoted context omitted.

> Yes but these are generally linear - if an x86 chip supports extension N it will support extension N-1 too. Not true for RISC-V. Not if you include AMD and Intel cores in that.

Why do you say that? Look here: https://clang.llvm.org/docs/UsersManual.html#x86

That list isn't really an accurate picture of the world, but a vague attempt to make sense of the madness.

There's plenty of cores that don't follow that versioning scheme, and it's not an Intel or AMD construct.

Re: Addressing Criticism of RISC-V Microprocessors

#113

Post by BirAdam »

tsmi wrote: post #96
BirAdam wrote: post #41

Earlier quoted context omitted.

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

I think the serious investment will be from Intel, Apple (with LLVM), and possibly Microsoft (into the GCC/Linux ecosystem).

Re: Addressing Criticism of RISC-V Microprocessors

#114

Post by dgreensp »

wmf wrote: post #91
socialdemocrat wrote: post #84

Earlier quoted context omitted.

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.

IANAE, but the article addresses why the arguments that assume these instructions need to be combined are usually not based on looking at the whole picture.

Re: Addressing Criticism of RISC-V Microprocessors

#115

Post by IshKebab »

mhh__ wrote: post #40
IshKebab wrote: post #36

Earlier quoted context omitted.

What do you mean "no"? My comment was entirely factual. > Firstly -march (or similar, e.g. -mcpu in LLVM land) should target a chip not individual instruction sets. LLVM still uses -march. And no you shouldn't target a specific chip unless you know your code will only run on that chip. That's the whole point I'm making. Sometimes you do know that (in embedded situations) but often you don't . Desktop apps aren't comp…

The LLVM tools (like llc) use -mcpu. Clang mimics GCC. My point about the specific chip is that you have to know it anyway if you're planning on targeting a combination of extensions so you might as well use it. As for linearity, the "generally" bit will apply to RISC-V by the time we have real desktop class chips using the ISA. We still can't assume AVX support for most programs, I don't view this as any different t…

LLVM uses -march and -mcpu. It seems to be a bit of a mess which one you should use and also depend on the architecture.

Time will tell if there's a de facto minimum set of extensions for desktop RISC-V. Let's hope so, but it isn't guaranteed.

Re: Addressing Criticism of RISC-V Microprocessors

#116

Post by Banana699 »

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 article said that it's not the generation and write back of the overflow bits that are the problem, this is basically free, it's the shared state that a status register represents that is the problem. Every single arithmetical/logical operation writes to it, out-of-order execution is already headache-inducing as it is without an implicit argument to most instructions.

Re: Addressing Criticism of RISC-V Microprocessors

#117

Post by brucehoult »

solarexplorer wrote: post #18
TazeTSchnitzel wrote: post #2

The conditional execution section makes no mention of the fact AArch64 doesn't have this feature either, and bizarrely lists a “64-bit” ARM code example that isn't. This doesn't inspire confidence in the author's understanding.

In the same section the part about the SiFive optimization is also misleading. The goal of the optimization is obviously to avoid interrupting the instruction fetch. But he makes it sound like the goal was to reduce instruction count by fusing two instructions to get a single monster op with five (!) register operands. That just doesn't make sense.

They don't fuse it. They have the branch and the following instruction both go down one integer pipeline just as they would if the branch was predicted "not taken. They are linked/tagged together such that if the branch actually happens then the result from the second instruction is simply not written back instead of taking a branch mispredict.

So the four input operands and one output operand are not a problem because that's just what two pipelines do all the time anyway.

Re: Addressing Criticism of RISC-V Microprocessors

#119

Post by brucehoult »

wmf wrote: post #91
socialdemocrat wrote: post #84

Earlier quoted context omitted.

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.

It's not that the examples given are not correct, in isolation, it's that they are not common enough in real code to matter.

Re: Addressing Criticism of RISC-V Microprocessors

#120

Post by brucehoult »

tsmi wrote: post #88
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 mak…

In 64 bit land, RISC-V has consistently the smallest code size. RV64GC, not even using the new things in the B extension that will make code smaller again.

Some data from Ubuntu 21.10 for amd64, arm64, and riscv64:

https://www.reddit.com/r/RISCV/comments/tik718/addressing_cr...

Post reply on HN