8 ms·
Never Bet Against x86
- trvz 7mo agoSeems 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.
- deleted 7mo ago[deleted]
- skydhash 7mo agoI believe it’s more from the point of view of Kernel, Compiler, and Driver developers, not from manufacturers and users. Standards, while not very flexible, are good for building ecosystems.
- michaelbuckbee 7mo agoI'd add AWS + Gravitron to that list as well.
- PaulHoule 7mo agoLately 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.
- TYPE_FASTER 7mo agoYeah, we migrated a bunch of compute to Graviton a few years ago at a previous employer and the result was better performance at a lower price point.
- samuelknight 7mo agoWhat does Valve ship without x86?
- jsheard 7mo agoNothing yet, but the upcoming Steam Frame VR headset is ARM based. The relevant detail is they're bankrolling the open source FEX x86 emulator, with the goal of bringing the whole Steam back-catalogue to ARM systems.
- TomatoCo 7mo agoNow that Google and Apple have to (more-or-less) allow other app stores, I wonder if Valve is bankrolling FEX with the intent of selling games on mobile?
- invl 7mo agoThe Steam Link was ARM-based.
- creatonez 7mo ago> Valve 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.
- beagle3 7mo agoWorked very well for Apple in their transition to Apple Silicon.
- i_am_a_peasant 7mo agofor real, rosetta is crazy good
- jmalicki 7mo agoThe 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.
- jsheard 7mo ago> 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. It is hard, but Microsoft came up with a hack to make it easier. MSVC (since 2019) annotates x86 binaries with metadata describing the codes actual memory ordering requirements, to inform emulators of when they need to be conservative or can safely YOLO ordering. Obviously that was intended to assist Microsoft's Prism emulator, but the open source FEX emulator figured out the encoding (which I believe is undocumented) and implemented the same trick on their end. Emulators still have to do it the hard way when running older MSVC binaries of course, or ones compiled with Clang or GCC. Most commercial games are built with MSVC at least.
- gaigalas 7mo agoThat is actually addressed in the article. Several architectures "pummelled" x86 before. PowerPC, for example. They did not stood the test of time though.
- beagle3 7mo agoWhat 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 7mo agoservers
- wolrah 7mo ago> 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 7mo agoNo 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.
- p_ing 7mo agoHow? x86 leads on performance. It's reasonably low power now, too; perhaps not the best, but it's not aughts-era power consumption.
- cedws 7mo agoAnecdotally 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.
- pjmlp 7mo agoPeople should look into consumer market share numbers before commenting.
- 2OEH8eoCRo0 7mo agoAnd the article explains why they'll never "win."
- Pannoniae 7mo agoThe 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.
- p_ing 7mo agohttps://browser.geekbench.com/v6/cpu/15805010 https://browser.geekbench.com/v6/cpu/15805010 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.
- future10se 7mo ago> https://browser.geekbench.com/v6/cpu/15805010 https://browser.geekbench.com/v6/cpu/15805010 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.
- adrian_b 7mo agoARM 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. 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.
- phendrenad2 7mo agoI don't think my gaming PC will ever use an ARM core. When you want true "big iron" you want x86. Intel and AMD have a duopoly on high-performance, no-TDP-spared chips, and they aren't sharing that market with anyone. 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.
- beagle3 7mo agoHardcore gamers are not a big enough market segment to sustain x86. If everyone else switches to ARM/RISC-V, games will too, eventually.
- Strom 7mo agoHardcore gamers were the reason behind a whole new chip type being introduced - the GPU. This was also when this market was a lot smaller. I don’t see this changing. The market will continue rewarding chips that cater to it. It is absolutely big enough to sustain several different completely bespoke chip types, regardless of what non-gamers are doing. x86 will lose to ARM/RISC in gaming only if those chips provide a better gaming experience.
- expedition32 7mo agoYeah things like heat and energy use don't matter much for gamers. Most of that comes from the GPU anyway.
- pseudohadamard 7mo agoAlso when the CPU is just an I/O peripheral for the NPU/TPU it doesn't matter so much what the architecture is.
- Analemma_ 7mo agoThis 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.
- PaulHoule 7mo agoe.g. the reason why x86 clobbered everyone else in the 1985-2005 period was that nobody else shipped enough units to keep ahead in terms of technology development. The slogan should be "Never bet against the CPU architecture that ships the most units" and today that translates to "Never bet against ARM"
- cmrdporcupine 7mo agoAs others have pointed out, gaming would be the place. 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.
- dana321 7mo agoYou mean never bet against AMD64
- hard_times 7mo ago...which is an extension of x86, the same way AArch64 is an extension of ARM.
- dmitrygr 7mo agoaarch64 is not an extension. It is a whole new architecture having NOTHING in common with ARMv7 and below. Nothing!
- Koshkin 7mo agoNever say never...
- hard_times 7mo agoNot mentioned in the article, but the latest generation Xbox and PlayStation run completely custom firmware with their own proprietary boot chains, and locked-down hardware. So much for the "uniform" x86-64 "ecosystem". I'm sure there are more examples.
- mifydev 7mo agoI'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 7mo agoRISC-V can be essential for this open future
- cardanome 7mo agoAs far as I understand RISC-V has the same lack of standardization that ARM has, no?
- mjg59 7mo agoIf anything, worse - there's much wider variety in the set of CPU extensions available.
- bee_rider 7mo agoRISV-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.
- adrian_b 7mo agoRISC-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. 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.
- dmitrygr 7mo agoGraviton, Apple M-series... That variable-length encoding and strongly ordered memory model will do x86 in sooner and not later.
- Zeetah 7mo agoI 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 7mo agoReally 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.
- M95D 7mo ago^ 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.
- anthk 7mo agoNo, 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 7mo agoYou actually confirmed what I said. :)
- anthk 7mo ago50/50, because once you boot a 32 bit os you can run 16 bit binaries :) I'm pretty sure that if I make a dual-kernel 9front (9pc and 9pc64 available at boot) in a 64 bit machine and I compile emu2 for it, DOS COM binaries might be trapped enough to run simple text mode tools under the 386 port.
- 7mo ago
- klelatti 7mo agoThe 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).
- M95D 7mo agox86 always had standards: same two IRQ controllers, same UART chips, same keyboard controller, same PC speaker I/O, same ISA, same PCI, same AGP, VGA ROM that init the GPU with the same framebuffer address, all PATA controllers used the same I/O and IRQ and a single driver worked for all, same de-facto standards for audio (OPL aka. Adlib / SoundBlaster / MIDI), simple/bidi/ECP/EPP standards for parallel port and de-facto ESC/P standard for printers, etc. Hell, even USB there were only 2 at the beginning: Intel (UHCI) and AMD (OHCI), and then they cooperated and made universal EHCI. 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.
- anthk 7mo agoARM 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 7mo agoIt's either a DTB per device or a firmware blob per device. I'll take the open source device tree anytime!
- mjg59 7mo agoA DTB is a blob. Whether you have the source is a vendor decision, just like ACPI. There's no inherent difference here.
- M95D 7mo agoYou can convert a DTB blob back into source code: dtc -I dtb -O dts -o devicetree.dts blob.dtb Big, biiig, biiiiig difference! PS: You can also examine it directly as a directory tree in /sys/firmware/devicetree/*
- mjg59 7mo agoYou can convert ACPI bytecode back to source with iasl. No difference at all.
- mattnewton 7mo agoNot 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.
- Smart_Medved 7mo ago[dead]
- TYPE_FASTER 7mo ago> When I buy an x86 computer, either in parts or from an OEM, either Intel or AMD, I don’t have to worry for one second if Windows, Linux, one of the BSDs, or goddamn FreeDOS, and all of their applications, are going to run on it. 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.