Hacker News Reader

Comment by 01100011 | Hacker News Reader

Does anyone know how well RISC-V will be able to compete with ARM in the higher end? It seems pretty easy to come up with a processor design that is competitive in low-compute load applications, but what about more advanced designs? I'm curious what it is that ARM brings to the table there and if there is a chance that RISC-V will ever offer serious competition.

Certainly RISC-V does not need to be the best to survive as a viable option for most designs. It may absorb a lot of market share from ARM in the long run. It will be interesting to see how it develops.

View on HN

The RISC-V spec is not finished yet.

RISC-V is a modular ISA, the base ISA contains only the minimum that must be included for all architectures. The basic ISA therefore excludes multiplications, divisions, float, atomic, SIMD, etc. The base ISA can only be used for small, minimalistic microcontrollers.

For more advanced microcontrollers, ISA extensions add Multiplications/divisions, Float32, ... (extensions M, F, ...).

For higher performance architectures you must add ISA extensions such as Atomics, SIMD/Vectors, ... (extensions A, P/V, ...).

(I intentionally exclude some details and other extensions to illustrate the benefits of the modular ISA)

Some of these extensions have a frozen spec, and some still open. Therefore RISC-V does not yet offer a complete solution to compete with ARM or x86. And currently RISC-V is perfect to target microcontrollers.

However RISC-V is designed to be competitive, as the instructions are designed to be compatible with existing optimizations for modern superscalar processors architectures.

So yes, there is a chance that RISC-V will become a serious competitor in the future.

Or fragmented like Linux distros, as it remains to be seen what extensions will be freely available, and certified as correctly implemented at the hardware level.

All extensions published by the RISC-V Foundation will be freely available, with verification tools.

Linux distributors are attempting to define a base spec (see the Unix Platform Spec group at the Foundation) which will define a minimum set of required extensions, and all other extensions will be optional and detected at runtime. We (Red Hat) are working with Debian, SUSE and Canonical on this.

It's possible in future that extensions will move from optional to required if they become popular and widely implemented. Apart from embedded (where, frankly, like ARM anything goes) Linux will not be fragmented.

Really?

I expect a future, where like Linux and BSD downstreamers, there will be OEMs with their own proprietary extensions using them as means of business differentiation.

Oh for sure I expect private extensions - in fact there's even a namespace for them in the RISC-V specs. A bigger problem is not private extensions, but companies adding ad hoc MSRs and instructions, and in fact one company has already done that. Most likely we'll ignore these and try to work with the companies to get them to do the right thing in future.

Note that Intel also provides private extensions to their best customers. (I believe they are fused off in chips sold to general customers.)

I don't really understand your comparison with linux distros.

Of course extensions will be fragmented, each chip will only embed a faction of the ISA according to its range of application. But Linux distro are not made to be "modular".

Can you elaborate on your thoughts?

Same will happen regarding OEMs doing their own stuff (ISA extensions) that won't ever get upstream.

So there will be applications or compilers only available from vendor X.

Yes, only standard extensions will be supported by all compilers.

Why is this a problem?

If a company needs to design its own extension for its specific application, RISC-V allows it.

And it will never get upstream, because it is only relevant for this specific application. And if this application is needed by many vendors, then it means that a standard extension must be designed.

Think Android, but RISC-V ISA instead.

Android is not fragmented, it is easy to write applications that run well on all android versions. The problem RISC-V faces is that one or more companies start to grow a significant market with non-compliant chips, basically the browser war scenario.

Said the one that never had to deal with background activities or firmware issues across the eco-system.

yep, that is me, I thought that the main issues were around deprecated features in newer API versions, I guess I was wrong.

> The problem RISC-V faces is that one or more companies start to grow a significant market with non-compliant chips, basically the browser war scenario.

The CPU market today is even more closed to competition than web browsers. RISC-V does not "face this problem", this problem already existed before RISC-V.

But RISC-V could make this market more competitive. If there is a royalty free standard on top of which all modern CPUs are built (the RISC-V ISA), then a newcomer can easily use it and take advantage of the tools which go with it.

But companies remain free to diverge from this standard by adding their own non-standard extensions.

That's actually the wrong way round.

For advanced designs the instruction set really doesn't matter that much, the bulk of the silicon in a modern advanced CPU is spent doing things like caching, branch prediction, instruction scheduling, buffering loads and stores that may be unwound due to speculation, address translation, etc. These things are completely instruction set agnostic. To see how little it matters look how well x86 processors work despite the x86 instruction set being a mess (even figuring out how long an instruction is in bytes is a nightmare) or how well advanced ARMv7 processors despite that instruction set being a mess (a free shift on every immediate, urgh).

Now low-power is a completely different game. The bulk of the CPU is spent doing really quite basic stuff, fetching instructions, decoding instructions, simple ALU ops. Tiny differences to the instruction set can make a big difference to how much silicon (thus power) this takes. This is why RISC-V offers a 'reduced' variant (with only 16 registers), they know that for any low-power design the vast majority of silicon area is just going to be spent on flip-flops or latches for the 32 entry register file (what a waste given the tiny performance bump in moving from 16 to 32 registers). That's a lot of leakage power for no reason.

Now RISC-V is not necessarily a great instruction set, but it's not really an awful instruction set either (from a pure perspective of implementing an efficient 32-bit CPU, I'm sure it has academic advantages). For example nobody implements a RISC-V CPU without the 'C' extension (16-bit instructions) and given that they really should have just made all instructions 16-bit with optional 16-bit or 32-bit payloads (typically immediates). This would have meant it was only a single instruction to load a 32-bit constant rather than two and code density would be higher (thus less power spent fetching and decoding instructions). On the other hand you'd have a lot less extensibility available. Probably this would require 16 registers instead of 32 (not enough bits in the 16-bit instructions otherwise), but again this is a good thing for lower power in small CPUs.

So RISC-V will never be the best instruction set for low-power 32-bit CPUs, but it's definitely better than x86 and ARMv7, and that's probably enough. And for 'advanced' designs it just doesn't matter, it's all about the quality of the implementation.

Personally I dislike RISC-V but I will still use it for implementing CPUs (and already have) due to the toolchain support. Designing your own instruction set is fun but porting a compiler is not, and RISC-V is sufficiently 'not bad' that it does the job. I imagine a lot of people feel similarly.

I like RISC-V and I like RV32E, the 16-register variant which is still 'OPEN' and not yet ratified. I think RVC is a very elegant compressed instruction approach; it can address 8 registers and is part of RV32E. RVC is far better than the Thumb or MIPS16 modes.

Yeah, I like RISC-V generally, especially the base and the vector extension. However, they really went off the rails with the Bit Manipulation Extensions [1] still in draft form. Compare bfp which mixes control + data in the same register with ARMv8 bfi. It's only been added since the 0.92 draft but it seems to me very un-RISC-like.

[1] https://github.com/riscv/riscv-bitmanip

I think you'll find that cutting out 16 registers wins you less area than it costs you in code ROM; and at a given execution speed target, you'll be costing yourself in power and area to make up for it.

There may be some kinds of software where this is not an issue, but for a lot of common types of software, 16 registers just keeps losing.

It’s not about the die area, but rather the instruction encoding space. And because you can freely mix and match long and short instructions, in practice it doesn’t matter much.

> For advanced designs the instruction set really doesn't matter that much

I disagree.

For high performance applications some extensions are required. That's why x86 has so many extensions such as AVX.

Most of x86's notable extensions are to provide increasingly wide SIMD registers, which risc-v solves with proper vector instructions.

Though there are, of course, other useful extensions like fast syscalls.

> Personally I dislike RISC-V

outside of the above 16 vs 32-bit instruction dichotomy, what makes it not good in your opinion?

is it more implementation-wise, or spec-wise? or, just how its managed?

i like it, but im not a pro in this area, so im very interested ^^

The "Shakti" open source processor from the Indian Institute of Technologies(IIT) is worth looking at for a comprehensive roadmap and vision based on RISC-V. Take a look at the available documents/software at https://shakti.org.in/

I'd say that depends on the higher end of what? Control over the firmware, understanding of the actual bits you're flipping and the architecture, power consumption, or raw computer per clock?

I’m not parent but personally I’m interested in performance per Watt

The ISA design has very little impact on actual energy consumption rather than an actual CPU's uArch. This is a conception that hasn't been true for at least 20 years.

It was somewhat true in the days where memory was expensive, and so smaller instructions were a good idea. But this came at the cost of increased area and thus energy (since you need more decoding logic).

As time went on, transistors shrank, so this cost kept decreasing; at the same time, memory got better and we developed techniques to hide the latency more, so the upside also kept decreasing.

Ultimately in modern times any difference in ISA results in some ~1% difference in energy consumption. You would gain far more efficiency (on the order of 2.5x) in just designing your uArch in a better way-- say, in-order vs OoO. [1]

In my opinion, the reason CISC vs. RISC is still very alive today is because ARM has done a fabulous job in marketing and executing itself as energy efficient. The big.Little architectures are an example in cementing this idea.

Conversely, Intel has done a similarly fabulous job in marketing and executing itself as performant, allowing both companies to live happily in their respective areas. The introduction of hyperthreading is another example of pushing this edge.

But these design decisions are NOT ISA intrinsic, and these misconceptions are changing incredibly fast (though I think ARM is doing a much better job than Intel at changing these paradigms).

[1] https://research.cs.wisc.edu/vertical/papers/2013/hpca13-isa...

> ARM has done a fabulous job in marketing and executing itself as energy efficient.

To be fair to ARM, they actually have produced energy efficient processors. I don't know a lot about ARM processor internals, but I've seen some presentations from many years ago and they had clever tricks for saving power while running, such as only charging some transistors during part of a clock cycle.

That doesn't mean the ISA is the reason for power efficiency, it means ARM designs have other tricks as well. Or at least, they used to.

I thought the world, the internet would have learned by now it was never ARM ISA vs x86 ISA or RISC vs CISC.

Edit: Read jleahy's reply

The X Factor here is how well Nvidia handles ARM and what it prioritizes.

As complicated as CPU design is, corporate politics can be downright inscrutable.

Reply on news.ycombinator.com