All you need to know is that until now, the power increases in Apple chips over the last 7 years has been consistently linear. So consistent that I believe they have been purposefully and artificially holding back their chips until they gave us a pretty big jump with M1 because of the mobile use-case before M1.
Sure, both Intel and AMD have things in the pipeline but Apple has something that they don’t - an unprecedented amount of head room with regards to power consumption and thermals. Add to this the inherent efficiencies gained by Apple’s specific ARM implementation/package architecture, their lack of legacy support and their vertical integration through to the entire software stack and you have an extremely solid foundation to build upon.
Think of it like this - Apple is pretty close to matching the single core performance of the best their competitors have currently and they are doing so at clocks of 3.x ghz vs 5ghz, whilst consuming a fraction of the power. Apple has the opportunity to use all of this to now start scaling horizontally (increasing core counts) and vertically (clock speeds), without fighting heat and power consumption the whole way like the others - and that’s just on this node process.
I think once we get into the pro machines, Apple is going to step things up significantly and very comfortably destroy the competitors in terms of performance. I then think they will drip feed performance increases to keep in line or just ahead of the competition whilst having a lot in reserve - they won’t want to blow their load too early. This then gives them breathing space in their hardware release roadmap - they can focus on R&D of what they will do in say, 5 years from now, instead of spending all their resources on being reactive to the market and playing catch up, like I’m sure Intel is right now. This is the period where Apple needs to be extremely vigilant around complacency.
With regards to the concerns voiced by the OP about applications and gaming, for those developers that already have intel MacOS apps, it’s trivially easy to port to ARM, with the exception of Apps that can’t solely take advantage of high level APIs and libraries and must have interaction with the bare metal - the most glaring example being virtualisation software.
With regards to gaming, we are already seeing the emergence of projects aimed at acting as a compatibility layers to translate OpenGL/Vulkan function calls to Metal with negligible performance hit.
Looking at developer support on Apple ARM in particular, don’t forget that Apple has basically trained a generation of hundreds of thousands (if not millions) of Devs to code in this environment for iOS devices, the switch to ARM macOS is then relatively easy to move across.
With regards to ARM support more broadly over the next 5+ years as long as Microsoft can nail down their X86 and more importantly X86-64 compatibility on ARM (especially if they develop their own ARM implementation, which will be driven by their data centre requirements) I can see a situation where the majority of Windows Laptops will be ARM based. Especially given we’re likely to see much more focus on other companies with ARM competence such as Nvidia and maybe even Samsung pivoting more towards higher end ARM products for laptops.
You’ll then see this weird fragmentation where consumers are using Windows on ARM, most data centre Cloud workloads will be on ARM and the last holdout will be Windows in on-prem enterprise or data centre bare-metal use-cases (both of which are very quickly becoming legacy), being pressured along from both the consumer low end and the very high end enterprise market segments (a kind of piggy in the middle).
Even if Microsoft is sluggish in getting Microsoft ARM up to power Azure, they will be getting immense pressure from AWS and Google Cloud with their proprietary ARM and their users then running Windows workloads in the Cloud on ARM. I’m sure Microsoft is rapidly adapting all of their licensing models for both desktop and server to include ARM - it would be crazy of them to retain exclusivity of ARM Windows, that is the Microsoft of 15 years ago under Steve Ballmer.
en.wikipedia.org
en.wikipedia.org
en.wikipedia.org
- Dependencies. This is for example the reason why it’s near impossible for games on Steam to be M1 native. Disco Elysian for example has an Apple Silicon native version on the Mac App Store, but the Steam version runs through Rosetta. The reason, is that when Steam launches a game, it’s launched with a Steam dylib in its memory space and that dylib is x86 as is the launcher code steam uses, so if the game ships ARM binaries we have mixed instruction streams and it’ll crash on launch. The developer can make their own code Apple Silicon native by just updating their build config, but they have dependencies that haven’t been updated - in this example they depend on Valve to update Steam and its libraries. And because of the way Steam’s launcher and Steam integration in games work, it’s one of the 5% of cases that requires a bit more effort than the checkbox. Some studios circumvent this by having their own launcher be the first thing that shows, offering to launch the ARM binary without full Steam integration or launch through Rosetta with Steam integration.
