Apple has made two transitions while retaining compatibility, in one case with emulation of the old architecture being around the speed of the previous (68k to PPC) and in the other with emulation being faster than the previous architecture (PPC to x86). There's no ARM that's fast enough to emulate an x86 in the same power envelope, so right now any transition would either require all performance sensitive apps to be ported or would result in machines that were slower for many tasks.
Bear in mind that both previous transitions were due to the processor line Apple was using being effectively EOLed (explicitly in the case of 68k, more implicitly in PPC - nobody was interested in making CPUs that had the appropriate performance/power ratio for consumer machines). Apple is doing great things with ARM, but they're not /that/ far ahead of the rest of the industry that they can pull off a seamless transition in the near future.
This is not happening any time soon and the article is junk. Previous transitions (68K->PPC->x86) occurred when the successor CPU's were so stupidly more powerful than what they replaced that emulation was a plausible tactic.
This is NOT the case with x86->ARM. Apple's ARM chips are impressive and are approaching Intel's chip in some areas if you benchmark in certain ways and ignore the areas where they fall short. I think people underestimate the gap. Maybe one day ARM while be fast enough to make switching worthwhile and emulate x86 acceptably, but it is not this day.
I would say it is more likely that Apple will end up releasing some sort of cross-CPU .NET/JavaVM-esque technology that compiles software locally if they really want to merge the product lines. But I am not even convinced that Apple wants to merge the two lines.
I lived through both major Mac CPU transitions (68K-PPC and PPC->X86) and in both cases the assumption was that it was impossible for Apple to ship a usable emulator. In both cases Apple proved everyone wrong and in fact the emulator was a major contributing factor to a smooth transition. It simply takes a lot of time for all 3rd party software to be released for the new architecture.
Given how they handled it in the past my guess is that Apple will release a very usable X64 emulator for the ARM and really brag about it at WWDC.
It sounds almost unbelievable, but it could happen. I mean, Apple, unlike every other computer company, has successfully transitioned processor architecture twice before (68k to PowerPC, PowerPC to Intel). They could pull the same tricks they pulled for PPC to have a smooth transition: x86 emulation on ARM, “Universal” (fat) binaries, and making it easy for developers to port their apps.
Apple will require CPU emulation to support legacy software releases (think Creative Suite, MS Office, ...); whether this can be done with reasonable performance on ARM is the first real question.
After that, why not make a switch? We (developers) can support ARM just as easily as x86-64, x86-32, and PPC. There are some specific areas that will require rework (games!), but investments are already being made there to support iOS.
Given how smooth Apple's transition from PPC to Intel was, and how much experience Apple has with ARM in their portable lines -- if/when the complete transition to ARM happens it'll probably be a brief blip on everyone's radar and likely increase competition both price and performance-wise in the desktop sector.
What's stopping Apple from adding hardware-level emulation to their SOC's, even if it's only partial functions, to ensure cross-compatibility doesn't take a serious toll on performance? x86 would be patent-encumbered but I'm sure there are a few creative ways to reduce that burden.
To imagine that the transition from ppc to x86 is remotely comparable to a present-day x86-to-ARM transition is utterly absurd. Basically everything has changed: Hardware architectures, software architectures, OS design, etc. The amount of software out there for x86 macs is massive and end users are going to expect all that stuff to work (even if they'll grumble and accept it when Apple tells them that only 50% of it will work). You're also having to maintain compatibility with a massive set of third party hardware used by creatives, developers and enthusiasts - are you gonna run those drivers in an emulator? In kernel mode?
This would be an undertaking beyond any past one, because in the past computers were much simpler and Apple controlled a bigger part of the picture. Now they're shipping elaborate GPUs and hardware stacks that mash together chips from various vendors and there's a ton of third party hardware and software all working on top of it. If they don't keep most of that working users won't stand for it. Something like "we need to get AMD or NVIDIA to provide us a top-tier video driver for the Axx instruction set and convince them not to demand a king's ransom for it" would not have been an obstacle in the PPC days but it's unavoidable now unless they want to ship their own GPU too (which they could do, but again, compatibility)
As for compatibility, Apple managed exceedingly well the moves from 68K to PPC and then to Intel, even keeping some binary compatibility. Few companies ever did that - DEC comes to mind, making VMS and Ultrix move from VAX to Alpha, and IBM moving the iSeries from AS/400 to POWER. iOS software will continue to be written for ARM for as long as we can see. macOS can, eventually, move to ARM too - if Microsoft can do it (emulate x86 at Celeron speeds on Snapdragon), Apple certainly can.
Both times the new CPU architecture was faster than the older one, granted. But still the emulated software would be slower on the new models with the emulator compared to bare metal execution on the old models.
I assume Apple will make some more improvements to close the gap between x86 and ARM, and switch when it makes sense for them. I also assume that, with the Mac App Store, they will start forcing developers to ship software compiled to both architectures ahead of making the switch. This way, only software that is distributed outside their store would be slow, which is going to become more and more niche as Apple enabled stricter signing enforcement by default in macOS Sierra (by default, only apps from the Mac App Store are allowed to run).
That's not really true. x86 emulation is a solved problem at this point, and Apple has shown willingness to use emulation to bridge an ISA transition in the past.
I think the real reason is some combination of (a) ARM isn't competitive (or only recently became competitive) at the high power/high performance point that Intel CPUs excel at; (b) the Mac line generates so much less revenue and operates at so much smaller of a scale than iOS devices that it isn't worth developing CPUs in-house for them, not to mention the fixed costs associated with undergoing a transition.
Achieving the same level of performance with ARM is only half the story.
Apple has to surpass the Core i series to make any sense to switch.
And then there's the whole clusterfuck that would be porting all the x86 software to ARM. When Apple switched to Intel emulation of Power PC was usable via Rosetta but AFAIK emulation of x86 with ARM is extremely slow.
Assuming the Apple-designed ARM chip is indeed significantly more performant than the x86-64 chip (there wouldn't be much point to this transition otherwise -- if it was solely about business concerns with Intel, they could use AMD's x86-64 chips instead), they could do an emulation mode of some kind. They could potentially even have some hardware optimizations for it.
Apps like photoshop would still get compiled targeting the new architecture to take advantage of the performance benefits, but other apps could run in emulation mode. Then, over say 3-4 years, most commercial and open-source apps would get updated or be replaced by alternatives.
On one hand, it's weird to use a different CPU than other computers. On the other hand I hate x86 and its complexity and its weird hacks, and it's about time someone ditched it. Although they literally just actually completed the transition to x86-64 a few months ago so it's a bit hilarious they're moving away so soon.
> I don't think that Apple will completely get away from x86 for a long time. Attempting to emulate the x86 on an Arm would be terribly slow.
It's not you're emulating an entire operating system: the operating system (and many libraries) are native, but the application code is emulated. It's faster than you think, and Apple has already done it twice: once in 1994, and once in 2005 (exercise for the reader: try extrapolating).
Apple's applications would be 100% native long before the ARM version shipped. Some intensive tasks—text rendering, audio/video/image encoding and decoding, HTML layout, JavaScript—these would also be native on third-party apps, since you just have to write the right glue into the emulator. This would be a lot easier than the 2005 switch from PowerPC to x86, which involved emulating a system with 4x as many GPRs and the opposite endian: ARM has 2x the GPRs as x86-64.
Sure, a bunch of apps will see reduced performance. Some will break. But remember: Apple has only been on x86 for ten years. We had the same problems during the PowerPC->x86 transition: you had to wait about two years to get a version of Photoshop that ran on x86 + OS X.
I'm willing to bet that Apple has been testing OS X on ARM for years now.
While it'd be neat to see, I think the hurdles that exist in moving from Intel to ARM are pretty high, and far higher than they were when they moved from the PowerPC range to Intel.
Just a few off the top of my head:
- The Mac platform, today, is much more widely used than it was in the PowerPC days. This is a double-edged sword. Apple can use their substantial weight to force ISVs to recompile[0]. These ISVs are unlikely to provide the next version for free. Some ISVs won't exist any longer, forcing one to run the application in whatever Rosetta-like compatibility later is produced. I can't speak to how well a translation application would work going from x86->ARM, but the only emulators I've seen that perform well are ones where the target platform is dramatically more powerful than the emulated platform (Nintendo emulators, etc). The impact to users on upgrading is very high and there are many more of them, now, which will get noisy. Their competition has also gotten better at producing more desirable competition (Surface Book, Windows 10[1])
- ARM's aims are performance-per-watt, not performance at all costs. I don't care if my desktop drinks electricity. I care if it does things quickly. I don't believe Apple will make this move until they can be assured that a processor can be developed for about the cost of an Intel equivalent and will perform as well[2].
- I'm foggy on the details, but my understanding is that App Store submissions are required to be done in a way that provides LLVM or other IL/VM language code instead of machine code. This could land them in a spot where re-compiling to a new platform can be done by Apple (assuming ToS have granted them that right), which is great ... for apps in the App Store. The mac platform app store isn't the only source of software.
- Apple would almost certainly have to design the processor as they have with their phone. "They've done it before, they can do it here" is a somewhat fair and unfair argument. Desktops have different design goals than phones/iPads. Notebook designs would probably fall somewhere in-between the two. To do it right, they probably have to support two new processor designs: one for "Pro Desktop" and one for a notebook that has more performance than their highest end mobile device, but sips power like their highest-end mobile device. The cost, all around, will be high: low-power/high-performance/cheap, pick two. Intel gives them high-performance/cheap and moderate power.
There are other, less important reasons, but in weighing pros and cons, I can't come up with a lot of benefits to doing this. The funny thing is that even as I was writing this, I could come up with plenty of counter arguments and the reality is that "Apple could actually pull something like this off". I am having a difficult time figuring out, though, what the upside is for them. Apple owning the processor doesn't buy them a whole lot. And while having a single set of CPU instructions[3] sounds like it might benefit ISVs, it really only helps mac-only ISVs. Most of those ISVs are going to have to target Intel platforms if they're supporting Windows. There would have to be a few other huge reasons to do this to offset the costs.
Personally speaking, I'd love to see something like this ... I'd probably find myself buying an Apple product[4].
Part of me (that more cynical side) me wonders if these rumors don't originate out of Apple as a way to keep Intel on its toes. Apple is a big customer and hints that Apple may jump ship to ARM keep Intel focused on improving the performance/watt ratio and likely helps them on price.
[0] And we all know it's not just a matter of changing the target platform for any moderately complex application
[1] Yeah, maybe not the best examples, but privacy elements aside, Windows 10 works, is pleasant to use and rarely crashes despite my running insider builds in the fast channel.
[2] I haven't looked too deeply into the server processors, but my sense is that they're desirable mainly because of the core numbers, almost as though the ARM processors are making up for single-threaded performance by throwing more cores at the problem. And that's probably a good deal for many/most server use cases. Many server tasks are simple as far as an individual thread is concerned, but multiplied by the concurrent use.
[3] Well, no, not exactly.
[4] For all of the same reasons these "insiders have [not actually] designed an ARM desktop", but also because my inner geek would like to play with an ARM desktop.
Given that Apple pulled it off twice with the Mac 68K emulator (for the Motorola 680x0 to PowerPC transition) and on OS X with Rosetta (for the PowerPC to x86 transition), it's certainly possible and ARM processors have come a long way.
I am going to go out on a very short limb and predict that Apple does no such thing in the foreseeable future, say 3 or 4 years. In the past, Apple has only transitioned to a new architecture once it was so powerful that it could easily emulate older hardware. Apple doesn't care about backwards compatibility as much as Microsoft on desktops but even they cannot release a new desktop/laptop that doesn't run existing software.
Although ARM processors are fast in certain benchmarks, they cannot compete with x86 for performance and certainly cannot emulate the instruction set at a speed users would find acceptable.
ARM makes great sense for low power devices and _maybe_ servers. Apple already makes tons of the former and seems uninterested in the later.
It's not an obvious win like the last couple of architecture switches because of the end of Moore's law. Like the PowerPC chips they were initially using ran 68k code quicker in a non-JITing emulator than any 68k they could buy. They had to switch to a JIT with Rosetta, but that same perf distinction was still true for the high end for PowerPC/Intel during their switch.
Running x86 code faster in an emulator than on a real chip might not ever happen.
And in not too long the x86-64 patents will have expired all the way through SSE4... I think Apple making their own x86 chips is just as likely as switching to ARM.
There will always be a question of backward compatibility due to the nature of the Mac ecosystem that you don't have in iOS. Then you have the issue of getting developers to migrate any existing arch specific optimisations. This can be mitigated somewhat and Apple has done this a few times before, but it's still a massive undertaking.
It may be easier for them to play the CPU vendors against each other if there is real competition in the AMD64 space. There are rumours of Apple going ARM on Macs, so it may be that that path is set, but if it isn't, there is sense in holding out the transition to ARM at this time.
But that’s still a tall ask at the high end, and splitting the Mac lineup into models that can’t all run the same software isn’t appealing.
Apple has already done this. The 68K to PPC transition wasn't nearly as quick as the PPC to x86 transition. They released new 68K Macs after releasing PPC Macs. The apps were "fat binary".
When I bought my first PPC Mac, all of my apps were on an external SCSI drive. I attached the drive to PPC Mac and it ran native software.
If the processor advantage never reaches the point that it can emulate x86 at full speed, then the Mac line probably won’t transition,
Again it doesn't have to. I had a first generation PPC Mac 6100/60 that ran emulated code slightly slower than my accelerated 68030-40Mhz LCII. My 68K Mac was about half the speed of the high end 68040-40Mhz Macs. It couldn't emulate programs that used the 68040's FPU at all. There were third party hacks that you could run like SoftwareFPU (a 68K program nonetheless) that could emulate an FPU.
The high end programs are always the first to be ported. The other apps are "good enough" and depending on how much time an emulated app spends running native operating system code, it won't be all emulated.
Bear in mind that both previous transitions were due to the processor line Apple was using being effectively EOLed (explicitly in the case of 68k, more implicitly in PPC - nobody was interested in making CPUs that had the appropriate performance/power ratio for consumer machines). Apple is doing great things with ARM, but they're not /that/ far ahead of the rest of the industry that they can pull off a seamless transition in the near future.
reply