Discussion

Never bet against x86

trvz: Seems like a silly thing to say right when x86 is getting pummelled to death by Apple and Valve, maybe slowly, but steadily, while the rest of the gang also watches on.

dana321: You mean never bet against AMD64

Analemma_: This feels like a take from 10 years ago, when Intel was struggling to deliver 10nm but a lot of people assumed it would all shake out in the end. I could see a defensible case for betting on x86 then, and most of the author’s bullet points seem tailored for that era.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.

creatonez: > ValveThis 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.

phendrenad2: [delayed]

samuelknight: What does Valve ship without x86?

p_ing: How? x86 leads on performance. It's reasonably low power now, too; perhaps not the best, but it's not aughts-era power consumption.

Pannoniae: The future of x86 is worrying but it's nowhere dead yet. I saw the C&C article yesterday and did some research, TL;DR:- 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.

adrian_b: ARM CPUs are quite good in "general-purpose" applications, like Internet browsing and other things that do not have great computational requirements, as they mostly copy, move, search or compare things, with only few more demanding computations.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.

beagle3: Worked very well for Apple in their transition to Apple Silicon.

hard_times: ...which is an extension of x86, the same way AArch64 is an extension of ARM.

mifydev: I'm quite concerned about x86 future, but the article has a point if you read it past the title.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.

davidkwast: RISC-V can be essential for this open future

cardanome: As far as I understand RISC-V has the same lack of standardization that ARM has, no?

mjg59: If anything, worse - there's much wider variety in the set of CPU extensions available.

expedition32: Yeah things like heat and energy use don't matter much for gamers. Most of that comes from the GPU anyway.

mjg59: There's a standard like ACPI for Arm devices - it's called ACPI, and it's a requirement for the non-Devicetree SystemReady spec (https://www.arm.com/architecture/system-architectures/system...). But it doesn't describe the huge range of weirdness that exists in the more embedded end of the Arm world, and it's functionally impossible for it to do so while Arm vendors see devices as an integrated whole rather than a general purpose device that can have commodity operating systems installed on them.

jmalicki: The Mac silicon is nice in that it has partial x86 emulation in that it can work in x86 memory store mode.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.

invl: The Steam Link was ARM-based.

cedws: Anecdotally at work (SME) we are pretty much all in on ARM. MacBooks with M-series, AWS Graviton instances, even our CI runners are now ARM to match local development.

Zeetah: I wonder if we'll still be running x86 code a hundred years after it came out (according to Wikipedia, it came out in 1978). We are already 48 years in.

cmrdporcupine: Really when people say x86 now tho they don't mean that. They really mean the variant introduced with the 386 which has a linear memory model, memory protection, etc. Or x86_64 which is philosophically akin to the 386 but really a new ISA.So it's really more like mid-80s or early 2000s, not late 70s.

dmitrygr: aarch64 is not an extension. It is a whole new architecture having NOTHING in common with ARMv7 and below. Nothing!

klelatti: The point about the difficulties with Arm may be fair comment but the positioning and outlook of this post is decidedly weird. It seems to pretend that competitive desktop Arm processors already exist and ignores the existence of Arm ACPI.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).

michaelbuckbee: I'd add AWS + Gravitron to that list as well.

PaulHoule: Lately I've made making some AWS Lambda functions to do some simple things in Python and chose to use the ARM-based instances because there wasn't any reason not to.

M95D: > my worry is that ARM devices will bring an end to such an open platform like modern PCs are.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.

adrian_b: RISC-V has a beautiful license, but it is one of the ugliest and least efficient computer ISAs ever designed.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.

gaigalas: That is actually addressed in the article. Several architectures "pummelled" x86 before. PowerPC, for example. They did not stood the test of time though.

beagle3: What they did not win was the popularity contest, mostly thanks to Windows - the Wintel market was just too massive to compete with.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.

gaigalas: servers

mattnewton: Not what the article is talking about, but I think betting against x86 in terms of the investment of companies (not individuals buying PC parts) has been a pretty good bet!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.

bee_rider: RISV-V is messy but for good reason, with real standards, although lots of them, which can be hard to keep track of.X86 is de-facto standardized by vendor fiat.ARM is in an unfortunate middle ground.

toast0: > can you even have something similar to IBM PC with ARM?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.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.

pjmlp: People should look into consumer market share numbers before commenting.

M95D: ^ that!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.

mifydev: You can just boot freedos to run them, it will execute in real mode which has the same cpu instructions as 40 years ago.

craftkiller: > can you even have something similar to IBM PC with ARMYes, 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.

M95D: Would you PLEASE stop promoting UEFI and ACPI?! These are closed-source blobs that the manufacturers will never update and have complete control over the system at ring -2. Why would you even consider it?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.

anthk: No, you are wrong. DOS COM files if 16 bit can't be run on 64 bit CPU's but 32 bit DOS binaries can be run under 32 bit GNU/Linux installs with DosEMU straight by just emulating the BIOS part, the rest is native.

M95D: You actually confirmed what I said. :)

2OEH8eoCRo0: And the article explains why they'll never "win."

fragmede: You can still boot Linux on PCs though. ARM devices, you're SOL in most cases. Device tree is a total shit show. For random ARM device, better hope randomInternetHero42 on a random forum has it for your device. Just asking the device itself what exists would be stupid question in ARM world.

M95D: If the device boots, you find the device tree in /sys/firmware/fdt, or in unpacked human-readable form in /sys/firmware/devicetree/* .

anthk: ARM device trees suck. ACPI for sure it's hell, but a DTB per device it's a damn disaster. U-Boot it's open, but it sucks at having to plug a damn USB-serial cable in 2026 in order to get a prompt. That should come builtin, and with an easy builting help or some text based menu.

M95D: It's either a DTB per device or a firmware blob per device. I'll take the open source device tree anytime!

M95D: UEFI switches the CPU into 32bit v86 mode or directly in 64bit mode and you can't go back to real mode without a CPU reset, which v86 won't allow (you don't have ring -2 privileges) and 64bit mode can't do at all. I don't have a UEFI system, so I might be wrong (I even hope I'm wrong - it would mean slightly more freedom still exists), but from what I read about it, I'm 90% certain it's not possible.

rep_lodsb: You're confusing several things here. The only x86 processor that didn't allow returning to real mode was the 16-bit 80286 - on all later ones it's as simple as clearing bit 0 of CR0 (and also disabling paging if that was enabled).Nothing more privileged than ring 0 is required for that."v86" is what allowed real mode to be virtualized under a 32-bit OS. This is no longer available in 64-bit mode, but the CPU still includes it (as well as newer virtualization features which could be used to do the same thing).

fragmede: What does that mean in a world where writing software just got a few orders of magnitude cheaper?

kode-targz: It didn't though. Not good software at least. AI (which is what I'm guessing you're referring to here) is simply incapable of writing such mission -critical low-level code, especially for a niche and/or brand new ISA. It simply can't. It has nothing to plagiarize from, contrary to the billions of lines of JavaScript and python it has access to. This kind of work can most definitely be AI-assisted, but my estimate is that the time gained would be minimal. An LLM is able to write some functional arduino code, maybe even some semi-functional bare-metal esp32 code, but nothing deeper than that.

wolrah: > 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.You've missed a huge segment:Random in-house apps or niche vertical market apps that are closely tethered with a business workflow to the point that replacing them is a massive undertaking, where the developers at best aren't interested in improving anything and at worst no longer exist.

beagle3: No I did not miss it. That has moved to web, either directly Or through an RDP/VNC interface where the actual windows virtual machine is hidden.Embedded/hardware is the last segment still not replaced by web.

cmrdporcupine: Even if you could/can it is an anachronism. Architecturally there's just a huge difference between 8086 and even 80286 and the 386. Before the 386 I wouldn't touch a machine with an Intel processor in it. Once the 386/486 penetrated the market and became cheap it was game over for everything else because it was good enough (linear address space, memory protection, larger address space, 32-bit etc etc), smart enough, gosh darn it it was cheap and everywhere.