Hacker News Reader

Comment by ipodopt | Hacker News Reader

The RISC-V ISA would be the better bet.

a. They start investing now and they can have some leverage in the spec.

b. The spec is minimal and open to expansion that it sets itself up for more domain specific processors. Which we will be seeing alot more of thanks to the slowing of transistors per dollar growth.

c. There is a pretty big theme of moving toward more open and democratized standards in tech.

d. They would be the big dogs in RISC-V where as ARM already has big players.

e. In both ARM and RISC-V they would be saving the need for extra transistors. My understanding is that there are extra transistors that basically translate x86 machine code to some internal RISC ISA for performance reasons on x86 processors. Due to the slowing of transistors per dollar growth and the maturation of external Fabs Intel and AMD will no longer be able to 'hide' this deficit.

f. No royalties

View on HN

I'd love to see RISC-V or another open source ISA become the dominant design. But I'm not sure RISC-V is there yet. Companies have been pouring resources into optimizing ARM CPUs for years now, and they're now starting to get to the point where their performance competitive with x86. RISC-V is just getting started. I don't know if there's a RISC-V CPU that's comes anywhere close to the raw performance of higher end ARM CPUs, nevermind x86.

Having said that, I hope AMD doesn't decide not to develop a RISC-V CPU. I'd expect them to have the resources to start working on ARM now, while planning for RISC-V further out.

> Companies have been pouring resources into optimizing ARM CPUs for years now

Yes, companies (Apple especially, but also Samsung and Qualcom) have been making optimized ARM CPUs, but those designs remain within those companies. Very similar optimizations could be made on a RISC-V implementation and AMD has proven that they have the ability to make design optimizations.

> I'd expect them to have the resources to start working on ARM now, while planning for RISC-V further out.

I doubt that strategy would work. The problem in the PC space is that there's no Apple-like leader who can boldy drive a change in CPU architecture. Whoever is first out of the gate bears all the risk of the change not catching on. If you lose the bet, you've wasted massive R&D spend to make a lemon. Take a look at the reviews of Microsoft's ARM surface laptops to see what I mean here.

I think there's an opportunity over the next 5 years or so for PC makers to ride the M1's coattails and shift from x86 to ARM. Especially given intel's failure to move off 14nm. But I doubt lightning will strike twice. If windows moves to ARM now, we'll be stuck there for at least another few decades. And the technical argument for RISC-V will be much weaker if ARM rules the roost.

Weirdly the strongest counterargument I can think of is due to electron. Chrome will maintain first class support for any and every popular CPU architecture. So the more that desktop software is written on the web and in electron apps, the easier any architecture transition will be down the road. That and the server space. Linux already supports RISC-V extremely well given how few linux-capable RV chips there are in the wild.

Not sure if it's still the case but RISC-V was beating ARM in code size as well

I find that a bit surprising since my understanding is RISC-V is more minimal (has fewer higher level instructions) (ATM, that will change with extensions) then ARM.

This paper refutes your point and is inline with my understanding: https://carrv.github.io/2020/papers/CARRV2020_paper_12_Perot...

One counter point is the simpler the ISA the more work the compiler needs to do. So x86 is may be easier to write an optimize compiler for given it does some of the work for you (despite the bloat).

I wonder how much benchmarks on the current ARM and RISK-V chips will change over time due to compiler improvements. ARM probably already has alot of investment in some workloads...

EDIT: This presentation show code size comparisons with a RISC-V extension that adds multiply/divide and it get really close to ARM: https://riscv.org/wp-content/uploads/2019/12/12.10-12.50a-Co...

My understanding was that RV was less dense than the ARM-M Thumb variants, but more dense than AArch64 like these servers would be.

Yes, you are correct. Thanks for pointing that out to me.

With compression and the multiply/divide extensions very similar to the ARM-M Thumb variants in code density.

https://riscv.org/announcements/2016/04/risc-v-offers-simple...

https://riscv.org/wp-content/uploads/2019/12/12.10-12.50a-Co...

Really fun time to be working on this part of the stack.

The paper you linked to is about embedded controller micro-benchmarks being worse by 5-10%; RISC-V's compressed ISA made some tough decisions to improve density on general-purpose code, not just micro-focused on MCUs. On something larger like SPEC, RISC-V is denser than ARM and x86.

The paper/presentation you link to is comparing 32-bit ARM with Thumb and RISC-V. This is mostly relevant to embedded processors, and my understanding is ARM and RISC-V is somewhat equal there.

But for 64-bit, ARM has dropped support for Thumb, while RISC-V still supports compressed instructions. In that case, RISC-V is more dense than ARM. I can't find the numbers for that right now, but I read it just yesterday so I'm pretty sure I remember correctly.

Also keep in mind that Thumb is a mode that the ARM CPU has to switch to, while RISC-V compressed instructions can be mixed with normal instructions.

Reply on news.ycombinator.com