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

41–50 of 149 posts

Re: Addressing Criticism of RISC-V Microprocessors

#41

Post by BirAdam »

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 wrong. I was very skeptical of RISC-V until I recently heard Jim Keller explain why RISC-V has a bright future. He was rather convincing. This is especially true given his track record of straight-up magical results. Looking at different RISC-V machines, I think that the greatest advantage is that it is simple and can therefore be optimized more easily than complex designs, and due to being open, it has very low cost which will encourage more eyes trying more and different optimizations.

EDIT: Link to Jim Keller interview https://www.anandtech.com/show/16762/an-anandtech-interview-...

Re: Addressing Criticism of RISC-V Microprocessors

#42

Post by nnx »

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 recently heard Jim Keller explain why RISC-V has a bright future

Would like to hear it too. Can you share a link?

Re: Addressing Criticism of RISC-V Microprocessors

#43

Post by BirAdam »

nnx wrote: post #42
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 recently heard Jim Keller explain why RISC-V has a bright future Would like to hear it too. Can you share a link?

Updated my response to include a link to the transcription. The audio/video is here: https://www.youtube.com/watch?v=AFVDZeg4RVY

It’s actually important (if you’re not an engineer) to listen to the whole thing, because he drops knowledge all over the place.

Re: Addressing Criticism of RISC-V Microprocessors

#44

Post by ansible »

ajb wrote: post #32
adrian_b wrote: post #17

Earlier quoted context omitted.

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 extra expense is not the generation of the overflow bit, but the infrastructure needed to support a flags register, or for every instruction to be able to generate an exception. On a simple processor like a microcontroller this doesn't cost much, but it's severely hampers a superscalar or out of order processor, as it can't work out very easily which instructions can be run in parallel or out of order. The clean…

> The clean solution from a micro architectural point of view would be to have an overflow bit (or whatever flags you wanted) in every integer register.

That's what the Mill CPU does. Each "register" also had the other usual flags, and even some new ones like Not a Result, which helps with vector operations and access protection.

Re: Addressing Criticism of RISC-V Microprocessors

#45

Post by brucehoult »

I am so bored with people criticising RISC-V based on tiny code snippets of things that basically never happen in real code.

A function that does nothing but return an array element from an array base address and index passed to it? Really? Do you actually write junk like that? And if you write it does your compiler really not inline it? Why? Do you like big slow code? Once it's inlined, it's probably in a loop, and strength-reduced.

It's very easy to verify that in the real-world RISC-V code is more compact than amd64 and arm64. Just download the same version of Ubuntu or Fedora (etc) for each one and run the "size" command on the binaries. The RISC-V ones are consistently significantly smaller.

You can also, with quite a bit more work, count the number of µops each ISA executes. RISC-V executes slightly more instructions, but they are each simple and don't need expanding. Lots of x86 instructions get expanded into multiple µops and many 64 bit ARM instructions do too. In the end the number of µops executed by each is very similar.

Trying to judge the goodness of a modern ISA by looking at two or three instruction snippets is as silly as using Dhrystone as your only benchmark program.

Re: Addressing Criticism of RISC-V Microprocessors

#46

Post by pjmlp »

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…

It isn't odd at all, this is the kind of usual narrative when selling stuff to an audience that only has a passing knowledge of all issues.

So anyone that isn't deep into ARM architecture will indeed buy into the arguments being made, as they can't assert otherwise.

Re: Addressing Criticism of RISC-V Microprocessors

#47

Post by audunw »

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 if I've understood correctly)

I'm sure there are some bad decisions in RISC-V, but I've yet to see one that isn't in the process of being remedied. There was a good argument for a lack of POPCOUNT instruction being bad, but I think that's being added soon

Re: Addressing Criticism of RISC-V Microprocessors

#49

Post by audunw »

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…

Why do you list code density as a potential disadvantage? With changes to the ISA that has already been approved, RISC-V will have the best code density of any significant ISA in real-world code.

The article touched on this briefly so it's odd that you would claim this without a source for the claim. I know there's some outdated benchmarks where it's slightly worse than Thumb for instance. But then Thumb isn't relevant for desktop CPUs.

The downside for RISC-V for high end desktop/laptop is lack of a large commercial backer (someone like Apple could pull it off, but clearly they've bet on ARM,which was clearly the right choice since RISC-V was far from ready). Lack of the huge legacy of tool chains and software built around x86 and ARM is also obviously a huge disadvantage.

But you could have said the same about ARM back in the day. The thing is I'm not sure if the advantages for RISC-V is big enough to take over all of ARMs markets the way ARM has the potential for with x86.

Re: Addressing Criticism of RISC-V Microprocessors

#50

Post by audunw »

devit wrote: post #37

I think the biggest issue is the lack of arithmetic with overflow checking, especially with a variant that calls a location in a control register on overflow. This makes it very inefficient to compile languages that would like overflow checks on all arithmetic.

A comment elsewhere here pointed out that RISC-V can do it with two fused compressed instructions for the most common operations. So seems like they did the right trade off to me.
Post reply on HN