Windows on ARM x86 emulation from a Mac transition perspective

Microsoft’s Edge browser is available for Windows on ARM as is Microsoft Teams. On the other hand, as for Microsoft Office, the only version that will run on Windows on ARM is the 32-bit Intel x86 binary — there is no ARM version of Microsoft Office. This is a very confusing situation that puts into doubt the level of commitment that Microsoft has towards Windows on ARM. Certainly, if you were an independent developer with a Windows application, you would be very concerned about the long-term viability of the new platform, and if Microsoft was not optimising their own software, then you might think that you shouldn’t either.

As is often the case however, the reality is not that simple.

I recently discovered a series of tweets from Hari Pulapaka, Group manager at Microsoft that cleared up the issue for me. Microsoft provides Compiled Hybrid Portable Executable (CHPE) versions of their Office DLLs (Dynamic Linked Libraries) which are optimised for ARM, which means that Office running on Windows on ARM is a hybrid of emulated x86 code and native ARM code. Microsoft analysed which DLLs are most critical for performance and then provided ARM optimised CHPE versions for these, while leaving the remainder as is. As a result, even though a large portion of the application is still emulated x86 code, the final result is much faster than 100% emulation. This allows Microsoft to get the first version with satisfactory performance quickly out of the door, and then to gradually rewrite the whole application leading eventually to a fully optimised version.



This approach is not new. Back in the late 1980s and early 1990s when Apple was transitioning away from Motorola 68k CISC processors and towards PowerPC RISC, they also had to provide a smooth transition path through code emulation. What they came up with was a 68k emulator and with a scheme so that instead of rewriting the whole MacOS System 7.1 in PowerPC code from the start, they would identify the most time-critical parts and optimise only those. This allowed them to make a gradual transition. The first version that could run on PowerPC Macs was System 7.1.2 which was still mostly 68k code running on the emulator. By System 8.5, Apple had replaced most of the 68k code and the system no longer ran on 68k Macs. Unlike the PowerPC to Intel transition in 2006 where Apple already had a version of Mac OS X that was running natively on Intel (“a secret double life”) many years before as a backup,  MacOS System 7.1 was a legacy system that was introduced in 1984 and was not designed to be CPU agnostic. Therefore it was clear from the onset that fully rewriting the OS would take years and hence the gradual optimisation route made a lot of sense.

The Windows version of Office has its roots back in the 1990s and it comes from an era when writing CPU agnostic code was less important for personal computers. It also has a large ecosystem of plug-ins which may not work across difference CPU architectures. Therefore a full rewrite in ARM code would require a lot of engineering resources and would also break plug-ins, many of which may come from third-parties. On the other hand, the code for the Edge browser (a lot of which is was based on the open source Chromium project which is CPU agnostic) is much easier to fully recompile for ARM. The same goes for Microsoft Teams which is built on the cross-platform Electron environment. 

The Mac version of Office is in a very different situation compared to Windows. Although the Mac version actually predates Windows, the multiple CPU and OS transitions on the Mac have forced it to also go through fundamental rewrites. Also, the plug-in ecosystem is much, much smaller. Therefore, we can speculate that rewriting the Mac version for ARM is a much easier undertaking.

We are tempted to assume that the lack of a fully ARM-optimised version of Windows Office for ARM is proof that Microsoft is not committed to that platform. However the reality is much more complex. The difficulty of the optimisation task varies widely depending on multiple factors, and this is often the most important factor in the decision to do so or not. It is rarely a matter of commitment alone.

What Mac can teach Windows about the switch to ARM

Dieter Bohn, wrote a great article about processor transitions published on The Verge. The article titled “What Windows can teach the Mac about the switch to ARM processors” illustrates some issues Apple may face.

Looking back after the Apple M1 Mac announcement, we can see how they addressed each and every topic in that piece. It’s a great example of how Apple tends to put all their wood behind a single arrow, making sure as much as possible that they get everything right.

ARM-based Windows computers are slower

Apple could have made this transition earlier if it was content with Apple silicon Macs being as slow as the Surface Pro X. I’m sure that they had MacOS running on ARM for many years already, gauging the performance compared to Intel. They waited until performance was good enough, which, based on their previous successful transitions, means about double the performance on at least some key tasks. With the M1 chips which have screaming performance, Apple has clearly overcome this hurdle.

Windows computer with an ARM processor actually requires a higher level of technical expertise

Dieter is talking about how Windows on ARM can emulate 32-bit Intel code but cannot run 64-bit code, and so users have to know which apps are written in which binary. Even when Apple transitioned from Motorola 68k to PowerPC, they made it very seamless with a great emulator. This time, Apple has Rosetta 2 which is apparently at least as good, so they cleared this one too.

“Here’s a cool new thing you can get if you want, but the reliable old thing isn’t going anywhere.”

Here Dieter is talking about whether Apple should allow ARM and Intel to coexist, or whether it should transition the whole lineup. Windows is supporting both x86 and ARM, and the emphasis is still clearly on x86 — ARM is a niche platform for those people who prioritise ultra-portability and long battery life ahead of performance and compatibility. As a result, as Dieter mentions, Windows on ARM is not getting hardly any developer attention. Even Microsoft has failed to port Office to ARM. Apple on the other hand has been very clear. Although they will continue to support Intel for many years, they will transition their whole Mac lineup to ARM within a couple of years. ARM and Intel will not coexist and there will be a clear transition. This is how Apple has managed every other transition.

What Apple got right

Apple is one of the rare tech companies that does not constantly throw spaghetti against the wall to see what sticks. In the case of this transition and all previous ones, instead of spitting out hardware with the new chips before they were ready, they waited (intentionally or otherwise) until the new processor architecture provided a multiple-fold performance advantage, prepared a great emulator, and then made a full transition in one sweep. Because of this, developers prioritised re-writing their code and supporting the new Macs.

In hindsight, Steven Sinofsky’s tweet storm also shows why Apple’s strategy of doing everything in discrete stages makes a lot of sense and why Windows RT (the ARM port of Windows 8) failed. Apple is forceful in committing to change, but also careful to change as little as possible with each transition. In the 68k to PowerPC transition and also in the PowerPC to Intel transition, Apple changed only the CPU architecture while maintaining the software APIs. On the other hand, when making the transition from the Classic Mac OS to MacOS X, the hardware was kept on the PowerPC. Apple never made a transition where both the hardware and software APIs were changed. In contrast, it is clear that Windows RT tried to do too much in one go. With the current Intel to ARM transition, Apple is changing only the CPU architecture while keeping the software APIs and the user interaction model exactly the same.

To put this in one simple word, I would choose “focus”. Apple focused on the right timing. They focused on getting all the parts ready for that timing. They also focused on doing just one thing during each transition. Dieter’s article and Steven’s tweet storm remind us that this was the very thing that Microsoft lacked.

Will Apple Silicon increase the market share of the Mac?


The discussion below is based on the assumption that the premium PC market is already dominated by Macs. Therefore, as long as Apple sells predominantly in this segment, there is not much additional market share to win. Although I have not seen any recent data, in 2009, NPD reported that 91% of US retail sales for PCs over $1,000 went to Macs. The number may not be accurate for 2020, but I am confident that the overall picture remains the same. 

I would have thought that this was a very easy question to answer. Unfortunately, some people seem to miss it.

Let’s be clear.

The PowerPC G3 Macs were advertised as being twice as fast as Pentiums. Many ads were made and many demos were performed to suggest that Macs were vastly faster than PCs. Mac market share hardly budged.

Apple iPhones with Apple silicon have constantly been faster than competing Android phones. This hasn’t propelled them further than 20% market share of the whole market.

Performance, either the ability to crunch numbers or the length of time you can run on a single battery charge, has seldom, if ever, been the factor driving market share. Instead, pricing, distribution channels, compatibility, network effects and other less sexy but conventional market forces tend to determine this.

Sure, some high-end laptop customers may decide to switch, but we also know that the premium market is very small in terms of market share. Although I do not have enough numbers to make an informed estimate, I guess that that we will only see a gain of a few percentage points at most. Although this will be enough to significantly increase Apple’s Mac revenues, Windows market share will remain dominant.

The only way that this might change is if Apple uses their silicon to drive down prices and sell laptops in the $600 price range. This is not unthinkable but it will require a big change in strategy, and we have no idea whether Apple will choose to do this or not.


Changed the price range in the final paragraph from $400-$600 to just $600 to be in line with the average selling price of laptops in the US in 2020.

The performance of Rosetta 2 and Windows on ARM tranlators/emulators

There has been much praise of the recently introduced Apple M1 Macs. Part of that is obviously due to the performance of the Apple M1 SoC. However, the performance of Rosetta 2 also seems to be very good since non-native, Intel-coded apps reportedly perform very well, sometimes exceeding their performance when run natively on Intel Macs.

On the other hand, Microsoft also has an emulator that allows you to run 32-bit x86 code on top of their Windows on ARM operating system. Reviewers were very disappointed by the performance of this emulator, however. Unfortunately, it is difficult to discern whether the dismal impressions were due to the emulator itself, or to the lacklustre performance of the hardware powered by SoCs that are far slower than the Apple M1.

Here, I would like to look at some benchmarks that have been posted on the web, and try to understand the performance of these two emulators/translators independent of hardware variances. I want to know how well they perform from a pure software perspective, after the differences in hardware have been factored in and controlled for. 

Bootcamp will not be coming to the Apple M1 Macs but Apple demoed a development version of Parallels during the M1 announcement, showing that operating systems coded for the ARM architecture can run on M1 Macs through a virtual machine. This suggests that the best path to run Windows on an M1 Mac will be to run Windows for ARM on Parallels (although Microsoft currently imposes licensing restrictions for this). Since the vast majority of Windows apps (including most of Microsoft’s own apps) have not been rewritten for ARM, they would be relying heavily on Microsofts’ translator/emulator. The current discussion should give us an idea of the performance that we can expect under this scenario.

Rosetta 2

  1. Geekbench shows that Rosetta 2 running emulated x86 code achieves 78-79% of the performance of native Apple Silicon code.
  2. Arstechnica ran browser benchmarks comparing native Chrome and Rosetta 2 emulated Chrome. Speedometer 2.0: 116 vs 210 (55%), Jetstream2: 93.1 vs 156.9 (59%), Motion Mark: 435.7 vs 726.4(60%) (x86 vs Native) 

There is also a very interesting and technical discussion of what Rosetta 2 might actually be doing to achieve this performance.

Windows on ARM

  1. Geekbench 4 single-core on a Surface Pro X scores 2293 in x86 emulation mode and 3643 when run natively. In multi-core tests, the results were 7215 and 12370 respectively. Here emulation is achieving 63% and 58% of native performance.
  2. A Google Octane browser test on the HP Envy x2 was performed on the Edge browser (native ARM code) and Chrome (emulated Intel code). Chrome scored 3500 while Edge was 10712. Since Chrome is typically the same or faster than Edge when run natively on Intel, you can estimate that emulation achieves 35% or lower performance on Windows for ARM.
  3. A game developer wrote his own benchmark code to test the performance of the emulator. He concluded that emulated performance is 3x to 8x slower than native code.

There is some documentation on the Windows for ARM x86 emulation layer here.


QEMU is open source software that provides a virtual machine, with or without binary code emulation. Alexander Graf tweeted his success on porting this to Apple M1 and running Windows ARM64 Insider Preview on it through Hypervisor.framework. Although it is highly unlikely that this open source project will provide a mainstream approach to running Windows on M1 Macs, this is similar to the approach that was demoed for Parallels, and what Apple executives have been mentioning. Alexander provided a comment on the performance of x86 emulation in this setup.

Windows 10 ARM64 can run x86 applications pretty well. It’s not as fast as Rosetta2, but close.


It is very difficult to draw conclusions since we do not have a suite of direct comparisons with the same benchmarks. The ratios between native and emulated code vary widely depending on whichever test we use, and it is impossible, given the current data, to give a qualitative assessment. This is very unfortunate since even low double-digit gains in performance do not come easily. In particular, we cannot evaluate the claims made by Apple with regard to how Rosetta 2 translates ahead of time to further optimise and how this improves efficiency. Nonetheless, it does seem that Rosetta 2 can consistently emulate x86 code with less performance penalty compared to Windows for ARM, but although the difference may be significant, it does not look like we will be looking at more than a 3x difference in general.

As announced, Windows for ARM will soon be gaining the capability (at last) to emulate 64-bit Intel x86 code. We might also see additional optimisations bringing performance closer to Rosetta 2. The introduction of this feature would be good timing for Microsoft to also relax licensing restrictions for Windows for ARM, allowing its mainstream use on M1 Macs. Parallels does seem very positive about the situation and I think we should be too.


This post has been updated and edited significantly since the original publishing date of 23-Nov, especially with regard to the tweet by Alexander Graf.

Successful processor transitions: Apple M1, ARM and chicken-and-egg problems

Apple has announced that they are making the transition to Apple Silicon within two years. The excitement around the performance of their chips is extremely high, and there is even talk about whether Wintel PCs will make a similar transition in the near future. Here, I would like to review what history tells us about transitions and evaluate whether this is indeed a likely scenario, or whether the Intel x86 architecture will prevail.

Chicken and egg

Before we start, I would like to emphasise that this is a typical chicken and egg problem. End-users will purchase the new devices if they run their favourite applications faster. However, application software developers will only invest resources to re-write their applications for the new CPU architecture, if they are confident that enough end-users will purchase the new devices.

The situation is the same in other levels of the value chain.

The transition from 68k to PowerPC Macs

A good summary of this transition can be found here. There are two factors that made this transition possible. First of all, the performance gap was already very wide, and with all the excitement around RISC, many people were convinced that it would get even wider in the future. Second, Apple had developed a very capable 68k to PowerPC emulator.In fact, the emulator was so good that a good portion of the operating system itself was not yet written in PowerPC code and had to be emulated. It was easy to mix 68k code with PowerPC code and so developers could gradually port their applications to PowerPC, focusing on the portions that affected performance the most.

Thus the chicken and egg problem was solved.

  1. End-users were confident that their apps would run on the new PowerPC Macs, and would also provide performance benefits.
  2. Application developers gained confidence that the PowerPC Mac users would be their main customers in the future, and they had a strong incentive to make their apps perform as best they could on the new architecture.
  3. Application developers did not have to spend huge resources upfront. They could gradually transition their software by focusing on the parts that mattered the most.
  4. Additionally for the CPU vendors, IBM and Motorola, they had their own agendas for investing in the PowerPC architecture, and to continue to provide high-performance designs.

The transition from PowerPC to Intel

Again, by the time Apple decided to make the switch, PowerPC lagged Intel in raw performance. What was more severe was the sheer inferiority in performance per watt, which was gaining more importance as computing was shifting from desktops to laptops. It was evident that the transition to Intel would provide significant performance benefits. 

Apple also stressed that Intel-based Macs would be reliable since Apple had been running an Intel version of MacOS X for quite some time (“a secret double life”). Unlike the 68k to PowerPC transition, the underlying operating system was already written in Intel code.

Emulation software was also available (Rosetta) which allowed most applications written for PowerPC to run on Intel Macs without modification. For the most part, you would not know if an app was running native or under Rosetta unless you took a peek with the “Activity Monitor” utility. Emulation was that good.

Furthermore, the PowerPC to Intel transition had great developer tool support. Ever since the transition from the classic MacOS to MacOS X, the development tool of choice had been Apple’s Xcode suite. Apple provided the capability to easily recompile your existing Xcode project into Intel binary code, touting that all it took was to tick a checkbox, and even if it was an exaggeration, Intel optimised versions of pre-existing applications emerged within months.

Apple also announced that the full transition of their line-up would be completed within two years.

So here again, the chicken-and-egg problem was solved.

  1. End-users were confident that their favourite applications would run on the new Intel Macs smoothly, with performance gains coming in the future.
  2. Application developers knew that Apple would fully transition within two years and that if they did not do this quickly, they would be left out from the performance benefits.
  3. Xcode made it easy for application developers to transition to Intel code with minimal effort.
  4. Intel had a strong vested interest in improving CPU performance and had already had chips that performed far better than PowerPC.

The transition to Apple Silicon

The transition to Apple silicon builds upon Apple’s experience going through the 68k to PowerPC transition and the PowerPC to Intel transition. All the parts that made these two past events successful are fully ready. The Apple M1 touts vastly superior performance over Intel chips, Rosetta 2 is here, Apple has announced that the transition will be over in two years, and the M1 is based on the same technology as the iPhone SoCs so there are no doubts about Apple continuing to invest in them.

Nobody has any doubts about the success of this transition.

Will Windows transition to ARM?

Windows has show interest in moving Windows to the ARM architecture for almost a decade. However, to this day, this remains a very small niche project. Microsoft ported Windows 10 to the ARM platform in 2017, providing the capability to run regular Windows app on ARM and not just UWP apps. They do provide an emulator for running code written in Intel binaries — however, this is severely limited since it only supports 32-bit. Reportedly, 64-bit support will come at last, after almost three years on the market.

The silicon that currently powers ARM PCs are the SQ2 in the Surface Pro X, and the Qualcomm 8cx in the Samsung Book S and others. While they do provide benefits in battery life, in terms of raw performance, they are at the bottom of the herd, even when running native apps.

Therefore, it comes as no surprise that Microsoft nor any other PC vendor has not made any commitment on fully transitioning their PC line-up. ARM-based PCs remain just a small niche segment for customers who value mobility over anything else, and who are willing to sacrifice performance and compatibility. Nobody thinks that ARM-based PCs will make a significant portion of the total user base.

With the above, we can analyse the chicken-and-egg problem for Windows moving to ARM.

  1. End-users have no confidence today that their favourite apps will run on Windows for ARM. With the emulator supporting only 32-bit Intel code today, a large number of apps simply do not run. Even if Microsoft announces 64-bit Intel code support, it will take a while for consumers to believe that Microsoft is committed to good compatibility.
  2. End-users have no confidence that their apps will run with good performance. Even when the apps are rewritten in ARM code, given the current ARM processors available, they will only see performance similar to low-power consumption Intel laptops.
  3. Application developers have no confidence that a significant number of users will purchase ARM hardware. On the contrary, they know well that ARM will remain a small niche market. ARM users will not purchase many apps since the compromise that they made in the first place was that they would use their devices only for casual browsing and email. This makes this niche unattractive for developers.
  4. Even Microsoft itself does not seem to be convinced that recompiling for ARM is worthwhile. The glacial speed at which they are recompiling their own productivity apps proves this. MS-Office is still not available as ARM binaries, and MS-Teams has just come a few weeks ago.
  5. Qualcomm has been developing the SQ2 and the 8cx for PCs, but performance is in the low-power PC range. We are not seeing anything like the Apple M1, where it rivals and exceeds all Intel MacBooks in single-core performance. Successful transitions by Apple have always involved multifold jumps in raw CPU performance, and it is clear that the Qualcomm ARM chips are not delivering in this regard.
  6. There is the question of whether or not non-Apple CPU vendors will have the incentive to develop ARM chips as powerful as Apple Silicon, with the same power efficiencies. If there was an independent market for powerful non-Apple ARM chips, then the incentive might be there. As of today, I cannot identify such a market.

Given the above, it seems unlikely that the chicken-and-egg problem will be solved, and so I doubt that we will see a successful transition of Windows to ARM.

What need to happen for the Windows transition to happen?

Looking at the above analysis, my conclusion is that for Windows to transition to ARM, there needs to be a market independent of PCs where the demand for high-performance ARM chips is strong. This market has to be big enough to fund the development costs to bring features like powerful GPUs and Unified Memory to the SoC. One candidate is the datacenter. If this happens, and ARM delivers performance that is very significantly ahead of Intel, then the market might be convinced that ARM is the future. Both Microsoft and software developers will start to take ARM seriously, and as a result we will have better emulators and more native code. This in turn will convince consumers that it is safe to buy these new devices.

Intel will also have to stand still. Intel is no slouch in incorporating technologies onto its platform, and CISC is no longer a fundamental disadvantage since its current CPUs are RISC at the core. From a market demand perspective, you could argue that Intel has much better access today to the markets that would value the high-performance that the concepts in the Apple M1 would bring. For ARM to succeed, Intel will somehow have to forfeit this advantage.

Unfortunately, I cannot see either of these happening and my current conclusion is that it is highly unlikely that Windows will transition to ARM in a significant way, and that it is more likely that the x86 Intel architecture will improve dramatically by incorporating the concepts pioneered in the Apple M1, before non-Apple ARM can make major inroads into the market.

Running Windows on Apple M1

Craig Federighi on running Windows on M1 Macs;

As for Windows running natively on the machine, “that’s really up to Microsoft,” he said. “We have the core technologies for them to do that, to run their ARM version of Windows, which in turn of course supports x86 user mode applications. But that’s a decision Microsoft has to make, to bring to license that technology for users to run on these Macs. But the Macs are certainly very capable of it.”

To clarify, Craig is talking about quite a lot of things here.

  1. Microsoft currently only allows Windows on ARM to be pre-installed on OEM machines. The current license does not allow Windows for ARM to be run on Macs. This is not a limitation for Windows on Intel.
  2. If Microsoft allows Windows for ARM to run on Macs, then the idea is to use virtualization software like Parallels to run it. BootCamp will not be supported, so you cannot run Windows directly.
  3. Windows apps that have not been rewritten in ARM code will have to emulated or translated to run on M1 Macs. Rosetta 2 will not do this. Instead, emulation will be done by Windows for ARM. Unfortunately, from what we know, emulation performance of the Windows solution is nowhere near that of Rosetta 2, and is most likely several times slower.

So yes, it is up to Microsoft allow Windows to run on Apple M1 Macs. However, Craig is not talking about running the Intel version of Windows. He is talking about the ARM version. Furthermore, with regards to apps that have not yet been recompiled for ARM, they won’t be translated using Rosetta 2. They will rely on the translation capability inside Windows for ARM, which at this point is far inferior.

By saying “that’s really up to Microsoft”, he is saying that Apple M1 Macs are the best hardware on which to run Windows on ARM, but it’s up to Microsoft to improve their software to make it a good experience.

CPU roadmaps from Intel and Qualcomm in the age of Apple Silicon

Dieter Bohn had this to say

It’s not difficult to dive into the future of Intel and even Qualcomm’s roadmap — they are consistent (and consistently dull) in their year-over-year improvements. Their customers are phone and laptop makers, so they need to be clear and transparent about what’s up. And I don’t see either pulling a step change like the M1 out of a hat.

Qualcomm’s roadmap most likely refers to the Snapdragon 8cx Gen 2, whereas for Intel it’s about Tiger Lake. Both promise solid improvements, but they aren’t M1-scale changes.

So anybody who had hoped that PCs might enjoy and ARM-based CPU with Apple M1-like performance will likely be disappointed, at least for the foreseeable future.

Which will prevail on PCs: x86 or ARM?

One possible side-effect of the Mac Intel to Apple Silicon is that WinTel PCs will also switch to ARM in the not-so-distant future. I want to spend a bit of time thinking about this.

Can Microsoft (or any other company) build a translation layer like Rosetta 2?

On the Vergecast, Walt Mossberg commented;

But the thing that really impresses me is their translation layer. This thing called Rosetta 2. They had a Rosetta when they made another processor change some years ago. And what it does is it takes apps that have not been written for this processor that were written for the Intel — which is most of the third-party apps so far — and it runs them. And I got to tell you, they run fast. They run normally. I mean, fast. If you were doing a blind test and you didn’t know this was originally written for Intel, still written for Intel, and it was running through this Rosetta thing, you would never know it. At least that’s been my experience. I don’t know if it’s been yours.

Indeed, as I have noted, benchmarks show that Intel code translated with Rosetta 2 achieves 78-79% of the performance of native code, which is an enormous leap forward compared to the Intel emulator that is on Windows for ARM.

This suggests that Microsoft is far, far behind today, and that it will take a large engineering effort to develop a Rosetta 2 equivalent.

Is there an inherent advantage in the ARM architecture that enables the performance in the Apple M1? Will any ARM silicon designed for PCs deliver similar speed?

Apple has shown that it is possible to develop an ARM instruction set based silicon that delivers great performance for desktop-style applications, whilst providing much superior battery-life.

One question is, does this mean that if Qualcomm or other ARM vendors create designs tailored to PCs, we will see the same kind of improvement? Is there a secret Apple sauce that is hard to imitate, or can other companies do the same? The second question is, does the ARM architecture itself have an inherent advantage, like, for example, RISC vs. CISC?

First of all, we know that Apple silicon for smartphones already significantly exceeded those from Qualcomm, Huawei, MediaTek and Samsung (Geekbench 1, 2). In single-core, the difference is almost two-fold. Therefore, we can safely conclude that Apple has had a secret sauce for many years.

Second, regarding any inherent advantages that the ARM architecture may have had over Intel x86. The consensus seems to be that although ARM had advantages for mobile usage in 1990, since then, due to the sheer increase in transistors per chip, the advantages today are mostly negligible (Quora 1, 2, 3). Apparently, the differences between ARM and x86 are due to whichever is the de facto standard in mobile or desktop, and access to the best manufacturing technology. The conclusion here is that ARM does not have an inherent advantage neither in battery-life nor performance, RISC vs. CISC notwithstanding.

If this is the case, then the real reason why Apple was able to get extremely good performance out of the ARM architecture is almost exclusively due to Apple’s secret sauce. Unified memory is obviously part of this, but there may still be other significant improvements.

It looks like, here again, a significant investment in time and resources will be necessary until we see similarly performing silicon from non-Apple sources.


On the software side, Microsoft will need to invest significant resources to improve their Intel on ARM emulator. What they currently have is very far behind. An alternative to this is for Windows application software vendors to diligently modify their software to run natively on ARM — Good luck with that.

On the hardware side, ARM silicon vendors will need to invest large efforts to design features on top of the basic ARM architecture.

Making both of these things happen is not going to be easy. 

The last time Apple made such a big leap was when they announced the iPhone, and that took about 4 years for Google to catch up with (Ice Cream Sandwich in 2011 is, in my opinion, the first time that they came anywhere close to iOS). This was mainly a software-only catch-up because at that time, Apple had just started using their own silicon (the A5) in the iPhone 4s, and hence CPU performance was similar to what you could elsewhere. It was totally up to Google alone to deliver.

This time, we need significant investments from both software and hardware, and no company owns both sides of the coin. Unless they see a future with a significant share of ARM-based PCs, application developers will not modify their apps. Microsoft will not develop a great emulator/translator unless silicon vendors can promise great performance. Silicon vendors won’t develop their own designs unless Microsoft makes a great emulator. Consumers won’t buy until they can run their apps with good performance. We are seeing a chicken and egg problem here, and this is because of how the non-Apple value-chain is divided. This is what has plagued Microsoft’s ARM efforts so far and even with the announcement of Apple’s M1, I don’t see this moving forward. Indeed, we have seen a similar picture with Android smartwatches.

Given this market dynamic, a much more feasible scenario is that Intel will fix their process woes and develop a great x86 mobile chip by today’s standards at 7nm or similar. ARM from other vendors won’t push x86 out of the market and may well be stuck in the same state as today. No revolution — just evolution. Apple will not come after the server market, the corporate PC market, the gaming PC market, nor the low-end market. Macs will gain some market share, but the damage will be restricted to the limited markets where it competes. Intel should focus on creating better chips than AMD and shouldn’t be distracted by Apple’s M1.

The Itanium fiasco provides us with a good idea of how things will work out here. With a segmented value-chain, there is a huge inertia toward sustaining evolution and that’s probably what we’ll see here.

My conclusion. It seems that despite its recent failures, market dynamics still strongly favour Intel and it will end up being on the winning side this time.


Update 2-Dec 2020

A story appeared on PC World noting the absence of any mention of Qualcomm chips that can compete with Apple M1 during the Snapdragon Tech Summit.

Trying to Understand the Apple M1 CPU Situation and Influence

Some thoughts. I will continue to add small snippets as they come into my head.


Will it be possible to run Windows on M1 Macs?

We currently know that Parallels will be coming to the M1 Macs. We also know that the x86 version of Parallels cannot be emulated on Rosetta 2. The version of Parallels demoed at the Apple event was running an ARM version of Linux. Additionally, the ARM version of Windows will soon gain the capability to run x86 64-bit code through an emulator. Connecting these dots together, it should be technically possible to run the ARM version of Windows inside of Parallels, with 64-bit x86 code running under the emulator provided with Windows. Unfortunately, we also know that the current version of the x86 emulator on Windows runs several times slower than native code, unlike Rosetta 2 which can run translated code at 70% of the performance of native. Putting this all together, it seems like we should see Windows for ARM running on the Apple M1 Macs under Parallels. However, x86 code will run slowly and will not benefit from Rosetta 2. On the other hand, it should still be much faster than running x86 code on a Surface Pro X with an SQ2 processor, which clocks about 4x slower that the Apple M1 on Geekbench.


Will x86 Windows run in Rosetta 2?

The current information suggests no.


Will companies like Qualcomm, Samsung, Huawei, etc. develop ARM silicon on par with the Apple M1 in terms of performance?

No doubt, there will be some efforts made. However, it ultimately boils down to focus, which I suspect may be lacking. Unlike Apple, Microsoft is very unlikely to fully commit to the ARM architecture. They will always keep x86 around. This makes it much less likely that Microsoft will develop a translator as good as Rosetta 2. PC vendors like Dell, HP and Lenovo are also very unlikely to ever commit to converting their whole line-up to ARM, and will most likely continue to use x86 for the majority of their products. Given this situation, I predict that instead of somebody developing ARM silicon on par with the M1, it is much more likely that Intel will manage to develop a CPU that keeps the ARM manufacturers at bay.


So why was Apple able to pull this off?

I think the key is focus. 


How does Vertical Integration play into this?

Apple is a vertically integrated company, and many people attribute the success of the M1 to this. However, it is important to note that for Apple to manufacture the M1, modularisation happened as well. For example, the ARM licensing scheme allowed the instruction set to be separated from chip design. Apple also chose not to own their own foundries unlike Intel which is vertically integrated in this dimension. This created a level of modularity compared to Intel, which made it possible for Apple to integrate chip design with their hardware and software. The level of integration across the value chain in total may not have changed much, and hence it is too simplistic to say that vertical integration is what enabled the performance of the Apple M1.


Will Apple sell the M1 to third parties?

This is very unlikely, but is interesting as a thought experiment. If Apple sold the M1 to Microsoft, for example, it should be possible to create a much better Surface Pro X. Looking at Geekbench scores, the M1 is several times faster than the SQ2 in the Surface Pro X. This means that the M1 is not a success because of vertical integration, and that it would probably be (almost) just as successful outside of Apple’s walled garden.


Would the Apple M1 have been possible without vertical integration?

For the Apple M1 to exist, both modularisation of the instruction set from the chip design and modularisation of the chip design from the foundries had to happen. In this sense, one could just as well say that modularisation had to happen as a prerequisite for the M1.


Then why can’t Qualcomm create silicon that is as fast as Apple’s?

This probably has more to do with scale than anything else. Apple can invest in creating the very best silicon from a performance perspective, with the knowledge that it can sell all that it can make. Qualcomm is not that fortunate. Android does not sell as well in the high-end as iPhones, and Qualcomm also has to sell a lot of chips for the mid- to low-tiers as well. It cannot put as much resources on the high-end because its high-end doesn’t have as much scale as Apple’s. This is similar to the situation with the S-series chips for Apple Watch. Apple can invest in silicon tailored to smartwatches because it can sell them at scale. Qualcomm can’t.


Is this disruption?

This is classical disruption. However, disruption is a long process and did not start with the M1 — M1 is where it (almost) ends. Disruption started with mobile, when mobile processors were toys compared to PCs. Mobile improved much faster than desktops until we reached the tipping point in the M1. The M1 is the beginning of the end.


Will x86 survive?

I believe, yes. If there is one thing that the history of computing and the resilience of mainframes and computing languages like COBOL teach us, it’s that legacy systems and programs live on far longer than we would ever imagine. The popularity of x86 programs and systems is so massive that the inertia is much too high for x86 to simply die out. I believe that Intel will quickly be able to improve x86 performance with a combination of better process technologies and also by stealing some of the architectural ideas in the Apple M1. This is after all, how Pentiums won over the RISC threat. 


Who will be the ARM processor king for PCs?

Given that Apple is unlikely to sell the M1 for use by other vendors in their PCs, somebody else will need to fill that gap and manufacture good ARM silicon for the future generation of PCs. It could be Qualcomm, Samsung, MediaTek, AMD or somebody we have yet to hear of. This is very hard to predict, but I would put my money on MediaTek simply because I think they have the least to lose and the most to win. Of course, this depends on whether or not PCs actually do transition to ARM, which I’m not optimistic about.


Will this accelerate the transition of Windows to ARM?

I doubt that it will be that easy. I’ll try to break it down here. First of all, the Apple M1 chip seems to be about twice as fast as any ARM chip out there in single-core performance, if the results on Geekbench are any indication. Secondly, whereas Rosetta 2 only causes a 30% decrease in performance compared to native code, Windows x86 emulation on ARM is several times slower. Therefore, in order for a serious transition of Windows to ARM to begin, Windows x86 emulation on ARM must dramatically improve, or a large number of apps have to be modified to run natively on ARM, neither of which seems particularly likely. Even then, it is likely that Windows on ARM will still lag behind Windows on Intel simply because ARM chips are far behind the M1. So no, I don’t expect a transition of Windows to ARM in the foreseeable future. Instead, I think small improvements in x86 like moving to a 7nm process will be sufficient to keep Windows on ARM relatively unattractive.


What about the long-term?

Will Windows on ARM win over Windows on Intel in the long term? The answer is in business models. Intel has a very strong incentive to improve x86 chips to maintain dominance over PCs running Windows. The same can be said for AMD. It is better for AMD to invest in x86 and to split the market with Intel, rather than to compete with a large number of potential ARM manufacturers. Qualcomm, Samsung and MediaTek can focus on ARM since they, do not have any competing interests in CPUs for PCs, but need much more commitment from Microsoft on bringing Windows to ARM. Microsoft on the other hand doesn’t have a strong incentive to make Windows on ARM equal to or better than Windows on Intel, especially when the ARM chips aren’t there yet. It reminds me of the situation before Apple transitioned to Intel, when both IBM viewed PowerPC Mac laptops as not important enough to prioritise development, instead optimising for their own servers. Qualcomm, Samsung and MediaTek will prioritise smartphones running Android and not PCs running Windows. Microsoft in turn will prioritise PCs on Intel instead of ARM. Unless something even more drastic that the Apple M1 chip happens, I doubt that we will see a coordinated effort between hardware and software. In the meantime, I expect Intel to get back on its feet again and reinstate the old order, even if Windows on Intel may never achieve the efficiency of MacOS on Apple silicon.

Rosetta 2 vs. ARM Windows x86 Emulation

Benchmarks of Rosetta 2 emulating x86 on the Apple M1 chip have been revealed, and it looks like it achieves 78%-79% of the performance of native Apple Silicon code.

Although not a strict comparison, the same cannot be said for Windows on ARM when emulating x86 code. One benchmark showed that emulation performed 3x-8x slower than native code.

When we look at what Apple has achieved in preparation for their transition to ARM, one the one hand we see the phenomenal performance of the Apple M1 chip. On the other, we see the amazing performance of Rosetta 2. Although Rosetta 2 is a temporary stopgap solution that may only be supported for a few years, the technology is nonetheless just as impressive as the M1. It is the combination of these two amazing proprietary technologies that will most likely make the transition of MacOS on Intel to ARM nothing like that of Windows.