Hell Freezes Over as AMD and Intel Come Together for x86
servethehome.com
servethehome.com
ARM took embedded first, then mobile, then gaming (on mobile and handhelds), then Macs, and now it is making real inroads into Windows laptops (e.g. Snapdragon X Elite) and servers (e.g. Graviton.)
The next shoe to drop would be a high-end gaming PC that can take an NVIDIA or AMD graphics card powered by a Snapdragon X Elite-like ARM chip.
Another shoe to drop would be a super-computer powered by ARM chips instead of x86. I don't think that has happened yet?
After that, the last refuge of x86 is in legacy software that hasn't been natively ported to ARM. But there will be fewer and fewer cases of this as the years go by. For now I think it will be mostly games.
x86 is under serious threat.
It's not like ARM has taken over those markets yet. Snapdragon X is fine but nothing special compared AMD/Intel chips. I think we just might have a pretty distorted view of ARM vs x86 because of Apple. They are just much better at designing ARM chips than anyone else (including both Qualcomm and especially ARM itself). Servers is kind of a mixed story as well.
There is nothing wrong with other companies trying to disrupt AMD/Intel duopoly and hopefully we'll get lower prices and more innovation because of that but calling x86 dead is a bit premature at this point..
The issue is that ARM is now fine for Windows. Until Snapdragon, ARM was actually pretty crap outside of Apple. This is a huge step. Qualcomm acquired a lot of the original Apple team for the M1 via Nuvia and I expect them to be able to execute at least decently going forward.
Apparently they are selling because they have better battery life than Intel/AMD laptops according to this: https://www.techpowerup.com/324301/battery-life-is-driving-s...
> Servers is kind of a mixed story as well.
Graviton is 30% cheap for the performance (e.g. performance adjusted price.) It is a no brainer for a lot of workflows, especially given so many developers are actually building on ARM machines in the first place. I want my servers to be 30% cheaper.
> There is nothing wrong with other companies trying to disrupt AMD/Intel duopoly and hopefully we'll get lower prices and more innovation because of that but calling x86 dead is a bit premature at this point..
Qualcomm is exploring acquiring Intel. A company who got its value from ARM is looking to take over the historic leader in x86 - doesn't that tell you something? https://www.reuters.com/markets/deals/qualcomm-approached-in...
The writing is on the wall. x86 isn't dead and it won't be dead anytime soon, but it definitely in its twilight period.
Why would they, though?
Neither Apple nor Qualcomm have any incentives to share their designs with ARM anymore than they do with Intel, AMD or each other. I wonder how AmpereOne will look assuming it actually ever comes out...
The Nuvia designs Qualcomm bought were made under an ARM architectural license that specifically restricts all designs sold to only go in servers - not phones, laptops, or anything else. They also weren't allowed to sell the company without destroying the designs first, because Nuvia got a really sweet deal on the architectural license. Qualcomm thinks that doesn't matter, because they have a (much broader) ARM architectural license already - you can't force someone to buy the same license twice, under the principle of rights exhaustion.
ARM furthermore has an incentive to keep architectural licensees from competing with ARM's in-house design licensing business. Apple Silicon isn't a threat to that business because Apple will never sell their own components to third-parties. In fact, that's why they hate right-to-repair so much[0]. They're better off licensing ARM patents and having Apple continue to work on LLVM than trying to squeeze them for more money. Qualcomm on the other hand sells phone chips to other companies, and currently spends a lot of money to package ARM's licensed designs into their own SoCs. Nuvia designs going into those phones would be a significant movement of money from ARM's pocket to Qualcomm's.
[0] To be specific, in a right-to-repair world where individual components have to be sold at the same pricing arrangements available to the OEM, Apple would not be able to have exclusive parts in their phones that other vendors can't have. Apple can't say this, because it's hilariously self-serving and the general public correctly doesn't give a flying fuck about IP law, but you can infer it from conduct.
Apple is perfectly willing to sell you assemblies, of course. Because no vendor is going to buy 100 unrelated parts to get the 1 they care about.
Techniques leak out as people move around, etc.
For example, AMD had a lead on chiplet designs but now Intel has them in the latest generation. I would expect that ARM will have chiplets designs by the end of the decade as well.
Look at Anthropic that seems to have an LLM that is on par with OpenAI GPT 4.
Sure, I mean I agree that ARM can outcompete x86 there but mainly Amazon can just cut out Intel/AMD and make their chips themselves which can significantly reduce costs. Not because Neoverse is somehow inherently better or faster than its x86 equivalents. Of course from the perspective of most users that's effectively the same thing, why overpay for 1 fast core when you can just get 2 slightly slower ones.
> Qualcomm is exploring acquiring Intel.
That's far fetched and hard to believe. IIRC there were talks about Qualcomm maybe buying some secondary subsidiaries/departments form Intel and somehow it got extrapolated to Qualcomm acquiring Intel (unless there is any credible information to back that up?)
Also reported in WSJ: https://www.wsj.com/business/deals/qualcomm-approached-intel...
That is Reuters and WSJ reporting it, not an X post by a anonymous rando. It mentions at least two sources.
This is not a rumour, it was at least somewhat real. Doesn't mean it will happen, it seems to be very preliminary and exploratory.
Some other deal, where Qualcomm buys some pieces of Intel, might be possible.
How can you tell? I'm not denying that and obviously can't claim to know but I just don't see any public information that would allow us to make this conclusion.
WSJ, Reuters and everyone else regularly report rumours that sound credible.
Although if we're only talking about "exploring" rather than anything more that's probably true, there is no reason for Qualcomm to at least try and do the math of at what price point it might start making sense and they should be obviously be doing that.
I just don't really see how is that particularly newsworthy since it's just extremely improbably (due to factors both Intel and Qualcomm can't directly control).
Huh? You live in a different reality than I do. These are reputable sources and I need to move onto something more productive.
Yes? And? Did I imply that there is something wrong with that or that they shouldn't be reporting it? I assume our definitions of what is a "credible rumour" differ...
> You live in a different reality than I do.
If you can seriously believe that Qualcomm could actually acquire Intel (unless Intel's management is engaging in some extreme amount of fraud to hide the fact that the company is on the brink of imminent bankruptcy) then yes, that must be the case...
Nvidia wasn't even allowed to buy ARM even though they weren't competitors and had almost no real overlap. This would be considerably harder to pull off.
Also you have that whole AMD64/x86 patent thing. Not sure about the details (and maybe the original agreement has expired and that part wasn't renewed) but according the original deal the cross licensing agreement would automatically expire if either party was acquired.
I think the first reason is more than enough but if it's not and they still have something similar about newer x86 related features developed after 2009 Qualcomm would only be buying Intel for the fabs and other assets or would have to pay off AMD if they want x86.
Huh, I didn't even realize they are sufficiently big for this to be potentially possible.
and those chips become relatively unimpressive once everyone gets access to the same TSMC nodes a year and some down the road with AMD's x86 beating Apple's wonder ARM once again…
Astra at Sandia Labs was the first Arm peta-scale supercomputer, and the first on the Top500. It debuted in 2018.
Fugaku is the fastest Arm supercomputer, taking the #1 spot on the Top500 in 2020. It is currently #4.
All NVIDIA Grace-Hopper systems will be Arm. There is one in the top 10 already, Alps at the Swiss CSCS, at #6. There are four more in the top 100.
Apparently I am super wrong here. ARM has made serious inroads here as well.
I think that ARM's willingness to allow their IP to be customized for their clients needs has really given them a lot of competitive advantages.
Right now RISC-V is ultra slow in all implementations I've seen. Like 30x slower than a top of the line Apple Mx series CPU. Maybe there is a high performing RISC-V chip out there but I haven't yet run into one.
RISC-V benchmarks: https://browser.geekbench.com/search?q=RISC-V. Compare to an Apple M4 benchmark: https://browser.geekbench.com/v6/cpu/8224953
That said, RISC-V is good for embedded applications where raw performance isn't a factor. I think no other markets are yet accessible to RISC-V chips until their performance massively improves.
Sometimes useful to see how cpu architectures grow and then get crowded out by the next processor family -- at least among supercomputers.
ARM devices are embedded in the SoC. That's basically the definition of a SoC. Intel & co. at that time didn't produce SoCs. A CPU was just a CPU. It didn't have UARTs, GPU, SDHCI, I2c, SPI and other stuff in it.
The only thing x86 (basically Intel, not Microsoft) did good was to standardize I/O addresses like framebuffer, IDE ports, serial I/O and later to make the rest discoverable via ACPI standard (which is a bad standard, btw, and UEFI is far worse).
You may view ACPI as the x86 devicetree. The only difference is that x86 comes with ACPI written in a chip, while ARM firmware is a separate file you add into your bootable image next to the kernel, without the need for a separate EEPROM chip.
You shouldn't be complaining about the ARM device descovery (devicetree), but about the absolute jungle of devices that ARM includes. Just think how many different USB controllers are out there. Each manufacturer designed it's own controller and every ARM chip needs a different driver. On x86 there are/were only 2: Intel (UHCI) and AMD (OHCI), and then they cooperated and made universal EHCI and xHCI.
This was in a different era where most PCs weren't networked.
x86_64 has moved to UEFI and SecureBoot since, but is still mostly expected to boot any live distro you'd like. Replacing x86 could drastically reduce the chances of replacing non-free vendor software with free software.
The presence or lack thereof of standardized interfaces for firmware, device configuration, or the underlying platform are orthogonal to issues regarding Secure Boot and trust management. Apple Silicon Macs use nonstandard boot firmware (iBoot) but booting a "fully untrusted OS" (or fuOS) is an explicitly supported[2] use case on them, gated only by the user needing to boot recoveryOS (OTR specifically) once and enter their password to sign the alternative kernel. They even support per-volume boot policies, so you can keep your macOS install fully locked down while your Asahi Linux does whatever you want.
And likewise Intel isn't stopping you from building in whatever user-hostile nonsense you want into x86 firmware. There's actually a whole range of laptops that have BIOS rootkits preinstalled, specifically to force-install Computrace onto whatever Windows install gets booted for corporate IT management purposes. The thing is, corporate IT has a terrible habit of leaving this shit on laptops they've sold", either because the laptop was stolen internally or because IT couldn't give a shit to do the computer equivalent of signing the title, so people wind up buying laptops that will lock up and wipe themselves if you ever install Windows on them.
[0] The most successful of these being the PC-98, which lasted all the way up until the Windows 9x era
[1] ARM SoC vendors additionally commit the crime of not being compatible with themselves. It is common for new SoCs to have completely different memory and device layouts. Apple is the only exception, ironically because they make both the OS and the SoC, which is the one time where such crimes would be excusable.
[2] I'm told Apple's original intent was Boot Camp with Windows on ARM, but Microsoft wouldn't license Windows on ARM on Macs because they have an exclusivity deal with Qualcomm.
This is a feature rather than a bug ;-)
They could just refuse to install Windows. It'd be more polite.
Fugaku?
I guess a secondary factor is that it was made of custom/low volume CPUs, which would increase the unit price as compared to the higher volume providers.
I've thought about this quite a bit since I responded to a commenter who was somewhat was amazed at an ARM supercomputer quite a while ago about this subject. I decided to comment about this a lot more since it is my option to do so. cheers They had posited that ARM would take over, mostly recognizing the very low-power and fairly inexpensive ARM SoC in phone handsets and routers.
This thought didn't sit quite right with me. I considered the power requirements and architectural needs of a larger computer system. With many, many PCIe lanes or some other interconnect, rapid storage commitments and the very responsive performance required by a "serious" architecture will cause all of these subsystems to continually draw current and dissipate heat. This is in stark contrast to power efficient computing devices like iPhone or ARM macbooks, and in my mind seems likely to eat the "gains" that people generally associate with these devices.
The piece missing in my understanding is about the semiconductor industry and the electronics field in general, and is particularly interesting to me, because many of the highest-tier operators outsource %100~ of their production to TSMC or the other. There isn't anything magic or even very good about x86 architecture. I'm fairly certain the instruction set no longer maps to hardware in most cases, rather more analogous to function calls in typical software applications.
Every now and then I like to reflect that iPhone came out in 2007. My car is older than that, and we were well on our way during the election of Barack Obama. And while legends hold that Power still exists, I had long forgotten about ALPHA or SPARC by then.
Imagine for yourself this earth-shattering shift: What happens when the basic lithography processes, assembly practices, and validation procedures become such that for similar trade offs, any advanced hobbyist could order a wafer from future fab houses similar to JLPCB, Scaleway, OSH Park, TSMCWAY, or whatever on-demand? Like, what if you could just pay $$$$ to buy a wafer that you designed and then sell 14nm UltraSPARC on tindie?
Yes, I believe this is called micro operations and have been around for a while now:
https://en.wikipedia.org/wiki/Intel_microcode#P6_and_later_m...
- The first game console with an ARM CPU was the 3D0 (1991 - not sure if it was an ARM1 or later version).
- The first game console with an Intel CPU was the Magnavox Odyssey 2 with an Intel 8048 (it also had an Intel graphics chip) (1978).
- The first game console with an x86 Intel CPU I believe was the FM Towns Marty (I think this is 1992 or 1993 - it had a 386).
- The first successful game console with an x86 Intel CPU was the original Xbox (2001 or 2002) - and actually it was an AMD CPU (edit: nope it was an Intel).
There were mobile phones with Intel CPUs in them for a short time - I think it was 2010-2011. I always wanted to see one (was like super curious how the boot firmware looked if it was user accessible). I wonder what happened.
I think it was actually a Pentium III with less cache, i.e. basically a Celeron. Only third-gen Microsoft consoles onward use AMD parts.
Correct according to Wikipedia: https://en.wikipedia.org/wiki/List_of_Intel_Pentium_III_proc...
ARM is clearly here to stay and took some of the 68k, PPC, MIPS, and low end/embedded x86 use cases.
Since the industry loves the idea of displaced incumbents we’ll see a lot of RISC-V articles for years to come.
All of these came before Linux dominated the server space. Back then, being able to run Windows was needed to escape the narrow Unix niche.
Plus, 20 years ago people said x86 could never hit power and performance targets that today are the norm. Everyone talks about x86 like the actual hardware is the same year after year. It's not. The underlying CPUs are amazing and both Intel and AMD have done amazing work keeping the ISA competitive. I don't see that changing any time soon.
When did it switch to ARM from x86.
I don't really see any reasons why can't x86 and ARM just coexist long-term. Porting software is relatively easy or not even necessary these days and ARM main advantage (that companies other than Intel/AMD can use it) is entirely non-technical (development + licensing costs) so as long as Intel/AMD can keep up they have no incentives at all to switch.
Amazon's and Ampere's ARM server chips are significantly slower and less power efficient than the equivalent AMD chips (for Ampere at least, note sure if Amazon is sharing their power usage data but I doubt it's massively lower..) they are also 30-40% cheaper because you don't have to pay for AMD/Intel's oligopoly margins.
Of course other hyperscalers can and presumably are doing the same. However everyone else will be left out unless Ampere (or somebody else?) steps up.
https://www.phoronix.com/review/ampereone-a192-32x/12#:~:tex....
Of course the Ampere chip is significantly cheaper which I think is the main and most visible advantage ARM has for servers at least.
x86 still powers most of how we actually get stuff done.
x86 is getting cornered by ARM in consumer and data center. RISC-V is gunning for ARM.
While ARM is open-ish, RISC-V is more open than both. When you're not the market leader, that's the strategy to become market leader.
And it certainly helps that a major world power is putting in enormous energy to make their architecture the dominant alternative to "Western" architectures.
Intel i9: https://browser.geekbench.com/processors/intel-core-i9-13900...
https://www.cpubenchmark.net/high_end_cpus.html
Search for "M4", it's not anywhere near the top of the list.
I was referring primarily to single-threaded performance. And remember that the only scores you see for M4 CPUs in the CPUBenchmark website from iPads which are definitely thermal constrained.
The MacBook benchmarks are not yet available on this benchmark - they will exceed the performance then of the M3 scores I suspect:
That wasn't the direction I was thinking of going in, but if you want to go in multi-threaded benchmarks, you need to include the Ampere and Graviton CPUs. Those are designed for hyperscalers and then you can make a fair comparison. They are not listed on your cpubenchmark website.
For example this multithreaded score from Graviton 4, https://browser.geekbench.com/v6/cpu/7980680, is better than all of the consumer Intel and AMD CPUs listed on Geekbench in their chart here: https://browser.geekbench.com/processor-benchmarks.
And better than AMD's latest hyperscaler CPU's multicore benchmark: https://browser.geekbench.com/processors/amd-epyc-9654
It is too bad that these Graviton CPUs are not listed on cpubenchmarks. It is true that CPUBenchmarks and Geekbench test CPUs differently so it would be nice to see both benchmark results.
I was not talking about i9s, I specifically stated I'm talking about "the highest-end x86 chips", like Threadripper. Nothing Apple has can compete on that scale, M3 and M4 are not even close to the top.
data center CPU with 192 threads.
(But neither is whatever you have under your desk.)
Apple has already caught Intel in single core. If power didn’t matter to Apple they could surely optimize for pure performance, but they’re not competitive in the spaces where power does not matter and we will never see them being that chip to market.
There are always trade offs at the exotic tier and someone will always win one benchmark over the other, but you can’t say that ARM is being laughed at by Intel. If they were laughing they wouldn’t be partnering with AMD. While I don’t think Intel is super worried about Apple since it’s an Apples to Windows/Linux comparison, I do think they’re worried about Qualcomm and AWS catching Apple and actually eating into their market share.
Apple has nothing that comes close to the top-tier x86 CPUs. It just doesn't. Not in the ipad, not in any of their hardware.
https://www.cpubenchmark.net/high_end_cpus.html
Go ahead and search for an ARM CPU... they are nowhere near close to the top.
>Apple has already caught Intel in single core.
I don't care. If your workload runs fine a single core, then good for you.
The fact is that Apple doesn't have a chip that can compete with the top x86 CPUs overall performance, simply because Apple doesn't care about that market at all. All they care about is selling the cheapest made computer to people who won't notice that their computer isn't all that fast - the average consumer. They don't care about power users. You'll never, ever see Apple silicon beating the top chips from AMD or Intel in total processing power. Nothing wrong with that, but my point still stands, ARM is nowhere near x86 in terms of processing power.
> you can’t say that ARM is being laughed at by Intel.
Yes I absolutely can, and I specifically said that about available software. ARM has nowhere near the available software that x86 does. x86 absolutely laughs at ARM where available software is the concern.
But that's Apple, not ARM. AFAIK Neoverse/Gravitron's main advantage is price (not having to pay Intel/AMD "inflated" duopoly prices) rather than actual performance.
ARM is not going anywhere for a while. It dominates the mobile and embedded markets and is making in-roads in others. If it eventually gets displanted, it will be by RIsC-V or its successor.
X86 is vulnerable, more vulnerable than the other two. Taking it down is going to take a lot though. I would not bet against it. The biggest problem is that it is master of an ever shrinking empire. Even if they never lose it, they may matter less over time.
What you probably want is less variability in SoC devices. Now each chip has a different SDHCI, different USB, different UART and different I2c, each needing a different driver. x86 only has 2: the Intel variant or the AMD variant.
If you know what board are you booting on, then you can load correct hardware drivers for everything else. But that's not going to work without UEFI and ACPI.
Just make a mind experiment - Is flash memory SPI or parallel NAND? What if it is a Parallel NOR? Is EEPROM I2C? On which address? Which I2C controller should you use if there is more than one? Is EEPROM SPI? Which SPI controller you should use? How you should configure your SPI/I2C/Parallel controller? Which registers, on which addresses? On which GPIO pins is your memory device connected?
You would still need some board specific mini device tree in your OS to resolve this issue. That's the reason why we have UEFI booting first and letting board manufacturer resolve it and then just providing a communication layer to make standardized queries without knowing all those questions above.
UEFI isn't a standard (as ISO is, or even a RFC). It's actually a specification. If you call UEFI a standard, then DeviceTree would be a standard too [1].
> [...] letting board manufacturer resolve it and then just providing a communication layer to make standardized queries [...]
Letting the board manufacturer resolve UEFI is the same as letting the board manufacturer resolve u-boot + devicetree instead.
> Just make a mind experiment - Is flash memory SPI or parallel NAND? [...]
That's not how u-boot works. U-boot is always manufacturer- and board-specific, just like UEFI/BIOS/ACPI. U-boot loads the devicetree into memory in a board-specific manner that the OS doesn't need to know/care about. The OS receives the devicetree in a memory location, usually just appended to the end of the kernel image. It doesn't read any SPI/NAND/I2c or any other device except memory, which is already initialized by u-boot.
If uboot is in a EEPROM/flash onboard, then there is no need for the OS to include it, or any other board-specific data.
The notable difference is that u-boot + devicetree would not allow the manufacturer to compromise a system after boot, like UEFI can, because the kernel overwrites the u-boot in memory, keeping only the provided devicetree, which doesn't contain any executable code. After kernel starts, u-boot can't execute again, unlike UEFI and ACPI which can even inject .DLLs into Windows (see Thinkpad's CompuTrace).
Actually, the only "advantage" of UEFI is exactly this requirement for the OS to execute it while running. It's great for spyware and rootkits.
Which memory location? Any ARM SoC does not have defined where RAM must be. So which address are you going to touch from your OS to get the configuration? Yep, that's exactly what UEFI and ACPI are for
And no "at the end of kernel image" is not a memory location, because then your solution works only with your specific ad-hoc setup. All the Linux distros are not working, BSD is not working, Windows is not working. Only your blessed Linux Kernel will work and that's going to be all. No difference from adding a device tree directly into a Kernel then.
> And no "at the end of kernel image" is not a memory location
Like @201984 said, u-boot can load the devicetree separately and this is the more common way to boot. But even if it didn't, "the end of the kernel image" actually is a memory location. Kernel knows where it's executing from (all CPUs, not just ARM, have the Program Counter register) and it's own size (kernel decompressor knows the end of the compressed data).
> Any ARM SoC does not have defined where RAM must be.
That's known from the devicetree.
> All the Linux distros are not working, BSD is not working, Windows is not working.
False. You can take Ubuntu as example. There's only one bootable image for all ARM64. I have no experience with BSD and who tf. cares about Windows?
The location of the device tree is given to the kernel in x0 by the boot loader. See https://docs.kernel.org/arch/arm64/booting.html.
This device tree has information about the RAM location and hardware on the device, so in theory this can work just as well as ACPI does.
Two individuals along with multi-billion dollar corporations. Curious why the organizations that these individuals represent were not included instead?
An Intel-AMD merger would make sense, but it’s only extension of extinction if they don’t migrate from x86
> The moral is obvious. You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code. In demonstrating the possibility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode. As the level of program gets lower, these bugs will be harder and harder to detect. A well-installed microcode bug will be almost impossible to detect.
[0] https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...
You can trust a system by accepting that if it is owned, you are owned. If you don't trust it you instead protect it with a system that you do trust. For example, if you don't trust any x86 system you would not make them face the Internet. You would put them behind a trusted firewall.
But you have to decide whether you trust a system or not. If you trust it then you have to believe it when it reports a certain feature is disabled. If you don't trust it to begin with then it doesn't matter if it's disabled or not. Your security shouldn't be relying on it anyway.
Which is a hint to the solution: https://news.ycombinator.com/item?id=41368835