RISC-V is not anywhere near competitive to ARM at the level that Qualcomm operates.
I’ve written about that here: https://benhouston3d.com/blog/risc-v-in-2024-is-slow
I’ve written about that here: https://benhouston3d.com/blog/risc-v-in-2024-is-slow
They pivoted to embedded shortly after spinning off into a separate company.
Acorn Computers started off much earlier (I owned an Acorn Atom when it was released) which begat the Electron, then the BBC Micro and then the Archimedes.
At that time ARM was just an architecture owned by Acorn. They created it with VSLI technology (Acorn’s Silicon partner) and used the first RISC chip in the BBC Micro before then pivoting it to the Archimedes.
Whilst Acorn itself was initially purchased by Olivetti, who eventually sold what remained years later to Morgan Stanley.
The ARM division was spun off as “Advanced RISC Machines” in a deal with both Apple, and VSLI Technology after Olivetti came onto the scene.
It is this company that we now know as Arm Holdings.
So it’s not entirely accurate to claim “they had a full computer system” as that was Acorn Computers, PLC.
Some of the other details you have are wrong too, to the point your comment is really quite misleading.
Anyone wanting an accurate version should check wikipedia: https://en.m.wikipedia.org/wiki/Acorn_Computers
(To be blunt the above comment is like a very bad LLM summary of the Acorn article).
As far as I am aware, there is nothing about the RISC-V architecture which inherently prevents it from ever being competitive with ARM. The people designing their own cores just haven't bothered to do so yet.
RISC-V isn't competitive in 2024, but that doesn't mean that it still won't be competitive in 2030 or 2035. If you were starting a project today at a company like Amazon or Google to develop a fully custom core, would you really stick with ARM - knowing what they tried to do with Qualcomm?
Having a competitive CPU is 1% of the job. Then you need To have a competitive SoC (oh and not infringe IP), so that you can build the software ecosystem, which is the hard bit.
Edit, link: https://box86.org/2024/08/box64-and-risc-v-in-2024/
This meant that you had (a) strong demand for ARM apps/libraries, (b) large pool of testers, (c) developers able to port their code without needing additional hardware, (d) developers able to seamlessly test their x86/ARM code side by side.
RISC-V will have none of this.
I think people are blind to the amount of pre-emptive work a transition like that requires. Sure, Linux and FreeBSD support a bunch of architectures, but are they really all free of bugs due to the architecture? You can't convince me that choosing an esoteric, lightly used arch like Big Endian PowerPC won't come with bugs related to that you'll have to deal with. And then you need to figure out who's responsible for the code, and whether or not they have the hardware to test it on.
It happened to me; small project I put on my ARM-based AWS server, and it was not working even though it was compiled for the architecture.
Having a clear software stack that you control plays a key role in this success, right?
Wanting to have the general solution with millions of random off label hardware combinations to support is the challenge.
When it comes to the adoption of a new ISA, there are no odds even the sources exist, it is the scale and QA that are or are not.
The arrival of the first wave of Apple Silicon in 2020 led to a very hectic year in 2021 and beyond of people rushing in to fix numerous issues mostly (but not only) in Linux for aarch64, ranging from bugs to unoptimised code. OpenJDK that had existed for aarch64 for some time was so unstable that it could not be seriously used natively on aarch64, and it took nearly a year to stabilise it. Hand-optimising OpenSSL, Docker, Linux/aarch64 and many, many other packages also took time.
It only became possible because of the mass availability of the hardware (performant consumer-level arm64 CPU's) that has led to a mass adoption of the hardware architecture at the software level. aarch64 has now become the first-class citizen, and Linux as well as other big players have vastly benefited from it (e.g. cloud providers) as a whole. It is far being certain that if not the Apple Silicon catalyst we would have seen Graviton 4 in 2024 (the 4th gen in just 5 years), large multi-core Ampere CPU's in 2023/24 and even a performant Qualcomm laptop CPU this year.
Mass hardware availability to lay people that leads to mass adoption by lay people is critical to the success of a new hardware platform, as all of a sudden a very large pool of free QA becomes available that spurs further interest in improving the software support. Compare it, for instance, with the POWER platform that is open and the hardware has been available for quite a while; however, there has been no scale. The end result is that JIT still yields poor performance in Firefox/ppc64. Embedded people and hardware enthusiasts are not the critical mass that is required to trigger a chain reaction that leads to platform success, it is the lay people incessantly whining about something not working and reporting bugs.
Then there is also a reason why OpenBSD still holds on to a zoo of ancient, no longer available platforms (including a Motorola 88k) – they routinely compile the newly written code – however many moons it takes them to do it – and run it on the exotic hardware today with the single narrow purpose of trapping bugs, subtle and less subtle ones, caused by architectural differences across the platforms. Such an approach stands in stark contrast to the mass availability one; it does not scale as much, but it is a viable approach, too. And this is why the OpenBSD source code has a much better chance of running flawlessly on a new ISA.
Hence, hardware platform adoption is not a simple affair as some enthusiastically try to portray it to be.
not that your point is wrong, but for mose uses it doesn't matter. It would be better if they had it but they don't need it.
Precisely. Embedded cares only about one thing: «get the product off the ground and ship it fast, bugs including». And since the software in embedded is not user-facing, they can get away with «power cycle the device if it stops responding» recommendations in the user guide.
Embedded also sees the CPU as a disposable commodity and not a long term asset, and it is a well entrenched habit of throwing the entire code base away if another alternative CPU/ISA (cheaper, more power efficient etc – you name it) comes along. Where is all the code once written for 68HC11, PIC, AVR etc? Nowhere. It has all but been thrown away for varying reasons (architecture switch, architecture obsolescence and stuff). Same has not happened for Intel, and the code is still around and running.
For more substantial embedded development, the responsibility of adopting a new ISA falls on the vendor of the embedded OS/runtime (e.g. VxWorks or the embedded CPU vendor) who makes reasonable efforts of supporting hardware features important to customers but does not carry out the extensive testing of all features. Again, the focus is on allowing the vendor's customers to ship the product fast. Quality of development toolchains for embedded is also not so infrequently questionable and complaints about poor support of the underlying hardware are common. They are typically ignored.
> but for mose uses it doesn't matter […]
Which is why embedded is not a useful success metric when it comes to predicting the success of a CPU architecture in user-facing scenarios (namely, personal and server computing).
We still have problems with software not being optimised for Arm these days, which is just astounding given the prevalence on mobile devices, let alone the market share represented by Apple. Even Golang is still lacking a whole bunch of optimisations that are present in x86, and Google has their own Arm based chips.
Compilers pull off miracles, but a lot of optimisations are going to take direct experience and dedicated work.
Golang's compiler is weak compared to the competition. It's probably not a good demonstration of most ISAs really.
I think the keys to Risc-V in terms of software will be,
LLVM (gives us C, C++, Rust, Zig,etc), this is probably already happening?
JavaScript (V8 support for Android should be the biggest driver, also enabling Node,Deno,etc but it's speed will depend on Google interest)
JVM (Does Oracle have interest at all? Could be a major roadblock unless Google funds it, again depends on Android interest).
So Android on Risc-V could really be a game-changer but Google just backed down a bit recently.
Dotnet(games) and Ruby (and even Python?) would probably be like Go with custom runtimes/JIT's needing custom work but no obvious clear marketshare/funding.
It'll remain a niche but I do really think Android devices (or something else equally popular, a chinese home-PC?) would be the gamechanger to push demand over the top.
The new (but tier1 like x86-64) Debian port is doing alright[0]. It'll soon pass ppc64 and close up to arm64.
Lack of reg+shifted reg addressing mode and or things like BFI/UBFX/TBZ
The perpetual promise of magic fusion inside the cores has not played out. No core exists to my knowledge that fuses more than two instructions at a time. Most of those take more than two to make. Thus no core exists that could fuse them.
Whether prebuilt distribution binaries support it or not, I can't tell. Simple glance at Debian and Fedora wiki pages doesn't reveal what profile they target, and I CBA to boot an image in qemu to check. In the worst case they target only GC so they won't have Zba. Source distributions like Gentoo would not have a problem.
In any case, talking about the current level of extension support is moving the goalposts. You countered "there is nothing about the RISC-V architecture which inherently prevents it from ever being competitive with ARM" with "Lack of reg+shifted reg addressing mode", which is an argument about ISA, not implementation.
25.10 -> RVA23
26.04 (LTS) -> RVA23
where are they?
On the open-source front, I can right now download a RVA23 supporting RISC-V implementation, simulate the RTL and have it out perform my current Zen1 desktop per cycle in scalar code: https://news.ycombinator.com/item?id=41331786 (see the XiangShanV3 numbers)
How long is this supposed to take?
How long until it is accepted that RISC-V looks like a semiconductor nerd snipe of epic proportion designed to divert energy away from anything that might actually work? If it was not designed for this it is definitely what it has achieved.
The absolutely essential bitmanip and vector extensions were just ratified at the end of 2021 and the also quite important vector crypto just in 2023.
Somehow I suspect in 10 years there will be a new set of extensions promising to solve all your woes.
Seriously, the way to do this is for someone to just go off and do what it takes to build a good CPU and for the ISA it uses to become the standard. Trying to do this the other way around is asking for trouble, unless sitting in committees for twenty years is actually the whole idea.
The base specifications in RISC-V were only ratified in 2019.
Source: https://riscv.org/about/#history
Both are milestones that paved the way to RISC-V's base spec ratification in 2019.
Incidentally, the Earth is estimated to be 4.54 billion years old.
It's actually worse than that, because until it's done there's no guarantee it will ever get there.
That's RVA22 and Vector 1.0.
Low-end hardware implementing the spec already exists (Milk-V Jupiter). High end implementations (e.g. Ventana Veyron V2, designed for servers) will be deployed in 2025.
Assuming you are right, getting on for four years after even this we would have a high performance implementation of it to look at which proves that it really is everything needed . . .
Except we don't.
Until we do all you have is a dream.
Typically (and quite consistently) there are 3 years from that point to products you can buy cheaply sitting on shelves.
Thus, expect some fun in 2025.
To re-iterate: you have no basis for saying it is high performance because it has not been shown to be so.
When a track record has been established _then_ claims of this kind can be made, but not before.
I have worked with chip makers at both ends (I was doing games which they used for testing, but they also tried to get our input for what their next designs should do) and honestly learned that these people are absolute dreamers. This was not helped by the nearly constant regularity with which we found performance destroying design flaws. Some prototypes were aborted as a result (dramatic overheating is quite a problem) but most products launched to go nowhere since they were now unspectacular.
The dreaming is necessary to enable them to get up and try again, but it means you should not believe a word they say until it works.
It is also unreasonable to think that each and every industry veteran who has designed successful, competitive high performance microarchitectures in the past and is now working on RISC-V IP is for some reason suddenly unable to deliver.
Waiting will give you confirmation, in the form of seeing your competitor's successful products in the market, but at the cost of missing your own chance.
¯\_(ツ)_/¯
Essential for what? RISC-V was not just created for high performance of application cores.
The first couple years RISC-V was mostly for university research work.
Turning it into a fully capable alternative only started later and yes, that takes a number of years.
> Somehow I suspect in 10 years there will be a new set of extensions promising to solve all your woes.
Its about delivering the same as Intel/ARM and they have that now. Yes, in 10 years more extentions will exist, this is true for RISC-V and ARM and x86.
> Seriously, the way to do this is for someone to just go off and do what it takes to build a good CPU and for the ISA
No it doesn't happen that way because the company wouldn't do that wouldn't open source their ISA design. Or at least not historically.
So a different path was taken to create and open standard and it worked out pretty well, even if it doesn't do what your imagination wants.
We can't know and won't for up to until 2030 or 2035. Humans are just not very good when it comes projecting the future (if predictions of 1950-60's were correct, I would be typing this up from my cozy cosmic dwelling on a Jovian or a Saturnian moon after all).
History has had numerous examples when better ISA and CPU designs have lost out to a combination or mysteries and other compounding factors that are usually attributed to «market forces» (whatever that means to whomever). The 1980-90's were the heydays of some of the most brilliant ISA designs and nearly everyone was confident that a design X or Y would become dominant, or the next best thing, or anywhere in between. Yet, we were left with a x86 monopoly for several decades that has only recently turned into a duopoly because of the arrival of ARM into the mainstream and through a completely unexpected vector: the advent of smartphones. It was not the turn than anyone expected.
And since innovations tend to be product oriented, it is not possible to even design, leave alone build, a product with something does not exist yet. Breaking a new ground in the CPU design requires an involvement of a large number of driving and very un–mysterious (so to speak) forces, exorbitant investment (from the product design and manufacturing perspectives) that are available to the largest incumbents only. And even that is not guaranteed as we have seen it with the Itanium architecture.
So unless the incumbents commit and follow through, it is not likely (at least not obvious) that RISC-V will enter the mainstream and will rather remain a niche (albeit a viable one). Within the realms of possibility it can be assessed as «maybe» at this very moment.
I would bet on china making risc-v the default solution for entry level and cost sensitive commodity devices within the next couple of years. It’s already happening in the embedded space.
The row with Qualcomm only validates the rationale for fast iterating companies to lean into riscv if they want to meaningfully own any of their processor IP.
The fact that the best ARM cores aren’t actually designed by ARM, but arm claims them as its IP is really enough to understand that migrating to riscv is eventually going to be on the table as a way to maximize shareholder value.
Business are actually happen how the ALA is proven in court.
Ventana announced their second-gen Veyron 2 core at the beginning of this year and they are releasing a 192-core 4nm chip using it in 2025. They claim Veyron 2 is an 8-wide decoder with a uop cache allowing up to 15-wide issue and a 512-bit vector unit too. In raw numbers, they claim SpecInt per chip is significantly higher than an EPYC 9754 (Zen4) with the same TDP.
We can argue about what things will look like after it launches, but it certainly crushes the idea that RISC-V isn't going to be competing with ARM any time soon.
SoC designers choose from existing IP blocks, not from existing physical chips.
If qualcomm changes instruction decoding over you’ll likely see a dramatic difference
Also correct: RISC-V is not anywhere near competitive to ARM at the level that Qualcomm operates.
Also, actually searching the chip in question is impossible.
I highly recommend it, most incisive RISC-V article I've read.
Geekbench does indeed not support the Vector extension, and thus yields very poor results on RISC-V.
RISC-V does indeed not have pipeline reordering.
The Geekbench score thing is a strawman invented to distract from that, no one has mentioned Geekbench except the people arguing it doesn't matter. Everyone agrees, it doesn't matter. So why pound the table about it?
But if you're talking IP, which would be what matters for the argument being made (core IP to use on new design), here's where we at (thanks to camel-cdr- on reddit[0]):
(rule of thumb SPEC2006*10 = SPEC2017)
SiFive P870-D: >18 SpecINT2006/GHz, >2 SpecINT2017/GHz
Akeana 5300: 25 SpecINT2006/GHz @ 3GHz
Tenstorrent Ascalon: >18 SpecINT2006/GHz, IIRC they mentioned targeting 18-20 at a high frequency
Some references for comparing:
Apple M1: 21.7 SpecINT2006/GHz, 2.33 SpecINT2017/GHz
Apple M4: 2.6 SpecINT2017/GHz
Zen5 9950x: 1.8 SpecINT2017/GHz
Current license-able RISC-V IP is certainly not slow.
0. https://www.reddit.com/r/hardware/comments/1gpssxy/x8664_pat...