Skip to main content

Analyzing Apple’s decision to migrate Macs from Intel processors to ARM

In late June, Apple announced plans to transition its next generation Mac computers from Intel-manufactured x64 processors to custom ARM chips, something which Apple has branded as “Apple Silicon,” highlighting the provenance of the new hardware. Later this year when the first Apple Silicon-based Macs begin to roll out, the company’s line of Mac portable and desktop computers will be using the same ARM processors that Apple is currently using in its iPhone and iPad  products. While there has been ample coverage of this news in the trade press, much of the commentary I have seen online from various technology pundits (here is a representative sample analysis from one of these self-anointed experts) misses many key aspects of Apple’s recent decision. Apples’s move warrants a better and more complete analysis.

In brief, moving off of Intel processors and on to ARM CPUs is not a huge deal, but it is a very smart move. What is fundamentally significant about the decision to switch to the ARM processor in future generation Macs is that it unifies all of Apple’s major computing products– namely, its iPhone, iPad and Mac computers – to all use the same computing platform. This consolidation around processor technology that Apple itself controls means that a single, software stack will exist across all those current and future devices, significantly simplifying Apple’s internal software development processes, something which should reduce Apple’s internal software development costs. Macs equipped with Apple Silicon will be able to execute native iPhone applications available from the Apple Store, which is a feature that Mac users, a high percentage of whom also own iPhones (and/or iPads), are expected to take full advantage of.

Normally, porting to a new hardware platform is a big deal – I am thinking not only of Microsoft’s relatively recent port of Window 8 to ARM processors, but of Microsoft’s not very warm and mercifully brief embrace of the Intel Itanium platform. In both cases, Microsoft needed to exert considerable effort into compiler development to support a new Instruction set architecture (ISA), particularly on the code generation side, further complicated in the case of the Itanium because the processor instruction set incorporated so many new, and supposedly advanced CPU features that it bogged down the code generation folks at Microsoft, who were understandably baffled about how to best take advantage of all the new stuff.

In the case of Apple porting its Mac software to use Apple Silicon, the Apple developers responsible for the code generation behind the Swift and Objective C languages are already supporting ARM code generation for iPhone applications, simplifying this aspect of the port considerably. In fact, in tandem with the announcement of future Macs running on Apple Silicon, Apple released a new version of its application software development platform, which is called Xcode, that already supports the new hardware. The announcement that the software development tools to convert legacy Mac code to run native on the new Macs with Apple Silicon are shipping now speaks volumes. Converting Macs to ARM processors isn’t just aspirational, there is a realistic technology roadmap firmly in place, and the key first steps are already visible.

Another factor in making the change now is evidence that Intel might finally be slipping, struggling to make the next leap to 7 nanometer (nm) semiconductor fabrication technology while Apple’s manufacturing partner for ARM processors, TSMC, is thriving, cranking out chips using its current 7 nm fab facilities while positioning for its 5 nm next step. Intel is far enough behind TSMC in 7 nm fabrication that the Silicon Valley-based company recently took the extraordinary step of out-sourcing some of processor hardware fabrication to TSMC, something that has seldom happened in Intel's storied history. In the wake of ARM’s enormous reach not only in smartphones, but in low-power IoT devices becoming ubiquitous in automobiles, household appliances, web cams and many other types of products, Intel’s business model where it both designs the chips and builds them in its own semiconductor fabrication facilities is looking shaky for the first time in decades.

 ARM vs. Intel.  

The main difference between Intel and ARM processors is they use different instruction sets. Switching to a different instruction set is a normally huge deal for the software developers that are fluent in the old instruction set and now have to learn something new and potentially very different. It is much less of a big deal for Apple to make this switch because the company already makes extensive use of ARM processors, which power all its iPhone and iPad tablets, .

ARM processors are designed by the ARM consortium and licensed by member companies affiliated with the consortium, one of whom is Apple. (The Japanese conglomerate Softbank purchased the company in 2016 for a whopping $32 billion. In September 2020, Softbank announced a deal to sell ARM Holdings to nVidia, the US-based company known mainly for its graphics chips. The sale price is reportedly $40 billion.) ARM itself provides only the standard design; other companies perform the actual manufacturing. For iPhones, for example, Apple hardware engineers create a SoC (System on a Chip) design that packages an ARM multiprocessor CPU, a GPU, and a Neural Engine all on the same microprocessor chip. Apple outsources manufacturing of these integrated ARM-based SoC microprocessors to the Taiwan Semiconductor Manufacturing Company (TSMC) at its state-of-the-art 7 nm semiconductor fabrication facility, probably the largest of its kind in the world. TSMC will supply the microprocessors that the new Apple Silicon Macs will use.

In converting from one processor architecture and instruction set to another, almost all of the burden associated with learning the new instruction set falls on a relatively small number of professional software developers, those that code directly in the new instruction set – namely, those programmers who write Assembler language code. Third party application developers who write code that runs on the Mac using Apple’s developer tools will be insulated from the change in hardware by transitioning their code bases to what Apple is calling Universal apps. “Universal” in this context only means that an Objective C or Swift app can be built today that runs native on current Intel Macs and will run native on the ARM-based Macs when the hardware becomes available without having to re-compile. What Apple is supplying here is a set of common runtime binaries that run on both Intel and the coming generation of ARM64 Macs. Apps built on top of that runtime will execute on both varieties of Macs, with Apple re-assuring current Mac customers that it intends to support Intel-based Macs for many years to come.

The folks that cannot be insulated from the change in the underlying hardware are Assembly language programmers. They know how to use the Intel x64 instruction set and now need to transition to using the ARM instruction set, which is very different. For the most part, Assembly language coding is limited to developers of operating system software (like the macOS developers) and compiler developers (like the ones who develop Apple’s Swift, Objective C and other language compilers that plug into the Xcode IDE and related tools). Even within the OS developer team, the developers primarily involved in Assembler language development are a few (very senior) folks that work specifically on the microkernel, a small set of core OS routines that include thread scheduling, device interrupt handling, serialization primitives for multi-threaded synchronization, inter-process communication (IPC), memory management, exception-handling, debugging, etc., the details of which all depend on the specific processor architecture and, thus, require assembly language code.

Among compiler developers, the developers specifically responsible for code generation are impacted the most, although the Apple developers working on Mac debugging and performance tools like Instruments are also going to take a big hit. Nevertheless, Apple, already seriously invested in ARM hardware, can be expected to leverage considerable internal ARM expertise and cadres of skilled ARM developers, all of which positions the company very well in taking on this port to ARM.

To support Universal Mac app development, in June Apple released a new version of its Xcode developer tools for the Mac that is also a flagship Universal Mac app. Version 12 of Xcode runs native on current Intel Macs and will support the new ARM-based Macs when they are available. The runtime libraries that make Xcode 12 “universal” today are deployed whenever you build a new Universal Mac app. With the new Xcode tooling, most application developers won’t have to learn very much about the new machine architecture to get them up and running on both older Intel-based Macs and new Macs that are built using Apple Silicon. In fact, if they already write programs for the iPhone, because the next generation of Mac machines will be running on the same underlying hardware as the iPhone, they already know most of what they will need to know about writing software for the Mac.

Apple’s Xcode documentation highlights the following concerns that developers porting current Mac apps to Universal apps might encounter, noting that any code that does the following is going to present difficulties:

  • Interacts with third-party libraries you don’t own.
  • Interacts with the kernel or hardware.
  • Relies on specific GPU behaviors.
  • Contains assembly instructions.
  • Manages threads or optimizes your app’s multi-threaded behavior.
  • Contains hardware-specific assumptions or performance optimizations.

The major showstopper is the first bullet point, any 3rd-party libraries that your code depends on that has not been converted to the Universal platform. You cannot mix and match Intel x64 code with ARM binaries in the same process.

Marginal Macs.

The move to Apple Silicon can also be viewed as a way to breathe some new life into the Mac line of business, which is marginalized inside Apple due to the success of the iPhone. Sales of Macs account for about $7 billion quarterly, as reported in Apple’s latest financial results, slightly more than 10% of Apple’s overall $60 billion quarterly revenue. The Mac is further marginalized outside Apple within the broader Intel-based PC portable and desktop business due to its limited market penetration, roughly in the 6-8 % range, depending on when you look and whose consolidated PC sales numbers you look at.

Because the Mac holds only a slim share of the overall PC market, it is currently difficult to get developers to target the platform due to its limited reach. And when you drill into the usability data for many of these “creative” type Mac owners, they spend most of their time running web-enabled applications like Google’s tools or Office 365. These customers could just as easily run these browser-based, cloud-enabled apps on inexpensive Chromebooks, less expensive Windows PCs, or even iPads, but they would have to be willing to sacrifice some of the hipster quotient that accrues when you flaunt your shiny tech toys while sipping on a latte at the neighborhood coffee bar, imbibing your daily caffeine fix.

Nevertheless, the Mac represents a $20 billion annual revenue stream inside Apple, that is also very profitable, not something you just walk away from. Apple sells plenty of Macs, and the company has been very successful painting an image of the Mac as cooler than a stodgy, business-oriented, Windows PC. Persuading an influential number of “creative” types that Macs are a cool alternative to PCs is a strategy that also allows Apple to sell at a significantly higher price point (see the pricey new 27” Mac, for example, and its whopper of a price tag) than the bulk of commodity-priced PCs. This is good for Apple’s bottom line. In addition, Mac customers are also extremely loyal, and they tend to buy other Apple hardware products, too. Replacing Intel processors with Apple Silicon is a way for the company to preserve the healthy profit margins associated with its line of Macs, and potentially differentiate them from garden-variety, Intel-based PCs.

One of the big potential benefits Apple sees in making the switch from Intel to ARM is enabling the army of developers that already write code for the iPhone to easily write code that also runs on the Mac. Right out of the gate, the new Macs equipped with the same ARM processors that iPhones use will be able to run current iPhone apps, many of which were never ported to run native on the Mac because its customer base is limited. To run the popular TikTok app on current Macs, for example, because a native Mac version of the app is not available, you first need to download and install an Android emulation program like Bluestacks, then download TikTok from Google Play and install that, which then allows you to run TikTok under the emulator. It is not a great experience. You are probably better off just accessing TikTok in the Safari web browser. The new ARM-based Macs will include an x64 emulator layer called Rosetta for Mac apps that were never ported to the Universal platform. Running an older x64 Mac app under Rosetta is probably not going to be a great experience either – this sort of real-time instruction set emulation is extremely clunky when it comes to performance.

In exchange for the long-term benefit of bringing iPhone software directly to the new Macs, Apple is prepared to sacrifice some sales of current Intel-based Macs in the short term. As expected, the announcement that there are new Macs coming, machines that are radically different from current Intel-powered Macs, is freezing many buying decisions. Apple says the first ARM-based Macs will be available in December, but it hasn’t been clear about which model Macs will be first out of the gate and which ones will lag. Meanwhile, Apple is starting to sell its new Intel-based iMac 27” desktop machines, targeting mainly Xcode developers who need to get started on the port to ARM-based Macs as soon as possible.

With the Universal app-compatibility layer in place on Intel Macs, it is premature for Apple to walk away from Intel processors entirely, especially at the high-end where Intel’s more powerful 10-core multiprocessors will out-perform the most powerful available ARM64 processors, currently Apple’s A13 Bionic processors with its 2 high-performance (Big) cores and four low-power (Little) processor cores embedded on a single chip. (For more about this innovative computer architecture, see an earlier blog post of mine entitled “Is there an ARM-based PC in your future” that dates back to 2012.) Apple currently uses the A13, which is built by TSMC using its 7 nm fabrication capability, exclusively in high-end iPhones and iPads.

My guess is that some of the first Apple Silicon Macs will use the A13, too, initially in portable PC products like the iMac Air, where battery use, which is where the ARM processors are technically superior to Intel CPUs, is more important that sheer CPU processing power and speed. As part of a program for developers who want to get to work right away on porting Mac apps to Apple Silicon, Apple is providing developers access to a limited number of Mac minis equipped with A12 SoC ARM microprocesses. Apple’s A12 SoC is a slightly older version of the A13 that is about 20% less powerful, according to Apple sources. Going forward, it will be interesting to see when (or if) its premium SoC chips become available in Apple-Silicon Macs.

However, workloads on single user portable and desktop PCs seldom require all the processing power that Intel high-end chips can deliver. Ten-core Intel processors are only useful when there are at least ten processing threads ready to execute or for important compute-bound tasks that demand the best possible performance. Those are not workloads that are common to single-user workstations, the exceptions being video rendering and other graphic processing applications and maybe software developers that require the best possible turnaround time for compile and build jobs.

One casualty of the move to Apple Silicon will be that the Mac OS will lose the virtual machine capabilities that allow current Mac users to also boot Windows and host Windows applications in a separate virtual machine. This Mac-Windows compatibility layer appears to be unavailable on Apple Silicon.  Again, this seems like a reasonable trade-off, much less important to Mac customers today than when it was first released. Instead of being forced to run MS Office applications like Word, Outlook and PowerPoint on a Windows virtual machine, Mac customers can run native versions of those apps today, Or they can run Office 365 apps in the cloud from their browser (along with comparable cloud-based productivity apps from Google). Recognizing that the iPhone and various Android phones are the platforms developers need to target today, not PCs running Windows, Microsoft appears committed to porting apps like MS Office to run native on the Mac and is embracing cross-platform development generally, recognizing that the Windows PC is no longer the platform developers are targeting these days.

Moreover, Apple continues to maintain complete control over what 3rd party applications it permits to run on the iPhone, extracting a healthy 30% surcharge on 3rd party application software exclusively available through its App Store. Apple does not separate out its App Store revenue from other software services, like iTunes licensing and iCloud storage fees, but it is safe to assume that it is considerable. Apple’s latest financial results show its revenue from “Services” exceeds the combined revenues of its Mac and iPad hardware business. Extending the market for iPhone software to Mac hardware certainly sweetens the deal.

Summary.

Building Macs on Apple-Silicon is intended to help shore up Apple’s ample profit margins for its Mac line of portable and desktop PCs. Apple originally turned to Intel-based Macs back in 2005 when Intel processor technology held a clear price-performance lead over all its competitors. In the interim, Intel has lost its once prominent edge in hardware manufacturing to ARM SoC microprocessors built in 3rd party semiconductor fabrication facilities like the one used by TSMC, which builds the ARM processors that already power Apple phones and tablets. ARM-based Apple-Silicon may lag Intel technology at the high-end, but the portion of the portable and desktop PC hardware segment that Macs occupy seldom requires that kind of peak, multi-core processing power.

The most significant aspect of Apple migrating the Mac from Intel to ARM-based processors is that it allows Apple to consolidate all its internal software development for its portable phones, tablets, and portable and desktop PC hardware on a single hardware platform. This consolidation should streamline software development inside the company, resulting in major cost-savings to Apple. Porting OS software and compiler code generation software to a new instruction set architecture is not nearly as big deal for Apple as it was for other companies like Microsoft because Apple already has significant ARM expertise in-house. 



Comments

Popular posts from this blog

Monitoring SQL Server: the OS Wait stats DMV

This is the 2nd post in a series on SQL Server performance monitoring, emphasizing the use of key Dynamic Management View. The series starts here : OS Waits  The consensus among SQL Server performance experts is that the best place to start looking for performance problems is the OS Wait stats from the sys.dm_os_wait_stats DMV. Whenever it is running, the SQL Server database Engine dispatches worker threads from a queue of ready tasks that it services in a round-robin fashion. (There is evidently some ordering of the queue based on priority –background tasks with lower priority that defer to foreground tasks with higher priority.) The engine records the specific wait reason for each task waiting for service in the queue and also accumulates the Wait Time (in milliseconds) for each Wait reason. These Waits and Wait Time statistics accumulate at the database level and reported via the sys.dm_os_wait_stats DMV. Issuing a Query like the following on one of my SQL Server test mac

High Resolution Clocks and Timers for Performance Measurement in Windows.

Within the discipline of software performance engineering (SPE), application response time monitoring refers to the capability of instrumenting application requests, transactions and other vital interaction scenarios in order to measure their response times. There is no single, more important performance measurement than application response time, especially in the degree which the consistency and length of application response time events reflect the user experience and relate to customer satisfaction. All the esoteric measurements of hardware utilization that Perfmon revels in pale by comparison. Of course, performance engineers usually still want to be able to break down application response time into its component parts, one of which is CPU usage. Other than the Concurrency Visualizer that is packaged with the Visual Studio Profiler that was discussed  in the previous post , there are few professional-grade, application response time monitoring and profiling tools that exploit

Memory Ballooning in Hyper-V

The previous post in this series discussed the various Hyper-V Dynamic Memory configuration options. Ballooning Removing memory from a guest machine while it is running is a bit more complicated than adding memory to it, which makes use of a hardware interface that the Windows OS supports. One factor that makes removing memory from a guest machine difficult is that the Hyper-V hypervisor does not gather the kind of memory usage data that would enable it to select guest machine pages that are good candidates for removal. The hypervisor’s virtual memory capabilities are limited to maintaining the second level page tables needed to translate Guest Virtual addresses to valid machine memory addresses. Because the hypervisor does not maintain any memory usage information that could be used, for example, to identify which of a guest machine’s physical memory pages have been accessed recently, when Guest Physical memory needs to be removed from a partition, it uses ballooning, which transfe