The Arm development ecosystem is ready

I have been keeping a close eye on the Arm software and hardware ecosystem for sometime and it is clear that we are at watershed moment. Given what we know about the M class of processors there is a lot to be gained from Arm in terms of ratio of power and watts. However, on Windows that calculation is less useful because of the raw power on the prior generation of devices was relatively low and, just as frustrating, was the lack of support for tooling and frameworks.

Microsoft’s Developer Division set out a few years ago with the short-term goal of reducing the friction for Windows developers on Arm, with an overarching long-term view of making the experience identical to the x64 equivalent. To meet that long-term goal, we needed to do way more than just make Visual Studio and .NET run natively on Arm64, we had to ensure that we promoted establishing a healthy and self-sustaining Arm software ecosystem for Windows on Arm (WoA).

To do this well we needed three things.

A chipset to compete with x64 on raw power, and simultaneously with M-series on efficiency.
Emulation that was good enough to allow x64 apps to run on Arm hardware.
Multiple improvements to ecosystems.

Well we certainly got the hardware!

We also have some strong assurances that the Qualcomm's Snapdragon X Elite will run Windows games 'just fine' using x64 emulation. The preference from a cost per watt perspective is to port the games to native Arm64, however, the option of doing nothing may result in perfectly reasonable performance (if not efficiency).

Certainly as it relates to the ecosystem there is a lot of work being done to tools and frameworks like LLVM, Flang, Python, Qt, CMake and dozens of other projects are now supported for WoA. Linaro is doing a lot of work to create a healthy self-sustaining Arm open source ecosystem for Windows, you can track progress on this initiative here.

Visual Studio Arm64 improvements

One of the larges, roadblocks for Visual Studio on Arm64 has been removed, it now supports SQL Server Developer Tools (SSDT), as of 17.10 GA! However, one of the more subtle, but no less important, features we have been waiting to resolve was a a problem with .NET apps marked with AnyCPU.

What is AnyCPU? When a application is running in the .NET runtime it will look at the architecture of the OS and figure out what the application launch architecture should be. Visual Studio now natively supports building and debugging Arm64 apps on Arm-based processors. Due to our obsession with backward compatibility and attempting to make the right choices for developers, applications built with the AnyCPU setting running on an Arm64 machine, will default to using x64 emulation. As we get closer to complete Arm64 parity this behavior is not what we want but a change like this would be considered a breaking change.

To better support the intended native behavior the Windows 24H2 update introduces a new setting for your app manifest files. Developers can include a list of supported architectures (amd64 or arm64), explicitly signaling that an application built with the AnyCPU setting should run natively using the Arm64 CLR on Arm64 devices.

Check out this talk from my good friend Jamshed where the team dive into the Next Generation of Windows on Arm. At long last I think we are ready.