A Microsoft engineer who led the effort to bring Python and machine learning libraries to Windows on Arm explains why some corporate software still has no Arm versions and how companies can prepare for the switch
Windows devices with Arm processors are attracting more buyers. According to Microsoft, the platform has grown into a full ecosystem that covers the core needs of everyday work, and the Works on Windows on Arm catalogue now lists over 8,000 apps and games. The list includes finished, verified programs, which is enough for an individual user and falls short for a business. Many corporate solutions and analytics and machine learning tools still have no Arm version. Companies have to run such programs through Prism, the x64 emulation layer in Windows 11, and lose the advantages that make Arm laptops worth buying. As a result, a company faces a choice: upgrade now and live with emulation, or wait until vendors release Arm versions.
Analytics Insight spoke with Gleb Khmyznikov, a Senior Software Engineer at Microsoft, about what keeps developers from releasing Arm versions of corporate software. He prepares the Python stack for Windows on Arm and leads a cross-team project to bring popular Python and machine learning libraries to the platform, coordinating it with engineers at Arm, Qualcomm, Nvidia and Linaro. Khmyznikov explained which tools already run natively on Arm, how porting software to Arm works, and what developers and companies should do.
Python Under Emulation
For analytics teams, the move to Arm laptops runs into the tools their daily work depends on. Many of them are written in Python, the main language of data analysis and machine learning, and on a new device Python goes through a quiet substitution. A developer installs the familiar x64 Python, the Prism emulation layer translates the code on the fly, packages install and programs run. From the outside, everything looks fine. However, the emulated program runs slower than it could, and as long as the code runs, nobody tells library authors about the gap, so it stays open. Khmyznikov ran into this while working on bringing machine learning libraries to Windows on Arm at Microsoft. To measure the scale of the problem, he carried out a study that the Universal Library of Engineering Technology published in December 2024.
"Developers judge a platform by whether pip install finishes," Khmyznikov says. "Under emulation it usually does, so the real picture only appears in comparison. I ran the same tests on a Snapdragon X Elite laptop in native Python and in x64 Python under Prism, then installed every popular package three ways: natively, under emulation and on a regular x64 machine."
Khmyznikov found that native Python ran almost 23% faster on average than x64 Python under Prism, and interpreter startup improved by 95.7%. In the same study, he checked the 1,000 most popular Python packages. By september 2026, about 96% of them supported Windows on Arm natively or did not depend on the processor, among them NumPy, Pandas, Matplotlib and ONNX Runtime. The remaining 4% are harder, because porting to Arm moves along a chain: first the low-level packages, then everything built on top of them. Only a package's author can fix it, and some maintainers have no Arm hardware or budget for an ARM64 build pipeline. To get the chain moving, Khmyznikov drew up a priority list of libraries and a validation suite that tests each one in all three modes. With it, Microsoft and its partners saw which packages blocked native work and began closing the gaps in order. As a result, the number of Python libraries with native Arm builds has grown over the past year, and Microsoft has planned to move the Python environment for Windows on Arm from experimental to stable status.
Two Compilers
Many Python libraries rest on code written in C and C++. NumPy and the CPython interpreter itself are written in these languages, as are many corporate programs for Windows. Porting such code to Arm depends on more than ready dependencies, since it also requires a choice of compiler. On Windows on Arm, teams build it with two toolchains, Microsoft's MSVC and the open-source Clang/LLVM, and have to choose without knowing in advance which one will give the better result. Khmyznikov examined this choice in a study that The American Journal of Engineering and Technology published on 30 April 2026.
"Switching compilers looks like changing one flag, and in a large Windows codebase it turns into manual rewriting of platform-specific code," Khmyznikov says. "Clang still lacks some MSVC intrinsics, and link-time optimization and exception handling need extra work. So I compared both compilers on real projects and two generations of Qualcomm processors to see when that work pays off."
For the comparison, Khmyznikov took four open-source projects: the LAME audio encoder, NumPy, the x264 video encoder and the CPython interpreter. He built each with both compilers and ran them on a Snapdragon 8cx Gen 3 with Kryo cores and a Snapdragon X Elite with Oryon cores. Clang/LLVM won most tests. CPython built with it ran faster in 14 of 15 benchmarks, and NumPy sorting on Oryon took 25.76 ms against 62.58 ms with MSVC. Square roots in NumPy, however, took both compilers about the same time on Kryo, while on Oryon MSVC finished 3.4 times faster. That means no one can name the winner in advance, since the outcome depends on both the task and the processor generation. Khmyznikov therefore treats Clang/LLVM as a reliable default, but for math-heavy software and new Qualcomm chips he advises deciding only after measuring your own workload on the target processor. Switching compilers takes a lot of manual work, and measurements keep that work from going to waste.
The study's main conclusion concerns the platform itself. Both compilers already build code for Windows on Arm, and the choice between them determines how fast a program runs, with compatibility no longer the main question. In Khmyznikov's assessment, the platform has reached maturity. For a company, this means its C and C++ software can move to Arm now, and the payoff depends on how much time the team invests in measurement and tuning.
Betting on Arm
Manufacturers are investing more and more in Arm. This autumn Microsoft released a new Surface Pro and Surface Laptop on Qualcomm’s Snapdragon X2, and on 7 October it opened preorders for the Surface Laptop Ultra, built on Nvidia’s new Arm chip RTX Spark, with shipments starting on 16 October. ASUS, Dell, HP, Lenovo and MSI also are bringing their own RTX Spark devices to market this autumn. One of the main arguments for such devices is the built-in neural processing unit (NPU) for AI tasks, which on Snapdragon X Elite delivers up to 45 trillion operations per second. An NPU alone does not guarantee a speed-up, though. In Khmyznikov's tests, a model on the NPU sometimes ran slower than on the regular processor if nobody had tuned the drivers and software stack to its architecture. Khmyznikov covers this part of the chain at Microsoft as well. He wrote the "ML ARM DX State" reference, which the company's teams used to set AI-on-Windows priorities and decide which libraries to port with partners. With its help, they moved workloads such as PyTorch from emulation to native execution. He also brought the Olive and ONNX Runtime teams together with engineers from Arm and Qualcomm to unblock the libraries the platform needs for AI.
"Arm devices already handle everyday work, and the number of Arm builds keeps growing, so waiting until everything runs natively makes no sense," Khmyznikov says. "An IT department should start with the dependency list of its own software. Browsers, messengers and mainstream office apps already run on Arm, and the risk sits in in-house tools and the scientific stack. A pilot on a few Arm machines with real workloads will find it faster than any compatibility chart."
The switch can happen gradually. A company does not need to wait until all of its software has Arm versions. It can port the most heavily loaded parts of its internal software first and leave the rest under emulation for a while, as library authors release their builds. Khmyznikov proposed this order back in his 2024 study. Chipmakers and PC manufacturers keep investing in the platform, the catalogue of native software is growing, and a company that starts with a pilot and a review of its software now can fit the switch into its regular hardware refresh cycle.