By: Heikki Kultala (heikki.kultal.a.delete@this.gmail.com), May 31, 2022 8:59 am
Room: Moderated Discussions
Peter Lewis (peter.delete@this.notyahoo.com) on May 30, 2022 3:45 pm wrote:
> Jan Wassenberg (jan.wassenberg.delete@this.gmail.com) on May 23, 2022 6:11 am wrote:
> > Some relevant questions:
> > 3) RVV is designed for scaling down. Will RISC-V eventually
> > capture a large share of general purpose computing?
What do you mean by claiming that RVV is designed for scaling down?
To me, it seems overly complex. Way too much state related to the vector configuration.
> I don’t have much of an opinion about your other questions but I will say my opinion about this
> one. If RISC-V has any chance in general purpose computing, the first place we will see it is in Chromebooks
> or web servers. Another place RISC-V could make sense today is in supercomputers, such as those being
> developed by the European Processor Initiative.
EPI is a politically motivated government project, which means it's just a hole to throw money at. They will not get out anything that's even close to commercially viable.
> If Intel or AMD acquires SiFive and Microsoft ports
> Windows to RISC-V, then it is possible that RISC-V could capture a large share of general purpose
> computing, but not before the 2040s.
No. Because technically, RISC-V is clearly inferior to ARMv9.
> I think it is more likely that Apple and Nvidia will eventually
> take over a significant part of the computer market with their ARM products.
Yes. And companies like Samsung might also start making PC-class ARM processor SoC's.
> As more low-performance software is rewritten in JavaScript and Linux becomes more popular on desktops, new
> instruction sets will have more of a chance, but that is a multi-decade process. If binary translation from
> x86 to RISC-V is developed that can translate Windows and Office, that would greatly accelerate the process.
RISC-V just happens to be the wrong "new" instruction set. It's just 1990's again. Technically, nothing new and good about it.
When making a new instruction set, the new instruction set should actually consider all the new developments in the last 25 years, instead of sticking on what was though to be good 25 years ago.
> The technical merits of a processor instruction set have little effect on its market success,
> as the original x86 vs 68000 battle showed. The real determining factors are processor implementations,
> deals with strategic customers, pricing and other business-related things.
Wrong. Instruction set does still matter.
It's just that the metrics used to define "which is better instruction set" used to be wrong. x86 is MUCH better instruction set than generally claimed. Actually, I consider modern x86-64 to be a better instruction set than RISC-V for high performance CPUs, RISC-V lacks for example good addressing modes and predication for scalars, x86 has quite nice addressing modes and conditional moves.
And back in the old days, x86 had also many technical advantages over 68000. For example, it had better code density, and x86 implementation could be clearly smaller than 68k. x86 could probably also clock faster than 68k made on similar mfg process.
> Jan Wassenberg (jan.wassenberg.delete@this.gmail.com) on May 23, 2022 6:11 am wrote:
> > Some relevant questions:
> > 3) RVV is designed for scaling down. Will RISC-V eventually
> > capture a large share of general purpose computing?
What do you mean by claiming that RVV is designed for scaling down?
To me, it seems overly complex. Way too much state related to the vector configuration.
> I don’t have much of an opinion about your other questions but I will say my opinion about this
> one. If RISC-V has any chance in general purpose computing, the first place we will see it is in Chromebooks
> or web servers. Another place RISC-V could make sense today is in supercomputers, such as those being
> developed by the European Processor Initiative.
EPI is a politically motivated government project, which means it's just a hole to throw money at. They will not get out anything that's even close to commercially viable.
> If Intel or AMD acquires SiFive and Microsoft ports
> Windows to RISC-V, then it is possible that RISC-V could capture a large share of general purpose
> computing, but not before the 2040s.
No. Because technically, RISC-V is clearly inferior to ARMv9.
> I think it is more likely that Apple and Nvidia will eventually
> take over a significant part of the computer market with their ARM products.
Yes. And companies like Samsung might also start making PC-class ARM processor SoC's.
> As more low-performance software is rewritten in JavaScript and Linux becomes more popular on desktops, new
> instruction sets will have more of a chance, but that is a multi-decade process. If binary translation from
> x86 to RISC-V is developed that can translate Windows and Office, that would greatly accelerate the process.
RISC-V just happens to be the wrong "new" instruction set. It's just 1990's again. Technically, nothing new and good about it.
When making a new instruction set, the new instruction set should actually consider all the new developments in the last 25 years, instead of sticking on what was though to be good 25 years ago.
> The technical merits of a processor instruction set have little effect on its market success,
> as the original x86 vs 68000 battle showed. The real determining factors are processor implementations,
> deals with strategic customers, pricing and other business-related things.
Wrong. Instruction set does still matter.
It's just that the metrics used to define "which is better instruction set" used to be wrong. x86 is MUCH better instruction set than generally claimed. Actually, I consider modern x86-64 to be a better instruction set than RISC-V for high performance CPUs, RISC-V lacks for example good addressing modes and predication for scalars, x86 has quite nice addressing modes and conditional moves.
And back in the old days, x86 had also many technical advantages over 68000. For example, it had better code density, and x86 implementation could be clearly smaller than 68k. x86 could probably also clock faster than 68k made on similar mfg process.