The very second someone else but Apple brings a competitive ARM desktop CPU to the market, it's game over for Intel. x86_64 literally cannot compete with modern ARM designs simply because of how much utter garbage from about thirty years worth of history it has accumulated and absolutely needs to support in the future because even the boot process still requires all that crap, whereas ARM was never shy about cutting out stuff and breaking backwards compatibility to stay performant.
The only luck that Intel has at the moment is that Samsung and Qualcomm are dumpster fires - Samsung has enough problems getting a phone to run at a halfway decent performance with their Exynos line and Qualcomm managed to completely botch their exclusive deal with Microsoft [1] (hardly surprising to anyone who has ever had the misfortune to have to work with their crap). A small startup that is not bound by ages of legacy and corporate red tape should be able to complete such a project - Annapurna Labs have proven it's possible to break into the server ARM CPU market well enough to get acquired by Amazon.
[1] https://www.xda-developers.com/qualcomm-exclusivity-deal-mic...
No. All it needs is
- Microsoft and Qualcomm breaking their unholy and IMHO questionably legal alliance
- an ARM CPU vendor willing to do the same as Apple did and add support for accelerating translation of x86 code (IIRC, memory access models/barriers are done differently between x86 and ARM, and Apple simply extended their cores to be able to use the same memory access/barrier model as x86 on translated-x86 threads)
- an ARM CPU vendor willing to implement basic functionality like PCIe actually according to spec - even the Raspberry Pi which is the closest you can get to a mass market general-purpose ARM computer has that broken [1]
- someone (tm) willing to define a common standard of bootup sequence/standard feature set. Might be possible that UEFI fills the role; the current ARM bootloaders are a hot mess compared to the old and tried BIOS/boot sector x86 approach, and most (!) ARM CPUs/BSPs aren't exactly built with "the hardware attached to the chips may change at will" in mind.
Rosetta isn't patented to my knowledge, absolutely nothing is stopping Microsoft from doing the same as part of Windows.
[1] https://www.hackster.io/news/jeff-geerling-shows-off-an-amd-...
This reminds me of Iron Man 1... "Tony Stark was able to build this in a cave! With a box of scraps! - Well, I'm sorry. I'm not Tony Stark."
Apple has managed to pull it off so well that the M1 blasted an i9 to pieces [1]. The M1 is just so damn well more performant than an Intel i9 that the 20% performance loss compared to native code didn't matter.
[1] https://www.macrumors.com/2020/11/15/m1-chip-emulating-x86-b...
The use case for the vast majority of laptops include I/O- and memory-bound applications. Very few CPU-bound applications are run on consumer laptops, or even corporate laptops, for the most part. CPU-bound applications should be getting run on ARM or GPU clusters in the cloud.
The use case for an M1 in laptops is the power benchmarks vs. an i9.
Where the M1 just blows anything desktop-Intel out of the water, partially because they integrate a lot of stuff directly on the SoC, partially because they place stuff like RAM or persistent storage extremely close to the SoC whereas on desktop-Intel RAM, storage and peripheral controllers are all dedicated chips.
The downside is obviously that you can't get more than 16GB RAM with an M1 and 24GB RAM with the new M2's and you cannot upgrade either memory at all without a high-risk soldering job [1]... but given that Apple has the persistent storage so closely attached to the SoC to swap around, it doesn't matter all that much.
[1] https://www.macrumors.com/2021/04/06/m1-mac-ram-and-ssd-upgr...
Wouldn't bet on that one
Conventional wisdom in the mid 90s was powerpc (RISC) would eventually be better the x86, but it never happened. They worked around the issues. And Microsoft eventually made an OS that wasn't a crash fest (I'm looking at you windows ME)
Also no one can afford to be on TSMCs best node when Apple buys all the production. Apple's been exclusive on the best node for at least a couple years now. Even AMD isn't using TSMCs best node yet.
Yeah, but that was (at least on the Mac) not a technical requirement, they just didn't want to carry around the kernel-side support any more. IIRC it didn't take long until WINE/Crossover figured out a workaround to run old 32-bit Windows apps on modern Macs.
> Also no one can afford to be on TSMCs best node when Apple buys all the production. Apple's been exclusive on the best node for at least a couple years now. Even AMD isn't using TSMCs best node yet.
Samsung has their own competitive fab process, but they still have yield issues [1]. It's not like TSMC has a monopoly by default.
[1] https://www.gsmarena.com/samsung_claims_that_yields_from_its...
... Oh yeah, and there are the junkware features like SGX and TSX and also the long legacy of pernicious segmentation that means Intel is always playing with a hand tied behind its back, for instance, the new laptop chips that should support AVX512 but don't because they just had to add additional low performance cores.
If you have all the cores running hard the power consumption goes up a lot but if it is just one core it won't go up too much. If worse come to worse you can throttle the clock.
In general it's a big problem with SIMD instructions that they aren't compatible across generations of microprocessors. It's not a problem for a company like Facebook that buys 20,000 of the same server but normal firms avoid using SIMD entirely or they use SIMD that is many years out of date. You see strange things like Safari not supporting WebP images on a 2013 Mac while Firefox supports them just fine because Apple wants to use SIMD acceleration and they'd be happier if you replaced you 2013 Mac with a new one.
I worked on a semantic search engine that used an autoencoder neural network that was made just before GPU neural networks hit it big and we wrote the core of our implementation in assembly language using one particular version of AVX. We had to do all the derivatives by hand and code them up in assembly language.
By the time the product shipped we bought new servers that supported a new version of AVX that might have run twice as fast but we had no intention of rewriting that code and testing it.
Most organizations don't want to go through the hassle of keeping up with the latest SIMD flavor of the month so a lot of performance is just left on the table. Intel is happy because their marketing materials can tell you how awesome the processor is but people in real life don't experience that performance.
I'm glad to hear some newer AVX512 implementations are better. I haven't used an Intel one for years, but I have used the current-gen Ryzen version. Unfortunately it's still suffering the same problems-last time I stress-tested it my CPU hit 100C and some absurd power number before I was too scared to continue. Granted, that was with Prime95, which I believe is close to peak utilization.