I think Apple did Arm an unbelievable favor by absolutely trouncing all CPU competitors with the M1. By being so fast, Apple's chip attracts many new languages and compiler backends to Arm that want a piece of that sweet performance pie. Which means that other vendors will want to have arm offerings, and not, e.g. RISCv5.
I have no idea what Apple's plans for the M1 chip are, but if they had manufacturing capacity, they could put oodles of these chips into datacenters and workstations the world over and basically eat the x86 high-performance market. The fact that the chip uses so little power (15W) means they can absolutely cram them into servers where CPUs can easily consume 180W. That means 10x the number of chips for the same power, and not all concentrated in one spot. A lot of very interesting server designs are now possible.
I think you are half right in the sense that people now know Intel architectures are not what they want/need. Riscv5 chipsets will take a bit longer to mature but can in principle do the same kinds of things that Apple is doing with M1 to keep energy usage low and throughput high. However, the key selling feature with RiscV5 is reduced IP licensing needs (cost).
With Nvidia, buying Arm and producing their own chip sets, that's no small advantage for companies that are not Nvidia (or Apple who have a perpetual license already). If I were Intel, that's what I'd be looking at right now. Same for perhaps AMD. The clock is ticking on their x86 only strategy and it takes time to develop new architectures; even if you do license somebody else's instruction set.
A counter argument to this would be software compatibility. Most of the porting effort to make linux, windows, and mac os run on Arm has already happened years ago. It's a mature software ecosystem. Software is actually the hardest part of shipping new hardware architectures. Without that, hardware has no value.
And a counter argument to that is that Apple is showing instruction set emulation actually works reasonably well: it is able to run x86 software at reasonable performance on the M1. So, running natively matters less these days. If you look at Qemu, they have some interesting work going on around e.g. emulated GPU where the goal is not to emulate some existing GPU but to create a virtual only GPU device called Virgil 3D that can run efficiently on just about anything that supports opengl. Don't expect to set fps records of course. The argument here is that the software ecosystem is increasingly easy to adapt to new chip architectures as a lot of stuff does not require access to bare metal. Google uses this strategy with Android: native compilation happens (mostly) just in time after you ship your app to the app store.
It's hard to imagine that until a few months ago it was very difficult to get a decent Arm desktop / laptop. I imagine lots of developers working now to fix outstanding Arm bugs / issues.
While I'm sure lots of projects have actual ARM-related bugs, there was a whole class of "we didn't expect this platform/arch combination" compilation bugs that have seen fixes lately. It's not that the code has bugs on ARM, a lot of OSS has been compiling on ARM for a decade (or more) thanks to Raspberry Pis, Chromebooks, and Android but built scripts didn't understand "darwin/arm64". Back in December installing stuff on an M1 Mac via Homebrew was a pain but it's gotten significantly easier over the past few months.
But a million (est) new general purpose ARM computers hitting the population certainly affects the prioritizing of ARM issues in a bug tracker.
When Itanium was newborn, HP enlisted my employer, Progeny, to help port applications to ia64 Linux.
Despite the fact that 64-bit Linux had been running successfully on DEC Alpha systems for years, we ran into no end of difficulty because pointers were truncated all over the place, which apparently hadn't mattered on Alpha systems.
It seems like it must have been an Endian issue, but after 20 years my memories are basically toast. I just know nearly every bug we found was pointer truncation.
A lot of hobbyist ones, e.g. But even for mainstream compilers, arm has been a second-class citizen where developers would not necessarily test on arm. E.g. I used to work on V8, and we had partners at ARM who would help support the 32- and 64-bit ports. While I often did go ahead and port my changes to arm, it wasn't always required, as they could do heavy lifting and debugging for us, sometimes. We didn't have arm hardware on our desks to test; V8 literally has its own CPU simulators built into it, just for running the generated code from its own JITs. We had good regression testing infrastructure, but there is nothing quite like having first-class, on-desk hardware to test with, preferrably to develop directly on.
They are licensing ARM cores; which as of now cannot compete with Apple silicon.
While there are using some future ARM core, and I've read rumors that future designs might try to emulate what has made Apple cores successful; we cannot say whether Apple designs will stagnate or continue to improve at current rate.
There is potential for competition from Qualcomm after their Nuvia acquisition though.
Maybe not in single threaded performance, but Apple has no server grade parts. Ampere, for example, is shipping an 80 core ARM N1 processor that puts out some truely impressive multithreaded performance. An M1 Mac is an entirely different market - making a fast 4+4 core laptop processor doesn't neccesarily translate into making a fast 64+ core server processor.
To be honest it does though. You could take 10 M1 chips (40+40 cores, with around 30TFLOPS of GPU) put them into a server and even at full load you would be at 150W, which is about half of the high core count Xeons. Obviously not as simple as that, but the thermal fundamentals are right.
The 40 core Xeon also costs around 10k.
There's rumors that the new iMac will have a 20 core M1 (16+4). I imagine that will be faster than even the top line $10k Xeon.
I have absolutely no doubt apple could put together a server based on the M1 which would wipe the floor with Intel if they wanted to. But I very much doubt they will since it is so far out of their core competencies these days.
I have absolutely no doubt apple could produce a ridiculously good server CPU from the M1. I doubt they will actually do it though.
> You could take 10 M1 chips (40+40 cores, with around 30TFLOPS of GPU) put them into a server
Not really, part of why the ARM chips are so good is that the memory bandwidth is so fast. With 40+40 cores you're going to have at least NUMA to contend with, which always hampers multithreaded performance.
if they could easily do that(competitor for xeon) they would do it, it's a huge and very stable market, there is no reason to ignore it, if you have such a big advantage.
It seems weird to me to say that arm cores can't compete with apple silicon given that apple doesn't own fabs. They are using arm cores on TSMC silicon (exactly the same as this).
> They are using arm cores on TSMC silicon (exactly the same as this)
No the Apple Silicon chips use the arm _instruction set_ but they do not use their core design. Apple designs their core in house, much like Qualcomm does with snapdragon. Both of these companies have an architectural license which allows them to do this.
Yes they make workstations, but they don't make ARM workstations. Yet. They already have ARM chips they could use for it, but they went with x86 instead despite the fact that they have to purchase the x86 chips from their direct competitor. Also, yes, less than $100k starting price would be nice.
