The Nintendo Switch emulator suyu has added a Recompiler mode (static recompilation mode) to 0.04, its final public release. It reportedly converts Switch AArch64 game code ahead of time into x86-64 executables, the format widely used on PCs. The approach moves part of the heavy work to before launch, rather than translating instructions while the game runs, as the conventional method does.
Wccftech described this as a leap toward "native" PC performance and suggested it could reduce CPU load and stutter during shader compilation. The mechanism is promising. But suyu's public documentation only confirms what the feature does, and it contains no figures measuring a speedup. What needs to be separated now is the theoretical advantage of static recompilation from the performance suyu 0.04 has actually achieved.
This Is Not a "Native PC Version"
Suyu's README divides the ways of running a game into two. The conventional emulation mode handles the GPU and CPU, as well as audio and services, in suyu's core. The new static recompilation mode converts AArch64 game code into an x86-64 executable ahead of time and combines it with suyu's HLE (high-level emulation infrastructure).
The key word in that description is "combines." Converting part of the game code the CPU runs into x86-64 does not turn the Switch's runtime environment into Windows or Linux. The game still calls Switch OS services and runs on its own assumptions about memory layout and synchronization. The commands it sends to the GPU also have to be bridged to PC-side APIs such as Vulkan. Input, audio, and timing management remain as well.
So while the generated CPU code can be called "native" in the sense that it runs directly on the PC's processor, that is different from a native PC port of the whole game. In a conventional PC port, developers adapt the source code to another environment and rebuild everything from rendering to input and output. Suyu converts CPU code from the binary and handles the rest through the emulator's compatibility layer. There is room for it to be faster, but the emulation does not disappear.
JIT, Static Recompilation, and Direct Execution on ARM
The three approaches differ in when, and on which CPU, Switch instructions are handled. JIT, the common approach on x86-64 PCs, finds blocks of AArch64 code while the game runs, converts them into x86-64 instructions, and stores them. The first pass through a block incurs translation cost, but the work is limited to code that is actually used, and information discovered at runtime can feed into optimization.
Static recompilation moves that conversion to before execution. If the code is analyzed in advance and an x86-64 executable is built, the need to convert the same sections every time the game is played can be reduced. Because some of the work done by the runtime translator and code cache management is moved out, it may reduce CPU load and frame-time fluctuation. That much follows from the method itself. How large the effect is remains a separate question.
Yuzu's Native Code Execution (NCE) for Android is a different case again. Both the Switch and many Android devices use 64-bit ARM-family instructions, so the idea is to run the matching game code directly on the ARM processor without translating it into other instructions. An x86-64 PC cannot execute AArch64 instructions as they are. In suyu's static approach, translation is still required; it is just shifted earlier.
The 60–70% improvement yuzu reported in 2023 should not be conflated with this either. That figure came from running the 32-bit version of Mario Kart 8 Deluxe on an ARM64 host with Dynarmic's block linking enabled. It is not a measurement of suyu 0.04's AArch64-to-x86-64 static recompilation. Even technologies from the same emulator lineage cannot serve as evidence for each other's performance when the target CPU and the changes involved differ.
What Pre-Conversion Lightens, and What It Adds
If everything could be converted in advance, there would be less work at runtime. But a game's machine code is not always executed from top to bottom. With indirect branches, the destination is determined by values in memory, and some code may be generated or rewritten at runtime. It is hard to find every instruction a program will reach before it actually runs.
A static recompiler therefore has to decide how to handle paths it failed to find: fall back to a safe auxiliary mechanism, or stop as unsupported. At the boundary where Switch OS services are called, the original processing also has to be connected correctly to suyu's implementation. Not only the proportion of instructions that could be converted but also how often execution falls back to the auxiliary mechanism will determine actual speed and compatibility. Suyu's README does not disclose this scope.
The burden is not eliminated, either; it moves. Users wait for conversion before starting a game and need storage space for the output. If the code changes through game updates, DLC, or mods, a decision has to be made about how much to rebuild. JIT can convert only the paths a player actually runs, as they come up, whereas the static approach spends more time and storage the more code it reads before execution. Which is better depends on the structure of the game, the PC's performance, and how complete the implementation is.
Shader stutter is also not purely a CPU-code problem. Waits occur when a game's GPU shaders are converted for the PC and the driver builds the rendering pipeline. If the CPU-side execution path is known in advance, it may become easier to prepare for this, but suyu's documentation does not explain how much of the GPU side is preprocessed. It is not yet possible to say that static recompilation will also eliminate shader stutter.
Six Gaps Between "Should Be Faster" and "Became Faster"
Suyu 0.04's public documentation lacks six kinds of measurement information: comparative FPS, frame times, test PC specifications, a list of supported games, conversion time, and size of generated files. This is the result of checking, item by item, what a third party would need to independently verify performance and compatibility, based on the full text of the official README retrieved on September 15, 2026. Data may exist outside the README or in later forks, so its absence does not prove the feature doesn't work.
Average FPS alone is not enough, either. To discuss JIT translation load and stutter, frame-time distributions need to be compared using the same game, scene, PC, and settings. Even at the same average, an operation feels better if long frames are reduced. Conversely, if the game halts because of missed conversions, a higher average FPS does not make the speedup complete for the user.
A list of supported games defines the scope of the effect. A handful of titles booting is different from a complex blockbuster being playable stably for long sessions. How many minutes pre-conversion takes and how many gigabytes the output occupies are also costs traded against runtime speed. Moreover, even for the same game, code differs across updated versions and DLC. Unless versions are fixed, the comparison results cannot be reproduced.
Wccftech predicted that mid-range PCs and open-world titles would benefit, but its article contains no comparison table or test procedure. What can be confirmed at present is that a promising design has been published. How much faster it is, and on which PC, cannot be confirmed.
The Value of a Final Release, and Verification That Has Stopped
Suyu 0.04 comes with difficulties beyond performance evaluation. The project treats this as its final public release and has archived the repository. The README says no further development or downloads are planned. It lists builds for Windows, Linux, and Android, while macOS and iOS are out of scope. Right after the new method was published, official improvements and bug fixes have stopped.
User reports also offer a clue that reproducibility has not been established. In suyu's user community, a post asked for working examples after a game tried with static recompilation crashed. Another user pointed to a later fork. However, PC configurations and builds were not controlled, and game data and settings are unknown, so this cannot be taken as suyu's overall failure rate.
Even so, it is no small thing that a design for building static recompilation into an existing Switch emulator and connecting it to a high-level emulation infrastructure has been made public. If the code remains as an archive, later developers can widen the range that can be converted, refine the auxiliary mechanism, and accumulate measurements. Rather than a finished product, v0.04 is a verifiable starting point.
Whether this method has reached a stage that can be called "native performance" can be judged by frame times, CPU usage, pre-conversion time, compatibility rate, and the rate of fallback to the auxiliary mechanism, all measured under the same conditions. If those measurements confirm improvements in speed and stability, and the same results can be reproduced even on low-cost PCs, static recompilation will become a practical option rather than a selling point.