Native Vs. Emulation: World of Warcraft Game Performance on Snapdragon X Elite
Key topics
The debate rages on: can a game like World of Warcraft run just as smoothly on native ARM64 as it does on emulated x86_64? The answer lies in a recent benchmarking test, which reveals that, surprisingly, the emulated version performs comparably to its native counterpart on Snapdragon X Elite hardware. Commenters weighed in on the feasibility of recompiling WoW for ARM64, with some pointing out that Blizzard has already done so, while others highlighted the non-trivial effort required to re-test and debug the entire game. As one commenter noted, releasing untested code is a risk, but it's a gamble that some developers might be willing to take.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
3h
Peak period
35
0-12h
Avg / period
11.6
Based on 58 loaded comments
Key moments
- 01Story posted
Dec 15, 2025 at 6:47 PM EST
19 days ago
Step 01 - 02First comment
Dec 15, 2025 at 10:10 PM EST
3h after posting
Step 02 - 03Peak activity
35 comments in 0-12h
Hottest window of the conversation
Step 03 - 04Latest activity
Dec 21, 2025 at 3:46 AM EST
13 days ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
But to answer your question as if they had not yet: it's never "just" recompiling. It's:
* recompile (and fix any warnings/errors indicated by the compiler)
* re-test ... the entire game
* fix the bugs that are encountered in test
* release/publish the game for Windows ARM64
Whatever this effort is, it's much much more than "just" recompiling. You could imagine motivated individuals on the engineering team chipping away at this list of their own accord. But following through with a product requires significant effort and coordination that often is weighed against the potential revenue that this new market could provide.
That seems a bit absurd. Surely many parts of the game won't likely have bits of code that interact with architecture in unique ways. Especially if you wrote the game in relatively portable code to begin with (as WoW almost certainly was).
I mean idk, maybe windows arm64 is a uniquely nasty target. But i'm skeptical.
https://news.ycombinator.com/item?id=46009962
WoW was released 21 years ago AFAIK
I came across a performance-killing bug that made the game unplayable (less than 1fps on a Mac Studio). It happened in a couple of dungeons (I spotted 2). From my tests it was caused by a specific texture in the field of view at a certain distance. There was no problem on Intel Macs, AFAICT. My old MBP was terrible but did not get any performance hit.
This is what can happen any time you don’t test even a tiny corner of the game. Also, bear in mind that this depends on graphics settings and you get a nightmare of a test matrix.
Surely that's a GPU thing and not an CPU thing, yea? Or was something about the texture processing architecture-dependent?
The core issue is that something slipped through the cracks. I don’t blame them, it’s a huge game and testing takes quite a lot of time. But testing does matter.
Windows on ARM isn't really the same ballpark. They were still there early, but the platform is still changing quite a bit.
Now WoW already supports Apple Silicon on macOS so most of that was already taken care of, but I'm betting there's a lot of Windows-specific code in there too.
Specifically, it's comparing the native ARM64 version against the emulated x86_64 version, both running on an ARM64 CPU.
Blizzard leans heavily on making sure their software is portable!
Never tested myself as I'm more a runescape/ragnarok online sorta guy myself...
I think this is incorrect. Specifically the Windows ARM support. Official hardware support page indicates that the Windows version requires x64. I unfortunately don’t have the hardware to confirm for myself. But Blizzard is the kind of company that would have made a blog post about that.
https://us.support.blizzard.com/en/article/76459
This is neat, and exciting that Windows emulation tooling is progressing! It seems like there’s a lot of work hardware vendors would need to do in order to make Win/Arm viable for game devs. I really wonder if that’s ever going to happen.
It has been around for a while, circa 2021. They made a forum post when they released it.
For reasons unknown the link no longer works but here it is on the wayback machine. https://web.archive.org/web/20210512205620/https://us.forums...
The high end model has a 192-bit memory bus, a 3 channel design. 12+6 cores but very big/big more than less big/little. 53MB L3 cache is quite healthy. 80TOps NPU (int8). 9533 MT/s 192-bit memory for 228GB/s which is nipping right at Strix Halo & Nvidia Spark's heels. 12x PCIe 5.0, 4x PCIe 4.0, and "3x USB-C" 40Gb/s (hopefully not some shared bandwidth cop out). And some kind of pretty big GPU. The specs here are quite promising.
And Qualcomm has started taking Linux drivers somewhat more seriously. Linux & mesa drivers are arriving now for previous Snapdragon X Elite & looking pretty promising. That said, this whole Device Tree world is hell, and never going to be good, and Qualcomm direly needs to get religion there & get some ServerReady type ACPI + UEFI compatibility standardized in the products, and stop OEMs from shipping these awful embedded-style non-PC things.
I'm excited to see ARM finally actually show up with something competitive. Alas though, those RAM prices. What a sad buzzkill, and man this is going to take forever to work out.
It’s the first Windows build with Prism and the first time they’ve introduced AVX(2) support, so I wonder simply if the performance isn’t there yet. I’ve found very little info online about this.
I'd expect more of a gain from enabling FMA, but that's assuming the program actually got built to use FMA -- it needs to either use it explicitly or have relaxations to allow the contraction. Oryon has 4 x 128-bit NEON pipes with 3c latency fadd and 4c latency fmul/fma, so it easily ends up latency bottlenecked unless there are plenty of independent calculations.
Not sure they care about it running in an emulated environment.
They do effectively allocate an executable memory region, copy the machine code that was streamed into it, and jump to it.
I guess in this case the emulation is an actual vm, rather than "rewrite x86 instructions into arm" (don't know much about this subject, but assumed that was how rosetta worked)
At least that's what I gathered around the time it was released. It seems to hold up; JITed x86 applications work great under Rosetta 2.
Mass mobs combat in Karazhan is a pretty good raid tester - in raids, the FPS won't be as low as that (AVG), but the 1%/0.1% lows will be quite close. For systems with weaker and weaker CPUs, even the AVG FPS will come closer and closer as the game will get a single-core "world state" bottleneck more easily. I did some comparison benchmarks before for this, including a world boss world quest with lots of people ;)
Also, regressions in WoW are a nightmare to handle. You go to the latest raid, the FPS is fine, but someone next to you has a slideshow.
All I want is something like a Macbook Air, but running Linux - long battery life, acceptable performance, an OS that respects me.
Funnily enough, the device with probably the best "normal" desktop protocol support is the old Windows RT tablet, which features an ARM SoC that runs UEFI and ACPI and everything. It's locked down to Microsoft's secure boot keys, unfortunately, but thanks to Microsoft abandoning the device, there are exploits you can use to bypass that.
So now we have a world full of devices running open software but which are locked down. And a Linux foundation run by corporates.
To me it is clear this was indeed a huge problem. Linux might not have become as big as it is now if it had taken GPL3 on board but it would have made it a lot harder for manufacturers to do what they're doing.
It should have, IMO. Because now we're stuck with all these locked devices. Even PCs are becoming more locked now. FOSS (at least on the OS level) can't really exist without open devices to run it on. Otherwise you're dependent on the gatekeepers of big tech and there's nothing 'free' about it anymore then.
Maybe, but even if they wanted to, it would be almost impossible. In Linux, the license of contributed code says "GPLv2", period. Not "GPLv2 or higher" like a lot of other projects do. If you are not the rights holder, you can't "re-license" a piece of GPLv2 code as GPLv3 as you could with for example a BSD license piece of code. Simply because the GPLV2 is too restrictive. So that would mean getting in touch with all current and past right holders / contributors (and maybe even people who inherited the rights of contributed code if the contributor passed away?) and get permission to re-license to GPLv3.
QCOM in this case probably could make a standard ARM PC. The problem will be QCOM corporate structure will probably strangle it. They will want to create a patent license stream. The interesting bits would be behind NDAs. It is their bread and butter.
The reality is no one wants to be IBM in the IBM/PC clone market. Basically the ones who did the expensive work to make the board but everyone just copies it.
It’s not their fault per se, but it’s discouraging.
Though I am not skeptical of the authors methodology, I do suspect that the ARM64 build of WoW may not be as "optimized" as the x64 build. This is because in some of his workloads the emulated game actually outperformed the native game.
Besides, I'd look forward to testinf with the nea ARM emulation layer Valve is developing.
Also curious if Battle.net client has the same bug as Apple Silicon where it consistently needs to run a game "update" after closing the game. The client is still x86 even on macOS so I'm wondering if this is an translation issue that could be fixed with a proper native client.