Apple Expected to Announce Arm-Based Mac Plans at WWDC, Transition Away From Intel to Begin in 2021

[cmaier]

In June 2005, to facilitate the PPC->Intel transition, Apple offered (for $999) an Intel-equipped Developer Transition System to select developers. It was essentially an Intel CPU inside a PowerMac G5 case, that ran OS X 10.4.

[Seven months later, in Jan 2006, when the first Intel Macs were released—consisting of the first 15" MBP, and a new iMac line—they offered to swap these systems for iMacs.]

I wonder if they'll be doing the same this time, except using, say, Arm-equipped Mac minis.

This time around they may have machines ready to go for sale - the difference this time is the transition has been in the works for many years - after all, Apple was designing its own chips so the cpu team and the computer team could work hand-in-hand.

 

[firewood]

Does it make financial sense for Apple to go it alone with their own high-performance silicon (CPU and GPU) to supply a desktop/laptop market share that sits at 10% of the PC market, ... Intel and AMD's R&D costs are paid for by much larger customer bases that include the server market as well, ...

It probably doesn't make sense for just their desktop/laptop hardware alone running generic apps. But Apple can leverage various integrations with their huge market share in mobile, tablets, and wearables, both in hardware tech (portions of CPU cores, GPUs, ML engines, security processors, etc.) and with customizations for their value added software technology, including ARM app development engineering. Apple is also a huge data center customer.

Note that the total mobile app market (almost 100% ARM) is estimated to be larger than Intel's total revenue.

 

[Unregistered 4U]

Evidently it does or they wouldn't be doing it

Not only that, Apple CURRENTLY ships the CPU’s in a far more massive number of iDevices. Adding macOS devices to that would just be a blip of additional cost in the grand scheme of things.
[automerge]1592683201[/automerge]

This time around they may have machines ready to go for sale - the difference this time is the transition has been in the works for many years - after all, Apple was designing its own chips so the cpu team and the computer team could work hand-in-hand.

I was reading an article recently correctly capturing that Apple’s been preparing for this for awhile, but then going off into how it’s going to take LONGER to have their major apps ready. As if the “preparation” part of this only applies to the hardware side of the business! I’m expecting to be surprised at how far along they are across the board.

 

[cmaier]

Not only that, Apple CURRENTLY ships the CPU’s in a far more massive number of iDevices. Adding macOS devices to that would just be a blip of additional cost in the grand scheme of things.
[automerge]1592683201[/automerge]

I was reading an article recently correctly capturing that Apple’s been preparing for this for awhile, but then going off into how it’s going to take LONGER to have their major apps ready. As if the “preparation” part of this only applies to the hardware side of the business! I’m expecting to be surprised at how far along they are across the board.

For sure. I’m quite convinced that the OS and all their own apps are fully ready. Any issues will likely be issues on both intel and arm platforms that happen every time they beta a new OS.

 

[Sydde]

This time around they may have machines ready to go for sale - the difference this time is the transition has been in the works for many years - after all, Apple was designing its own chips so the cpu team and the computer team could work hand-in-hand.

in the mid oughts, there was talk about, what was it, "Project Star Trek" or something, where they had OS X running in x86 already, so the transition was imminent. Now they have had almost all of it running on ARM, in the wild, for a decade (5 or 6 years on 64-bit), so that is a done deal. It has been extensively field-tested and debugged, the only things missing, TBMK, being a few appkit objects (that do not have UIKit analogs) and Bindings (last I heard).

In fact, I could see the iPad Pro transitioning into notebook space with not much difficulty. It already has a USB-C connector, and, quite frankly, who would not prefer a device that does not get totally fried when you spill your Jolt into the kbd? Or, even, allows you to choose the kbd model you prefer instead of having to put up with theirs.

 

[TGM85]

ARM keeps getting better while Intel and AMD have to work pretty hard to keep their Moores-millennia-old architecture competitive.

Yes, the Egyptians, Greeks and Romans really knew how to put those Pentium II and AMD Duron CPUs to work for them. Just look at all the architecture they were able to design with those ancient CPUs

 

[makman]

They did that in 1996, too. How long did that last?

TSMC totally changes the picture.

 

[cmaier]

TSMC totally changes the picture.

For the moment. In 1996 Intel had an insurmountable fab lead.

And, btw, Apple gets to use TSMC too. So if all that matters is fab, and since Apple has better designers than AMD, Apple wins.

 

[makman]

For the moment. In 1996 Intel had an insurmountable fab lead.

Intel's manufacturing stumble at 10nm has put them a generation behind TSMC. By the time they get 7nm up (equivalent to 5nm at TSMC), TSMC will be ramping 3 nm. Given that TSMC is a pure-play with a singular focus on fab, and, btw, larger than Intel in market cap, it might be tough for Intel to retake the process crown. And AMD is basically TSMC x86. Anyway, this is only an issue that affects the AMD vs Intel question - as you point out, Apple is already at TSMC.

And, btw, Apple gets to use TSMC too. So if all that matters is fab, and since Apple has better designers than AMD, Apple wins.

The real question is how quickly Apple is going to go easing off x86 in its mac transition to ARM. Because while Apple may be at the world's most advanced fab and have incredible designers, they do not have an x86 license. Anyway, we'll find out soon enough.

 

[Marty_Macfly]

Hi All,


Ok, time to resurrect this discusion thread! 😀

I read it a few weeks ago, thanks for all the contributers 😀



.....OK Apple Announcements over....


What are your thoughts on this transition to ARM chips by apple?

1st apple propducts out by end of this year? Seems really early for flawless apps etc.


Be good to heat your thoughts

regards

Martin 😀

 

[JPNMac]

Why did Apple announce the use of their silicons in Macs but not say they would use ARM?

 

[cmaier]

Why did Apple announce the use of their silicons in Macs but not say they would use ARM?

They did say they would use arm. It’s on the website and was discussed in the afternoon session.

Consumers watching the keynote don’t care about arm, and apple wanted to emphasize its THEIR chip, not some chip designed and sold by someone else.

 

[Sydde]

As I understand it, the ARM CPUs will handle Intel code through run-time translation rather than traditional emulation. It is not clear to me whether the translated code is stored for subsequent launches in order to smooth out app operation over time, but if this is the strategy, it is difficult to imagine that Apple would discard the utility as early on as they dropped Rosetta.

 

[cmaier]

As I understand it, the ARM CPUs will handle Intel code through run-time translation rather than traditional emulation. It is not clear to me whether the translated code is stored for subsequent launches in order to smooth out app operation over time, but if this is the strategy, it is difficult to imagine that Apple would discard the utility as early on as they dropped Rosetta.

Yes, from hints in documentation about start up times on first run, etc., what’s going on is that when you install an x86 app it will be translated to the extent it can be. If already installed, it will be translated on first run, so the first start up will be slower than subsequent. And in some cases there is JIT translation, depending on the nature of the code.

 

[Unregistered 4U]

Yes, from hints in documentation about start up times on first run, etc., what’s going on is that when you install an x86 app it will be translated to the extent it can be. If already installed, it will be translated on first run, so the first start up will be slower than subsequent. And in some cases there is JIT translation, depending on the nature of the code.

I think Apple‘s benefit here is that almost all applications have been written and compiled with Xcode. Because Apple knows exactly what their compiler output looks like and it’s intent, they can replace the code intelligently and efficiently. I’d imagine, as always, that anyone who took a dev route that didn’t include Xcode are the ones that will have a harder time.

 

[Sydde]

I think Apple‘s benefit here is that almost all applications have been written and compiled with Xcode. Because Apple knows exactly what their compiler output looks like and it’s intent, they can replace the code intelligently and efficiently. I’d imagine, as always, that anyone who took a dev route that didn’t include Xcode are the ones that will have a harder time.

A few years ago, they required App Store submissions to be in llvm-ir form, which means that a specific device could receive a processor-optimized post-compilation executable. I am not clear whether the conversion was done in-store or the llvm-ir package was delivered as-is to be converted on the target device. Having a converter built into every OS does not seem that big a deal, and the package does not contain comment text (AFAIK).

llvm-ir is processor-specific, but it does give a translator an easier place from which to start.

 

[theorist9]

As I understand it, the ARM CPUs will handle Intel code through run-time translation rather than traditional emulation. It is not clear to me whether the translated code is stored for subsequent launches in order to smooth out app operation over time, but if this is the strategy, it is difficult to imagine that Apple would discard the utility as early on as they dropped Rosetta.

Here's a nice discussion of this subject by Ryan Smith at anandtech:

The Next Phase: Apple Lays Out Plans To Transition Macs from x86 to Apple SoCs

www.anandtech.com

x86 Compatibility: Rosetta 2 & Virtualization

Meanwhile, in order to bridge the gap between Apple’s current software ecosystem and where they want to be in a couple of years, Apple will once again be investing in a significant software compatibility layer in order to run current x86 applications on future Arm Macs. To be sure, Apple wants developers to recompile their applications to be native – and they are investing even more into the Xcode infrastructure to do just that – but some degree of x86 compatibility is still a necessity for now.

The cornerstone of this is the return of Rosetta, the PowerPC-to-x86 binary translation layer that Apple first used for the transition to x86 almost 15 years ago. Rosetta 2, as it’s called, is designed to do the same thing for x86-to-Arm, translating x86 macOS binaries so that they can run on Arm Macs.

Rosetta 2’s principle mode of operation will be to translate binaries at install time. I suspect that Apple is eyeing distributing pre-translated binaries via the App Store here (rather than making every Mac translate common binaries), but we’ll see what happens there. Meanwhile Rosetta 2 will also support dynamic translation, which is necessary for fast performance on x86 applications that do their own Just-in-Time compiling.

Overall Apple is touting Rosetta 2 as offering “fast performance”, and while their brief Maya demo is certainly impressive, it remains to be seen just how well the binary translation tech works. x86 to Arm translation has been a bit of a mixed bag, judging from Qualcomm & Microsoft’s efforts, though past efforts haven’t involved the kind of high-performance chips Apple is aiming for. At the same time, however, even with the vast speed advantage of x86 chips over PPC chips, running PPC applications under the original Rosetta was functional, but not fast.

As a result, Rosetta 2 is probably best thought of as a backstop to ensure program compatibility while devs get an Arm build working, rather than an ideal means of running x86 applications in the future. Especially since Rosetta 2 doesn’t support high-performance x86 instructions like AVX, which means that in applications that use dense, performance-critical code, they will need to fall back to slower methods.

On which note, right now it’s not clear how long Apple will offer Rosetta 2 for macOS. The original Rosetta was retired relatively quickly, as Apple has always pushed its developers to move quickly to keep up with the platform. And with a desire to have a unified architecture across all of its products, Rosetta 2 may face a similarly short lifecycle.

 

[cmaier]

I think Apple‘s benefit here is that almost all applications have been written and compiled with Xcode. Because Apple knows exactly what their compiler output looks like and it’s intent, they can replace the code intelligently and efficiently. I’d imagine, as always, that anyone who took a dev route that didn’t include Xcode are the ones that will have a harder time.

It’s also slightly easier to go from CISC to risc. After all, that’s what the instruction decoder in an x86 chip is doing (sort of).

 

[theorist9]

In addition, there's this from a recently-posted Apple developer document (https://developer.apple.com/documentation/apple_silicon/about_the_rosetta_translation_environment), which I take to mean that Parallels and VMWare will need to compile their code to run natively on Apple Silicon.

I would guess that Apple has already been working with them on this (as they've been with Adobe and MS), since it's in their mutual interest for this software to work on the ARM Macs.

What Can't Be Translated?

Rosetta can translate most Intel-based apps, including apps that contain just-in-time (JIT) compilers. However, Rosetta doesn’t translate the following executables:

• Kernel extensions
• Virtual Machine apps that virtualize x86_64 computer platforms

Rosetta translates all x86_64 instructions, but it doesn’t support the execution of some newer instruction sets and processor features, such as AVX, AVX2, and AVX512 vector instructions. If you include these newer instructions in your code, execute them only after verifying that they are available. For example, to determine if AVX512 vector instructions are available, use the sysctlbyname function to check the hw.optional.avx512f attribute.

 

[theorist9]

Another interesting tidbit from the anandtech article is this:

As noted by our own Arm guru, Andrei Frumusanu, Arm is on the precipice of announcing the Arm v9 ISA, which will bring several notable additions to the ISA such as Scalable Vector Extension 2 (SVE2). So either Arm is about to announce v9, and Apple’s A14 SoCs will be among the first to implement the new ISA, otherwise Apple will be setting the baseline for macOS-on-Arm as v8.2 and its NEON extensions fairly late into the ISA’s lifecycle. This will be something worth keeping an eye on.

So while Apple has a great deal of latitude in customizing the microarchitechture (and has done so extensively), does this mean that Apple needs to wait on ARM for advances in the ISA? Or can, and will, Apple go entirely its own way?

 

[cmaier]

Another interesting tidbit from the anandtech article is this:



So while Apple has a great deal of latitude in customizing the microarchitechture (and has done so extensively), does this mean that Apple needs to wait on ARM for advances in the ISA? Or can, and will, Apple go entirely its own way?

It can do what it wants, but if it claims compatibility with any particular arm instruction set it has to be compatible. So it can add stuff if it wants.

 

[dgdosen]

Regarding being arm64 - would that mean binaries built for arm64 should work on an Apple silicon mac without recompiling? Or docker containers targeting arm64 would just work?

 

[SocialKonstruct]

Here are some actual developers chatting about this transition in greater detail:

 

[theorist9]

It can do what it wants, but if it claims compatibility with any particular arm instruction set it has to be compatible. So it can add stuff if it wants.

What would be the advantage, to Apple, of having such compatibility?

Would it make it easier for devs who've, say, written apps for ARMv#-based Android phones to port them to iPhones if the latter used an ARMv#-compatible ISA? And would Apple want such porting to be easier?

 

[cmaier]

What would be the advantage, to Apple, of having such compatibility?

Would it make it easier for devs who've, say, written apps for ARMv#-based Android phones to port them to iPhones if the the latter used an ARMv#-compatible ISA? And would Apple want such porting to be easier?

Maybe, though i doubt apple would care. They may be contractually obligated to be compatible with at least some of the arm instruction subsets. Or maybe they only have to do that if they use Arm’s trademarks. We don’t know what the details of their license agreement are.