Arm execs: We respect RISC-V but it's not a rival in the datacenter Arm executives this week tried to play down the threat of RISC-V to the silicon architect's business. Speaking to reporters at a press event, Dermot O’Driscoll, VP of product solutions at Arm, acknowledged that RISC-V was driving “some competition” against the British chip designer. “It's a very exciting market right now,” he …
RISC-V and ARM are complementary. ARM becomes relatively more expensive at very large volumes but only if you have an army talented and experienced designers. It's difficult to see phone makers moving from ARM because it solves so many of their problems. x86 is expensive from the start and only has the legacy of industry applications to keep it attractive. More and more IaaS providers will be offering ARM as an alternative.
Intel joined RISC-V International earlier this year.
Horse Creek - an Intel RISC-V processor - is expected in a few weeks time.
And Intel have said that they're happy to fabricate any chip design - X86, ARM, RISC-V etc., and are currently helping a number of companies realize their RISC-V designs.
Perhaps X86 is losing (or set to lose) some market share, but Intel have good form in changing when the circumstances demand it.
That's part of Intel's transition to a foundry. They can't hope to compete with TSMC and Samsung if they restrict customers' ability to use the cores they want.
TSMC has some RISC-V core libraries you can plug into your design, so 'Horse Creek' merely matches that capability. Intel is not going to sell RISC-V CPUs as a product, they are making the IP available as a platform for people who want Intel to make the chips for them.
The one thing Intel can offer the others can't is the ability to license and use x86 cores in customer designs, though presumably with some restrictions and obviously not Intel's latest and greatest or anything close to that. Whether there's much demand for that is another matter.
This post has been deleted by its author
It appears that Intel joined the forum to build RISC-V hardware emulators, for RTL design. Intel just recently put these systems up for sale to processor developers. It appears that Intel has never had the intention of developing their own RISC processors, but just the development tools.
Alibaba are believed to be using T-Head's RISC-V C910 in their data centres. (The C910 has an early version of the Vector extension.)
Once chip designs which incorporate the ratified Vector and Matrix extensions come to fruition... then Arm really will have a problem. It's suggested that they'll start appearing mid 2023.
Typical definitions. Right now, what is already on the market. Near future, already tapped out and in validation (can take up to a year). Always a huge deal, marketing wise. Doesn't really matter, engineering wise. I mean, it really doesn't tell you what people are working on, what's already in the pipeline.
I take your point that ARM weren't exactly a fresh-faced upstart with barely a die to their name. (You could say they were very upwardly mobile.) However the people who've moved from Intel to ARM are exactly people who would happily move to RISC-V, as soon as it's ready. ARM doesn't have a padlock on the datacentre like x86 did/does. That was the big shift. If you've done that recently, you should have good understanding of how to repeat it.
And, speaking of Intel lock-in, how is Windows on ARM these days...? Still bumping along the bottom...? Actually, Apple's emulation, is very impressive, if Microsoft can get it that fast, there's no reason it shouldn't take off; old apps are unlikely to be demanding of the hardware. But I don't know how much of Apple's speed comes from their unique architecture. (One charitable reviewer thinks Windows-or-ARM is ready for the stratosphere.) Still, the argument about the datacentre applies to PCs too. If Microsoft have figured it all out, it shouldn't be too hard to get Windows on RISC-V...
The good news for ARM is that they have close to the same lock in on Android that Intel have on the PC. Not withstanding the occasional x86 mobe, or apps being largely java, I can't see that moving away any time soon.
I don't know how Windows on ARM is right now. The problem is that they've announced a lot of things that suggest that it could be pretty good by now: they've got 64-bit emulation, they've got multiple hardware manufacturers, and they have had several generations of software to iron out the bugs. It might work well enough for some use cases. I don't know that though because I don't have any reason to buy a machine. The processors they have from Qualcomm have raw performance better than the low-end laptop chips, but not for high-end machines. Claims of significant improvements in battery life don't appear to be as monumental as they say. I don't have any reason other than curiosity to consider one.
>Actually, Apple's emulation, is very impressive, if Microsoft can get it that fast, there's no reason it shouldn't take off;
Apple haven't emulated x64. They're cross compiling X64 to opcodes to Arm opcodes and storing the results in advance and you end up running software that is already in Arm opcodes. It's slightly chancey because a lot of EULA prohibit such stored translations, but no one dares to sue Apple (such conditions existing specifically because software vendors want to be able to sell a new version, something Apple is preventing). The end result is very good for the end user though!
MS could easily do the same.
If you replace "RISC-V" in that sentence with "Linux" I think it's a Microsoft statement in verbatim, circa 1999.
It's worth realizing that ARM would be another declining Japanese company if it wasn't for phones. Peak phones == Peak ARM. As far as system on chip integration works, ARM's good, RISC is even better. I wonder what Japan's Softbank is thinking.
I agree. RISC-V appears to be following the same foot steps as ARM. First develop embedded processors to get the volume on your side, then move upmarket. All the pieces are there to take RISC-V to the data center and supercomputer realms, does not appear that anyone is going there yet. Remember, it does take significantly longer to develop a datacenter processor, post silicon validation takes more than twice as long. More corner cases, more sense of "state".
Embedded requires better knowledge of time precision of an operation, meaning the difference in time between best case scenario and worst case scenario needs to be minimized. Here, RISC-V appears to do very well, competitively.
ARM was a RISC architecture processor. Since "reduced" and "complex" are vague terms, it's hard to define where the boundary is these days, but ARMV8A has about 1100 instructions (counting has to be done manually from a large set of docs that duplicate them sometimes) and they've been adding extensions for years. ARMV9A may have slightly reduced that by throwing away some 32-bit legacy instructions, but it also has extensions so they likely cancel out to a similar value.
Compared to the 50 core instructions mentioned in RISC-V, that makes ARM a lot more CISCy. I wouldn't expect real world usage of RISC-V to stay that way, at least excluding microcontrollers (ARM's most basic M0 cores also have fewer instructions). People will add extensions, software will come to expect them, and we will stick to a complex architecture.
have an upvote for 'was'.
Lots of instructions have been added since the original concept. It happens with almost all CPU architectures over time.
If you go back to around 1970, the DEC PDP-8 had a very simple (or very reduced) instruction set of 6 instructions.
https://homepage.cs.uiowa.edu/~jones/pdp8/man/mri.html
The original ARM (As in Acorn days) had few instructions compared to what we see today.
The x86 CISC programming model was kept alive - and made increasingly complex - by the PC compatibles of the 80's onwards. Whilst the other CISC devices slowly gave up their positions, often to ARM (e.g. Palm devices started on 68000 derivatives and ended on ARM), PCs wanted to keep the backwards compatibility for End User software.
But all the x86 PCs were also all moving towards RISC implementation, as they shifted to more complex microcoded devices.
So you've been using RISC devices for a long time - just because you don't get to directly code to the RISC instructions doesn't mean they aren't there, doing all the hard work.
Funny how people still think the x86 is CISC..
Having encountered a number of mainframe and minicomputer assembler languages and done several years of x86 assembly programming, when RISC vs. CISC first blow up, I didn't really see the x86 architecture as truly CISC, but more of a RISC architecture with instructions merely being shorthand handles to standardised microcode for many common operations. From memory the comparisons at the time had problems identifying clear water between "true RISC" and x86 instructions...
All CPUs are CISC these days.
Yes, RISC-V is technically a RISC processor, but that's just the core. Most implementations will have extension that are very "complex".
In the end, RISC-V vs ARM vs x86 performance really boils down who has the best extensions (supported in compilers and libraries), as that's where most of the compute speedup comes from.
"The base RISC-V CPU ISA is relatively light and simple, with fewer than 50 instructions, and can be extended as needed by implementers to suit their applications.... extensions include support for floating point math, atomic instructions, vector math, and so on."
The whole concept of RISC was that the bottleneck was in the decoder. Three things happened:
1) heavy use of caching during the 90's hide the problems with CISC architectures
2) The second generation of RISC added instructions, since they did not fit in existing instruction counts, they added escape codes - becoming CISC themselves. Such instructions include the SIMD instructions added by CRAY to their processors.
3) RISC is and was a project out of Berkley. More value from the University was added by supporting current infrastructure, and peripheral needs (OS development (UNIX-bsd), compilers, etc.) Now that we are reaching scaling limits (atomic sizes), reducing transistor count for the same operation once again makes sense (unless we figure out how to make sub-atomic transistors).
I think you're sort of trivializing the discussion.
I understood RISC to be about hardware efficiency - what is it optimized for, how much chip real-estate is devoted to rarely used instructions.
As a hardware goal, RISC was about optimized chip features, and more regular timings, to get higher frequencies. From that pov you could say "RISC won", but really it's "x86 evolved along the demands raised by RISC"
In terms of ISA, CISC has survived and been extended, aided by innovation like micro-ops and better memory controller designs.
Except that, to a large extent, ARM don't have to fight at all. There is huge software inertia behind ARM in certain segments - very notably mobile, and increasingly laptops. It doesn't really matter what RISC-V does in the mobile space, it's always going to come right up against the fact that everyone has built their software for ARM, and has very little motivation to do anything but build their software for ARM. That's the problem Intel and MIPS ran right into, when they tried to take on ARM.
So, to MG's quote properly in the mobile sector one has to turn around the protagonists. It's RISC-V who did the ignoring (they pretended ARM didn't exist). I don't yet see them laughing at Arm, or even trying to fight Arm in the mobile market.
Things can be different where the software market place is a lot less "mass-market" - e.g. private data centres, where the owner probably doesn't mind recompiling their software stack. That is a market where ARM do want to penetrate further. And, sure, the fight is on! ARM is not established there, not in the same way Intel / AMD are.
My view is that we'll see more fragmentation in data centres. They will become "application specific".
I think there are significant motivating factors to rebase open source apps to RISC-V:
- China. The tech trade dispute means that China is working hard on both RISC-V hardware and on rebasing apps to run on RISC-V.
- Industry. Big Tech loves FOSS. It appears to be starting to move towards RISC-V too - no doubt because of its openness. It will sponsor open source software for RISC-V where it's economically profitable for them to do so.
- The open source community is also very excited about consumer grade open source RISC-V. They're going to want the apps they want to use on RISC-V hardware, and will encourage app developers to rebase their work (or will fork it and do the work themselves). Meanwhile they'll make do with alternatives, understanding that the "million apps" thing is a felonious construct.
(A friend of mine recently got LAMP working on his RISC-V Sipeed Nezha. He's now waiting for Wordpress to produce an app. I don't think his wait will be too long, because an alternative will come along if Wordpress are unobliging.)
Given that very large percentage of that software is written in portable languages like C plus the large incentive for major players, especially Chinese, to move towards RISC-V I don't see that as much of an issue.
RISC-V can already run Linux and most GNU tools, which is more than enough for anyone to work with RISC-V based systems. Only device drivers may need to be ported, but that will be done in short order.
Indeed so.
Potentially, Risc-V is its own worst enemy. What it has shown is that, without too much effort, it is possible to define an ISA, get chips made, build a GCC or CLANG for it, and roll all of OSS out on it. If a company really, really wants to gain a market advantage and they're big enough to do it (Google, Alibaba, etc), then they can go fully bespoke with their own CPU, their own closed source compiler, borrow whatever they want from the entirety of OSS, and have a closed, heavily tailored ecosystem.
If they're a private datacentre / web services outfit like Google (i.e. it's only their software running on their computers [I'm ignoring Google's public cloud in this example]), they are not distirbuting software to anyone as such and so can do such things whilst keeping it all in-house.
So for Risc-V, it's openness is a double edged sword. Yes, it's avialable to all to "take on the mighty encumbents" as they wish. But at the same time, it's not so hard to take Risc-V in one's own direction ignoring everyone else and own the entirety of the end result.
This is perhaps why ARM will succeed; their control over what the ISA actually is is a benefit to those device manufacturers who simply want to make devices and sell them to system builders (those who aren't big enough to be able to mint their own chips and compilers). There's not so many system builders who can mint their own chips and compilers, there's a large sea of system builders who need to pick and choose from across the industry. Risc-V's uncontrolled diversity creates an environment where it could actually be annoyingly tricky for such system builders, whereas the more controlled ARM ecosystem makes life a little bit easier.
There have been dozens of ISAs created over the past 50 years - perhaps there's as many as a dozen in a smartphone. Some of the ISAs have been open source (and at least one other continues to be, I believe).
So perhaps it's time to look for other reasons for RISC-V gaining traction.
And so long as chip designers follow the standard for the specific use case; there won't be the fragmentation bogeyman that Arm have tried to create.
This post has been deleted by its author
Sure there is - there's a whole line of constriction from what the end user wants to be able to do, back through the software, to the OEM's choice of processor especially designed for the use case. Nobody's going to spend design time, effort and resources on producing a chip that's not fit for purpose. That's why the RISC-V Foundation publishes standards.
Coming up with your own ISA isn't the problem. It's supporting it and writing and updating all the tools that floors you. And in addition, you need MIND SHARE, to entice other developers to use your ISA and to develop tools, operating systems and drivers for it. This is too much effort for even large companies like Western Digital and Google. They're happy riding along with standard GNU tools and modifying these to suit their needs.
RISC-V currently has this mind share, mostly because Chinese semiconductor manufacturers fear being shut out of the ARM ecosystem in a couple of years. And large companies like WD and Samsung are merely hitching a ride to eek some more profit out of their business with a minimum of investment.
> acknowledged that RISC-V was driving “some competition” against the British chip designer.
> “It's a very exciting market right now,” he said.
> “It helps us all focus and make sure we're doing better.”
Which is precisely what you would expect to hear from a marketing department that was scared spitless of an upstart that threatened their very existence.
RISC-V could well turn out to be the hardware version of Linux. Whether that would be interpreted as something that stays in the margins for decades, or something that disrupts the cosy world of established CPU makers, is the more interesting question.
In the long end ARM will be toast as there's no reason why the RISC-V couldn't migrate to the data-center, the smartphone or desktop. In ARM's words I do sense a bit of worry over the sustainability of their business model. I suspect low-end cores will be produced by Chinese vendors using RISC-V. This will hit ARM midships since that's where the bulk of their licensing revenue comes from.
Eventually ARM will need to match the prices of companies who license RISC-V cores, such as SiFive, to remain competitive. So far I haven't seen any indication that SiFive is any cheaper than ARM, but it may well be. And most larger companies design their own RISC-V cores, such as Samsung, Western Digital et al.
They aren't direct competitors (yet) though.
ARM sell actual core designs and guarantee their performance, while RISC-V is just an ISA - it's not a core.
You need a lot of specialist expertise to turn that ISA into an actual working RISC-V chip, and you don't know up-front what you're going to get because it's not a tried-and-tested design.
The real competitors are the likes of Si-Five who will sell you a tested core design.
I don't think ARM are going to struggle, even if RISC-V does become a mainstream ISA taking away some business from ARM, there will always be a need for ARM compatible cores, its been a ISA that has survived for over 30 years.
Plus there would be nothing stopping ARM adding RISC-V compatibility to their own chip designs since it is an open ISA, just like Intel are offering RISC-V designs even if it might mean they sell less x86-64 CPUs. And ARMs chip designers are very good at what they do, and could create their own RISC-V designs which are better than some of their competitors.
And I'm betting they will lose a significant part of their low-performance core licensing business to RISC-V in the couple of years.
Some of which may even be truly open-source and free to use (I believe there are a couple already).
The higher end stuff will take longer, but even there RISC-V is growing by leaps and bounds.
Taken at its most basic the ARM is just another generic RISC -- multiple registers, three address instruction set, five stage pipeline and so on. Their secret sauce was their conditional instruction execution, its a great idea but I don't know how much its used in practice. So the competition is not going to be about the actual processor core, that's pretty much standardized, but how well one or more cores can be integrated with memory and peripherals. For the low end -- a surprisingly large percentage of processor applications -- this doesn't matter that much, this type of processor has been a standard offering as a soft core by FPGA manufacturers for decades. So I'd expect this ARM business to evaporate over time, leaving just the higher performance designs. This is probably what they meant by 'data center'; here ARM has got a significant lead over RISC-V -- but for how long?
ARM's "every instruction is predicated"?
Looked great in a couple of hand-picked examples in 1985: GCD, software emulation of missing multiply and divide hardware instructions. But not so much in general code.
They didn't include predication at all in Thumb, just traditional conditional branches.
Thumb2 (ARMv7) added back a limited form -- maximum 4 instructions in a row predicated by the same condition or its inverse, controlled by an extra instruction preceding them.
Predication is entirely absent from 64 bit ARM.
Arm had a reputation for smaller code for a given amount of software functionality, I guess for a variety of reasons. Always appealing to those looking to save a micro-buck here and there!
Remember SPARC's sliding stack frames? Great in theory, not much use in practice (and I think dropped). I always admired Sun for giving ideas a go, like asynchronous electronics (used on a memory bus if I recall, was slightly quicker than DDR for at least 3 months), and I think that they were the first to put crypto acceleration into a CPU (which made SPARC really good for https servers).
I miss this kind of thing. Arm is very good, AMD did pretty well with x64, but both are a bit safe (not much eccentricity). Itanium was a disaster and perhaps the last hurrah of "let's try this" where this makes one stop and mutter "whaaaaa?". IBM are still putting some odd (but very rational and effective) things into POWER, but that's about it. What I want is a CPU that natively consume BrainFuck, just for the lolz of having something entertainingly difficult and reassuringly ill advised (financially speaking).
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
