It says that x86 is highly standardised - even with different combinations of chips, peripherals and motherboards you know it will work just fine. It's not the case for ARM systems - can you even have something similar to IBM PC with ARM?
I personally know that adding support for ARM devices on Linux is a huge and manual task - e.g. look at devicetree, it's a mess. There is no standard like ACPI for ARM devices, so even powering off the computer is a problem, everything is proprietary and custom.
I don't agree with the article though, x86 is dying and my worry is that ARM devices will bring an end to such an open platform like modern PCs are.
Yes, it's called SBBR which requires UEFI and ACPI. It is more common on server hardware than on consumer-grade embedded devices. The fact that it is not ubiquitous is really holding back ARM.
Device tree does the same thing and it's open source. Even if you only extract it in binary form a proprietary kernel or uboot, you can decompile it very easily.
AFAIK, ARM does not have port mapped i/o, so that makes it difficult to really match up with the PC. That said, an OS can require system firmware to provide certain things and you get closer to an IBM like world. Microsoft requires UEFI for desktop Windows (maybe WP8 and WM10 as well, but I believe those were effectively limited to specific qualcomm socs, whereas I feel like Desktop windows is supposed to be theoretically open to anything that hits the requirements).
ACPI for ARM is a thing that exists, but not all ARM systems will have it. Technically, not all x86 systems have it either, but for the past several generations of Intel and AMD, all the hardware you need for ACPI is embedded in the CPU, so only old hardware or really weird firmware would be missing it. Also, PC i/o is so consistent, either by specification or by consensus, that it's easy to detect hardware anyway: PCI is at a specific i/o port by specificiation; cpu ID/MSR lets you locate on-chip memory mapped perhipherals that's aren't attached via PCI, and PCI has specificied ways to detect attached hardware. There's some legacy interfaces that aren't on PCI that you might want, and you need ACPI to find them properly, but you can also just poke them at their well known address and see if they respond. AFAIK, you don't get that on other systems... many perhipherals will be memory mapped directly, rather than attached via PCI; the PCI controller/root is not at a well known address, etc, every system is a little different because there's no obvious system to emulate.
Mostly ACPI is about having hardware description tables in a convenient place for the OS to find it. Certainly standardized understanding of power states and the os-independent description of how to enter them is important too.
There are/were other proposals, but if you want something like UEFI and ACPI, and you have clout, you can just require it for systems you support. The market problem is Apple doesn't let their OS run on anything non-Apple, and Android has minimal standards in this area; whereas the marketplace for software for the IBM PC relied heavily on the IBM BIOS, the marketplace of software for Android relies on features of the OS; SoC makers can build a custom kernel with the hardware description hardcoded and there's no need to provide an in firmware system of hardware description. Other OSes lose out because they too need custom builds for each SoC.
Modern PCs are NOT open platform anymore. Not since signed bootloaders, UEFI, secure boot. ARM on the other hand, as long as they don't require signed bootloaders (like phones) or a closed source driver for GPU or something, are in fact open.
Any competent computer engineer can design a much better ISA than RISC-V.
The problem is that designing a CPU ISA is easy and it can be done in a few weeks at most. On the other hand, writing all the software tools that you need to be able to use an ISA, e.g. assemblers, linkers, debuggers, profilers, compilers for various programming languages etc. requires a huge amount of work, of many man-years.
The reason why everybody who uses neither x86 nor Arm tends to use RISC-V is in order to reuse the existing software toolchains, and not because the RISC-V ISA would be any good. The advantage of being able to use already existing software toolchains is so great that it ensures the use of RISC-V regardless how bad it is in comparison with something like Aarch64.
The Intel ISA, especially its earlier versions, has also been one of the ugliest ISAs, even if it seems polished when compared to RISC-V. It would be sad if after so many decades during which the Intel/AMD ISA has displaced other better ISAs, it would eventually be replaced by something even worse.
As one of the main examples of why RISC-V sucks, I think that any ISA designer who believes that omitting from the ISA the means for detecting integer overflow is a good idea deserves the death penalty, unless the ISA is clearly declared as being a toy ISA, unsuitable for practical applications.
It’s a crapshoot. That’s why whenever anyone recommends a certain cool Arm motherboard or mini PC, the first thing you have to figure out is what its software support situation is like. Does the OEM provide blessed Linux images? If so, do they offer more than an outdated Ubuntu build? Have they made any update promises?
I really hate to like x86 but I know that when I set up an embedded x86 device it's flash, apt-get update/upgrade, and I've got the latest stuff running and supported.
ARM is a complete jungle by comparison. Each ARM manufacturer licenses a different UART, different USB, different PCIe (or none at all), different SATA, different GPU, different audio even if it's just I2s, different I2c, different SPI, different GPIO controller, different MMC/SDHCI, etc. etc. And each one needs, of course, a different driver!
The big mistake ARM (the company) made was to design only CPUs, not complete SoCs with peripherals, or at least require standard I/O addresses. And now they're trying to patch it up with UEFI and ACPI: closed-source ring -2 blobs that will never be updated or bug-fixed by any manufacturer.
This is a funny thing to say when Valve hasn't actually released any ARM device yet, and the Steam Deck is still fully reliant on x86. The ARM hardware they do plan to release relies on x86 emulation, which is something that historically usually doesn't pan out.
Since they had control over the hardware, they could punt on one of the hard parts of Rosetta and bake it into Silicon.
Understanding the memory ordering requirements from binary without source and without killing performance by being overly conservative (and hell, the source itself probably has memory ordering bugs if it was only tested on x86) sounds next to impossible.
They also use emulation backing this project: https://github.com/FEX-Emu/FEX
But that’s changed somewhat - Apple has managed a larger mind and market share (while switching into ARM). The vast majority of uses are now available on the web, which is CPU agnostic, and there is a huge amount of open source software available.
The only things for which x86 still shines a little brighter are games, and native office. But office is mostly available on web, on Mac, and on Winarm. So games. Which aren’t big enough market mass to sustain the x86’s popularity — and is a segment (soon) under attack by Valve.
But now? I can’t think of a single segment where x86 is doing well. Its out of mobile entirely, it’s slowly getting squeezed out of servers as e.g. Graviton takes over, it has no presence in the AI gold rush, and in consumer desktops/laptops it’s position is precarious at best.
I’m quite bearish on x86.
And in terms of squeezing out of servers, this is happening way more slowly than you're implying.
I say this as a person running an NVIDIA Spark as my daily driver. We're not there yet.
The reason ARM is making inroads in the server market is we've reached the point where cooling is a significant cost factor in server farms, so lowering TDP is starting to become a relevant factor in total cost.
x86 will lose to ARM/RISC in gaming only if those chips provide a better gaming experience.
On the conclusion - x86 didn't eventually win in smartphones.
And of course having a choice of processor designs from precisely two firms is absolutely something that we should continue to be happy with (and the post ignores RISC-V).
Being long AAPL and NVDA has crushed AMD and INTC, and that's with AMD's gains which I would argue are mostly due to non-x86 chips. Even Broadcom + Qualcom + ARM has been a better basket to hold for most of the last 5 years.
While PCs still need x86 because of the standardization the article talks about, more appliance-like computers like mobile phones and even server hardware have stolen a lot of market share and I think are the dominant way people will do their computing in the future. This comment was written on a m2 macbook that I use to ssh into a gb200 server.
- Apple took over the single-threaded crown a while ago.
- ARM also caught up in integer workloads.
- ARM Cortex is still behind in floating-point.
- Both are behind in multithreaded performance. (mostly because there are more high-end x86 systems...)
- Both are way behind in SIMD/HPC workloads. (ARM is generally stuck on 128-wide, x86 is 256-wide on Intel and 512-wide on AMD. Intel will return to 512-wide on the consumer segment too)
- ARM generally have way bigger L1 caches, mostly due to the larger pagesize, which is a significant architectural advantage.
- ARM is reaching these feats with ~4.5Ghz clocks compared to the ~5.5Ghz clocks on x86. (very rough approximation)
Overall, troubling for x86 for the future... it's an open question whether it will go the way of IBM POWER, legacy support with strict compatibility but no new workloads at all, or if it will keep adapting and evolving for the future.
So by that measure the future of x86 seems to be less troubling today than it was 5 years ago.
On the other hand, most ARM-based CPUs, even those of Apple, have quite poor performance for things like arithmetic operations with floating-point numbers or with big integer numbers. Geekbench results do not reflect at all the performance of such applications.
This is a serious problem for those who need computers for solving problems of scientific/technical/engineering computing.
During the half of century when IBM PC compatible computers have been dominant, even if the majority of the users never exploited the real computational power of their CPUs, buying a standard computer would automatically provide at a low price a good CPU for the "power" users that need such CPUs.
Now, with the consumer-oriented ARM-based CPUs that have been primarily designed for smartphones and laptops, and not for workstations and servers, such computers remain good for the majority of the users, but they are no longer good enough for those with more demanding applications.
I hope that Intel/AMD based computers will remain available for a long time, to be able to still buy computers with good performance per dollar, when taking into account their throughput for floating-point and big integer computations.
Otherwise, if only the kinds of computers made by Apple and Qualcomm would be available, users like me would have to buy workstations and servers with a many times lower performance per dollar than achievable with the desktop CPUs of today.
This kind of evolution already happened in GPUs, where a decade ago one could buy a cheap GPU like those bought by gamers, but which nevertheless also had excellent performance for scientific FP64 computing. Then such GPUs have disappeared and the gaming GPUs of today can no longer be used for such purposes, for which one would have to buy a "datacenter" GPU, but those cost an arm and a leg.
I see x86 on top (the first valid result is 6841, which is x86), if that is the sole benchmark we're going to look at. You can further break that down into the individual tasks it performs, but I'm not going to :-)
> - ARM generally have way bigger L1 caches, mostly due to the larger pagesize, which is a significant architectural advantage.
Larger pages mean more potential for waste.
Not to bash on x86 or anything, but that's an outlier. Very overclocked with a compressor chiller or similar. Also the single-threaded and multi-threaded scores are the same; it's probably not stable at full load across all cores.
I don't think that's really representative of the architecture at scale, unless you're making the case for how overclockable (at great power/heat cost) x86 is.
I have a virtual instance of Win11 ARM running in UTM on my MBP. It's honestly been surprisingly rare that I have to figure out how to run something that requires x86. More and more Linux distros have an ARM version that I can run if I need to.
So it's really more like mid-80s or early 2000s, not late 70s.
You can't run a COM program today. Not without emulation. Recent PCs can't even run DOS EXE because they're missing the BIOS interrupts most DOS programs use.
That variable-length encoding and strongly ordered memory model will do x86 in sooner and not later.