5 ms·

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 competitiv

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.

TimSchumann 6y ago
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?
- mastazi 6y ago
  I’m not parent but personally I’m interested in performance per Watt
  - ljhsiung 6y ago
    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-power-struggles.pdf https://research.cs.wisc.edu/vertical/papers/2013/hpca13-isa...
    - jlokier 6y ago
      > 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.
jleahy 6y ago
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.
- CalChris 6y ago
ksec 6y ago
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
avianes 6y ago
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.
- pjmlp 6y ago
  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.
  - rwmj 6y ago
    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.
    - pjmlp 6y ago
      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.
rramadass 6y ago
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/ https://shakti.org.in/
msla 6y ago
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.

TimSchumann 6y ago

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?

mastazi 6y ago
I’m not parent but personally I’m interested in performance per Watt
- ljhsiung 6y ago
  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-power-struggles.pdf https://research.cs.wisc.edu/vertical/papers/2013/hpca13-isa...
  - jlokier 6y ago
    > 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.

jleahy 6y ago

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.

CalChris 6y ago

ksec 6y ago

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

avianes 6y ago

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.

pjmlp 6y ago
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.
- rwmj 6y ago
  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.
  - pjmlp 6y ago
    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.

rramadass 6y ago

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/ https://shakti.org.in/

msla 6y ago

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.