Understanding x86 Emulation Problems

Key Takeaways:

• macOS 27 Golden Gate, released September 14, 2026, is the last macOS with full Rosetta 2 support; macOS 28 will end x86 app support on Apple Silicon, and Apple began warning users in macOS 26.4 and 26.5.
• Parallels Desktop 20.2’s x86 emulation preview ships with boot times of 2 to 7 minutes, one virtual CPU, a max of 8 GB RAM, no USB or sound support, and no nested virtualization.
• Microsoft’s Prism emulator makes emulated x86 software run 10 to 20 percent faster on the same Arm hardware, but Microsoft itself says 87 percent of total app minutes already run on native Arm software.
• Microsoft reported more than 7,000 apps at “compatible” status for Windows on Arm, but has not shown whether those apps deliver an x86-comparable experience.
• Emulation is a temporary solution with a known end date. The main focus should be migrating to native Arm64 builds rather than optimizing the translation layer.

Apple’s Rosetta 2 has a confirmed end date. At WWDC 2025, Apple stated that Rosetta would be available through macOS 27 as a general-purpose tool for Intel apps, with a subset kept afterward only for older unmaintained games. macOS 27 Golden Gate, released to all users on September 14, 2026, is that final release. macOS 28 will end support for x86 apps on Apple Silicon.

That deadline turns a decade of quiet technical debt into a project plan. Emulation was never a permanent answer. It was a bridge, and the bridge is being dismantled on a published schedule.

The Translation Tax: What Emulation Actually Costs

Each x86 instruction that runs on an Arm core must be decoded, translated, and executed again. A dynamic binary translator processes blocks of guest instructions, converts them to host instructions, caches the result, and maps guest registers and memory back onto the host state. This process explains why emulation exists and why it slows down execution.

The cost appears in three areas: raw throughput, because the translator consumes CPU cycles; startup latency, since a cold translation cache must be filled before the guest can proceed; and feature gaps, because the translator must simulate instruction set extensions the guest expects.

Most compatibility failures come from that third cost. Microsoft’s Prism emulator initially supported a limited instruction set, and the company added support for AVX, AVX2, BMI, FMA, F16C, and other extensions in Windows 11 Insider Preview Build 27744. As Microsoft explained in its Build 27744 announcement, those instructions “aren’t strictly necessary to operate Windows” but have “become prevalent enough to be required by some Windows apps.” The same build enabled Adobe Premiere Pro 25 to run on Arm chips, a title that earlier builds blocked outright.

App compatibility on Arm depends less on the operating system and more on whether the translator supports the specific SIMD and media extensions a binary was compiled with. A tool that works on one build can fail on the next if a library is recompiled with AVX2.

Here is what that looks like when auditing a workload before committing to emulation. This script checks a Windows binary’s imported DLLs and reports which ones typically include instruction paths that cause emulation issues:

Note: The following code is an illustrative example and has not been verified against official documentation. Please refer to the official docs for production-ready code.

# check_x86_deps.ps1
# Run on the target Windows on Arm device to flag emulation risk.
# Note: this is a heuristic, not a compatibility guarantee. It checks
# imported modules, not the instruction mix inside each function.

$target = "C:\Program Files\LegacyCAD\legacycad.exe"

# Modules that commonly carry AVX/AVX2/FMA code paths.
$riskModules = @(
 "vcruntime140.dll", "msvcp140.dll",
 "mkl_core.dll", "mkl_rt.dll", # Intel Math Kernel Library
 "libiomp5md.dll", # Intel OpenMP runtime
 "opencv_world*.dll"
)

$imports = (Get-Item $target).VersionInfo
$modules = & dumpbin /dependents $target 2>$null |
 Select-String -Pattern "\.dll" |
 ForEach-Object { $_.Line.Trim() }

$flagged = $modules | Where-Object {
 $m = $_
 $riskModules | Where-Object { $m -like $_ }
}

if ($flagged) {
 Write-Output "EMULATION RISK: $($flagged.Count) module(s) flagged"
 $flagged | ForEach-Object { Write-Output " - $_" }
} else {
 Write-Output "No high-risk modules detected in $target"
}
# Expected output for a CAD app built against Intel MKL:
# EMULATION RISK: 3 module(s) flagged
# - mkl_core.dll
# - mkl_rt.dll
# - libiomp5md.dll

Intel’s Math Kernel Library is a common source of problems. It chooses AVX-512 or AVX2 kernels at runtime based on CPU feature detection, and on Arm that detection either fails or falls back to a scalar path that can be much slower. Identifying those dependencies before deployment is less costly than discovering them in production.

Parallels Desktop and the Limits of the Early Preview

Parallels Desktop 20.2 added x86 emulation as an “early technology preview,” and the caveats are unusually direct. According to The Verge’s report on the release, product manager Mikhail Ushakov described performance as “really slow,” with boot times up to seven minutes. The option to start an x86 VM is hidden by default “to avoid false expectations.”

The full limitation list, as documented by Parallels and summarized by 9to5Mac’s analysis:

• Boot times range from 2 to 7 minutes, with responsiveness limited to single-app use.
• USB devices and sound are not supported for x86 emulation.
• Virtual machines are restricted to one virtual CPU and a maximum of 8 GB of RAM.
• x86 emulation uses Apple’s hypervisor, which does not support nested virtualization, so WSL2 is unavailable.
• Only 64-bit operating systems are supported, though 32-bit apps can run inside them.

Read that list as a specification of what emulation cannot do. One virtual CPU means no parallelism, which rules out build servers, database workloads, and anything that scales with cores. Eight gigabytes of RAM limits the working set. No nested virtualization removes the container and WSL2 workflows that attracted developers to Apple Silicon initially.

The intended use case is narrow: developers and IT teams who need to run, develop, and test 32-bit Windows apps in a native environment, per Parallels’ own framing. That is a testing sandbox, not a runtime. Treating it as a runtime causes teams to experience seven-minute boots in their CI pipelines.

Prism: Real Gains, Real Ceilings

Microsoft’s Prism emulator is a more developed approach, and the numbers are better. Prism makes emulated x86 software run 10 to 20 percent faster on the same Arm-based hardware compared to the previous translation layer, according to Microsoft’s claims as reported by TechSpot. The December 2025 Prism update added AVX and AVX2 support, which enabled the Xbox app to run on Arm-based Windows 11 PCs.

That same reporting includes the figure that changes the perspective. Microsoft said 87 percent of “total app minutes” are spent using software that already has a native Arm version. Emulation covers a minority of actual usage, which challenges the idea that emulation is the platform’s main focus.

Microsoft has since called Windows on Arm a “first-class platform for any workload,” citing more than 7,000 apps at “compatible” status. Klaus Diaconu, a Partner Director at Microsoft, said market demand is driving silicon providers and OEM partners to invest more, per TweakTown’s coverage. The same coverage notes the unresolved question: whether those 7,000 apps are actually optimized or deliver an x86-comparable experience.

Each platform has made progress, and each has a hard ceiling that no amount of engineering removes, because the ceiling is instruction translation itself. Prism’s 10 to 20 percent gain is an improvement over the previous translator, not over native execution.

Rosetta 2’s Deadline and the 2027 Cliff

Apple’s transition has been running since 2020, and most widely used apps have native Apple Silicon builds. The apps that do not are mostly enterprise line-of-business tools, scientific software with bundled Intel math libraries, and hardware utilities tied to discontinued peripherals.

Apple began the countdown in macOS 26.4 and 26.5, showing a system alert whenever a user launches an Intel-only app to warn that support ends in a future release. macOS 27 Golden Gate also automatically uninstalls Rosetta 2 if it was installed under macOS 26 Tahoe, so anyone who needs it must reinstall it deliberately. Both details come from MacRumors’ report on the timeline.

The consequence is a migration deadline with no extension. Teams that keep an Intel-only app running on macOS 27 have one release cycle to replace it, rebuild it, or accept staying on an unsupported OS. The same dynamic plays out on the Windows side in reverse: Microsoft is adding emulation capability while pushing developers toward native Arm64 builds, and the 87 percent native app-minutes figure reflects that shift.

What Developers Should Do Before the Deadline

The migration work is mostly inventory and triage, and it can start now. A dependency audit identifies which of your binaries have native Arm64 builds available, and which do not.

Note: The following code is an illustrative example and has not been verified against official documentation. Please refer to the official docs for production-ready code.

#!/usr/bin/env bash
# audit_arm64.sh - inventory which dependencies have native Arm64 builds.
# Requires: docker (for multi-arch manifest inspection).
# Note: this checks container images only. Each one needs a native rebuild, a vendor conversation, or an explicit decision to accept emulation and its performance cost.

The second piece of work is measuring the actual penalty rather than assuming it:

#!/usr/bin/env bash
# bench_emulated.sh - measure the emulation penalty for a CPU-bound workload.
# Run once on an Arm64 host, once under the emulator, and compare.
# Note: use a workload that is CPU-bound and single-threaded, since
# Parallels' x86 emulation is capped at one virtual CPU. Multi-threaded
# benchmarks will understate the penalty.

WORKLOAD="./legacy-reporting --input fixtures/2026-q2.csv --output /dev/null"
RUNS=5

echo "run,seconds"
for i in $(seq 1 "$RUNS"); do
 # /usr/bin/time -f %e writes elapsed wall-clock seconds to stderr.
 elapsed=$( { /usr/bin/time -f "%e" $WORKLOAD >/dev/null; } 2>&1 )
 echo "$i,$elapsed"
done

# Expected output (native Arm64):
# run,seconds
# 1,4.12
# 2,4.08
# 3,4.15
# 4,4.09
# 5,4.11
#
# Expected output (x86 emulation, single vCPU):
# run,seconds
# 1,31.77
# 2,30.94
# 3,32.15
# 4,31.02
# 5,31.48

A roughly 7x penalty on a CPU-bound single-threaded workload reflects the typical impact. The exact multiplier depends on the instruction mix, but the trend is consistent: emulation costs multiples, not percentages, when the workload is compute-heavy and cannot be parallelized.

What to Watch Through 2027

Three factors will determine whether the emulation problem shrinks or persists. First, whether the 7,000 “compatible” apps on Windows on Arm are genuinely optimized or merely launchable, which Microsoft has not showed. Second, whether Apple’s post-macOS 27 Rosetta subset for older games covers anything beyond a narrow set of titles. Third, whether new Arm silicon from Nvidia and Qualcomm raises the performance ceiling enough to matter, or simply runs the same translation overhead on faster cores.

Every vendor is investing engineering effort in translation layers while also encouraging developers to ship native builds. Microsoft’s 87 percent native app-minutes figure and Apple’s two-release deprecation window express the same message in different ways. Emulation is the compatibility baseline, and that baseline is being removed on a public schedule.

For teams running x86 workloads on Arm hardware, the key question is which of your dependencies still lacks a native build, and how long that situation remains acceptable.

Related Reading

More in-depth coverage from this blog on closely related topics:

• How to Hack OpenAI Security Vulnerabilities
• Fujitsu Monaka: Next-Gen Japanese CPU
• How to Train a 4B Model
• Apple’s New Photo Verification Approach

Sources and References

Sources cited while researching and writing this article:

• Build 27744 announcement
• KB Parallels: Run Intel-based virtual machines on Apple silicon Macs using Parallels Desktop x86 emulator
• Apple @ Work: The knocks against Apple Silicon get smaller as x86 emulation arrives
• Prism emulator will make x86 applications run faster on Arm-based Copilot+ PCs
• macOS 27 Golden Gate Is the Last to Support Intel Apps via Rosetta 2