That's valid only if the ARM won't run x86 binaries. If Apple does a "Rosetta2" then that would be OK for me.
----
The phrase "Rosetta 2.0" was forming in my mind then I saw you wrote it. The transition from PPC to Intel wasn't painless, but Rosetta certainly eased my suffering.
It is petty tough to do Rosetta 2 when didn't do Rosetta 1. Technically Apple really didn't do Rosetta. The core of the Rosetta system was actually technology from a company called Transitive. That company doesn't exist anymore ( acquired by IBM which probably has about close to zero interest in giving Apple a sweetheart deal on a follow on. ) .
There's another way to look at it. There is a library of 1 million iOS apps, some of which could form the basis of a new library of OS X apps.
Cocoa Touch and Cocoa are different enough that this really isn't a core. It is also the case if just add a few more tweaks to Cocoa Touch is it really necessary? These same apps that are a "core" are also essentially in competition. Things like Continuity are also dual edge swords as iOS matures and takes on more robust abilities.
Apple has never moved an Apple OS to a platform that
already has major established Apple OS.
Anyway, Apple handled the 68K to PPC transition pretty smoothly, and Rosetta worked decently enough in the transition from PPC to x86.
Apple did the 68K -> PPC transition about two decades ago. If Apple hasn't technically done an emulator in that long of a period of time, what is the chance they still have retained the skill set necessary? It was absent enough almost a decade ago that they outsourced the solution from Transitive. They still haven't built any deployed expertise and Transitive is now gone.
The other huge gap is that the 68K -> PPC and PPC --> x86 transition points the targeted arch was substantively faster than what was moving away from. That eases the dealing with the emulation overhead. In this proposed ARM one, there is mostly arm waving flapping (***) about how ARM might be equivalent speed with native, not emulated, code.
Cheaper doesn't particularly had major traction either when Intel now has sub $100 SoC offerings. [ Sure the current ones are a bit behind the high end ARM but in the two years for ARM to catch up, Intel can be doing the exact same thing with there low cost alternatives. ]
Apple's ARM implementations are optimized for the same constraints iOS has. Primarily one app at time (with some background daemons). If iOS shifts to multiple concurrent apps with the ARM following then what's the point of porting OS X? If iOS is consuming OS X functional domain, then just let the process roll forward.
*** Geekbench and synthetic gaming benchmarks are arm flapping. They aren't system performance benchmarks of real world load. Benchmarks of primarily instruction cache loaded code and high data cache hit rates doesn't necessarily hold up in real world app contexts and even less in emulator (and higher than average branching) workloads.
Geekbench multipe threaded is not necessarily indicative of multiple process/application performance at all. SIMD is not MIMD.
I'm not saying everything would be perfect, or that there aren't drawbacks to a switch to ARM, but it would be irresponsible for Apple NOT to at least experiment with the idea.
An experiment used to trot out as a bogeyman to scare/motivation Intel to keep pushing. Absolutely worth the money. Intel is at its best when they running in the paranoid mode ( " Only the paranoid survive" -- Andy Grove).
I don't think have to necessarily drag things to market (e.g., Windows NT on Alpha / MIPS , Windows RT ) to actually get them going if proactive in asking for stuff and looking to leave them reasonable profits for their products.
However, a major part of why the 68K -> PPC and PPC -> x86 transitions made sense was that to move ALL of the Mac platform over. The emulator is more so for seamless legacy apps while the developers and users shift over at various speeds. However, the emulators Apple deployed were never intended to be permanent solutions.
If Intel
and AMD totally screw up down stream then sure they can go to the Plan B ARM alternative. So far Intel hasn't screwed up in the processor space that Apple actually buys. Their roadmap for the next 2-3 years is pretty good and Apple probably an even deeper insight into that than most do.
They are getting to be pretty good at customizing ARM for mobile devices. If they ramp up power consumption to the levels NVIDIA is using for the Tegra K1 they may be able to get a notebook running at decent speeds in the near future.
That doesn't make alot of sense. Can't really just ramp the exact same design up to high power or super high clock rate. The power and clock distribution are tuned for specific implementations.
It makes sense for Apple to do optimized SoC for their high volume iOS devices. The major disconnect is that OS X devices, relatively speaking, are
not high volume. Apple has shown little to no motivation to get into low volume ARM optimizations at all. None. They even rebadged the M1/M2 motion solutions from outsourced provider(s).
Apple has enough chip design expertise to do about 2 SoC designs in pipeline fashion An and AnX ( where n = 5 , 8 , 9 , etc. ) that's it. The focus on a small targeted implementation is exactly why they are managing to get to market several months ahead of the other ARM vendors who have more design and more general implementation targets. If Apple widens their focus there is zero indication that they won't slide back to being matched with same logistical overhead the other ARM implementors have. It won't improve the overall corporate competitive position to sacrifice iOS competitive advantage just to weave in OS X and gratuitously kick Intel in the shins.
Nvidia isn't a particularly successful ARM implementor in the mobile space.
They have a limited set of design wins, but are not the major player Apple is competing against. Apple will have better GPUs over time. Mostly likely those will be optimized for iPad usage.