- cross-posted to:
- [email protected]
- [email protected]
- cross-posted to:
- [email protected]
- [email protected]
Can it topple x86 and Arm, or is the gap too wide to close?
Isn’t China still pushing it hard for reasons of sovereignty? Given China’s surplus manufacturing capacity, that should give it a lift.
yup. There’s loongarch which is much faster (only 1-2 generations behind the latest x86) but it’s proprietary as far as I know.
From what I remember, loongarch is more than 2 generations behind, PR benchmarks notwithstanding.
Google’s temporary retreat on RISC-V is a good example of the kind of basic stumbling block that a new architecture faces on the road towards mainstream - the lack of a mature and unified ecosystem.
I think RISC-V is positioned well to be the preferred architecture for an open ecosystem. But that’s not necessarily going to help it compete. If RISC-V is ever able to compete with Arm it will be because some company developed a chip based on a proprietary implementation of RISC-V, that is able to outperform Arm based offerings in some key way. Proprietary is just more profitable than open, so that’s where the money is going to go, and you need money to compete.
That being said, I’m glad an open standard ISA like RISC-V exists.
Considering how a product hits mainstream is complicated. I assure you that marketing has asked themselves this question for their own businesses for centuries.
To some degree it’s a chicken and egg problem with respect to software namely OS support. it takes a certain minimum inertia to command support. Outside of this, it’ll be by offering a compelling value proposition and claiming space in products that consumers purchase not specifically for its processor architecture but because those products solve a problem.
Google’s temporary retreat on RISC-V is a good example of the kind of basic stumbling block that a new architecture faces on the road towards mainstream - the lack of a mature and unified ecosystem. Most are familiar with the Arm ecosystem, with Qualcomm doing its thing in the laptop market currently with Windows on Arm devices, and Arm already has a foothold in the mobile ecosystem with companies such as MediaTek using the architecture to full effect within its flagship mobiles. But where does RISC-V potentially fit into the equation?
Even Microsoft and Qualcomm are having massive challenges with launching WoA and they’ve been at it for what seems like more than a decade. It’s not only about the smartphone apps, but everything else that comes with it; the whole “supply chain” and ecosystem.
Why you asking me?
I learned that if the headline is a question the answer is always no.
Betteridge’s Law
https://en.m.wikipedia.org/wiki/Betteridge’s_law_of_headlines
That’s perhaps one of the biggest headaches for RISC-V and the architecture as a whole: software compatibility. While both Arm and the x86 ecosystems are extensively supported, the same can’t be said for RISC-V.
I think the future will be that software comes to the end-user device nearly-compiled (think WebAssembly modules) and then is transformed into the final machine code on-device. This way ensures maximum hardware compatibility while retaining portability.
In that case, it doesn’t matter so much what hardware you’re sporting, as long as it supports the basic instructions.
Ecosystem is the key thing here. It’s a hard thing to go from cute embedded nonsense hacks to standard firmware booting distro cdroms/usb sticks and “boring” installs with strong upstream support. I’ve watched this first hand from the Arm ecosystem point of view and I don’t know who or where this work is being driven from for RiscV. Defining the ISA is really just the first step.
Actually it wouldn’t matter whether people used x86 or armv7 if people stopped distributing target-compiled binaries and supported distributing webassembly modules instead. this would also solve different issues, like code transparency (webassembly can be “un-compiled” to a certain extent), portability, and interlinking.
Let me explain the last point (interlinking):
if you have a good library written in languageX and you want to use it in programming languageY, that’s a problem. (for example java library in python). such a thing is often not possible. WebAssembly, however, makes this possible. You can write a library in one language, compile it to webassembly, and then use it in another language. i think that’s a good thing and reduced software redundancy (no need to re-write the same library code for every language.)