The Cheapest Compute on Earth Is the Compute You're Already Wasting

TL;DR: A 3-day experiment using an AI-driven iteration loop made Snes9x, a 25-year-old SNES emulator on millions of devices, 61.2% faster on x86-64 and 52.3% faster on arm64. Every frame and audio sample is bit-exact against the unmodified original. Total AI model cost was under $30. The performance was never in a new chip. It was sitting idle in code that everyone considered finished, and the only thing that changed was the cost of finding it.

The Assumption Nobody Questions

Every conversation about AI in 2026 seems to end at the same place: we need more. More data centers, more chips, more power. The assumption underneath that is so old nobody questions it anymore. If you want software to do more, you buy more hardware.

This post describes a small experiment that points the other way. It involves a Super Nintendo emulator, a couple of ARM handhelds, and a question I could not stop asking: how much of the hardware we already own is executing work that does not need to exist? In this one case, the answer was about 61%.

Why Snes9x Is the Right Target

Snes9x has been around since the late 1990s. It ships inside RetroArch, which puts it on millions of phones, handhelds, Raspberry Pis, TV boxes, and PCs. Some of the most respected people in the field have worked on it, including the late Near, whose hardware research raised the accuracy of nearly every SNES emulator ever written.

This matters. If I had found performance waste in some abandoned hobby project, nobody should care. Snes9x is the opposite: mature, deeply understood, and considered essentially finished.

When people want more speed out of it on weak hardware, they don't optimize it. They reach for an older, simpler fork: Snes9x2005 or Snes9x2010, frozen at earlier snapshots of the code, faster because they predate years of accuracy fixes. The community had quietly accepted that on ARM, speed and accuracy were a dial, and you picked a point on it.

I didn't believe the dial was real. I thought it was an artifact of nobody having had the time to look.

The Method: Three Days, Under $30, Zero Behavior Changes

Over three days in September 2026, I built a performance fork called Snes9x-Z. Here is what it is, stated plainly.

It is bit-exact against upstream Snes9x. Not 'looks the same.' Not 'I played through a few levels and nothing broke.' Every frame of video and every audio sample is hashed and compared against unmodified upstream code at a pinned commit (7a8878f1, September 4th, 2026). Any difference, one wrong pixel, one wrong audio sample, fails the check and the change does not ship. This was enforced against a corpus of 22 ROMs: commercial games and dedicated hardware-behavior test ROMs written specifically to catch the subtle drift that optimizers introduce.

And it is fast. Measured with interleaved A/B runs across 14 commercial games (six repetitions each, alternating builds so machine noise hits both sides equally):

• +61.2% mean throughput on x86-64 (dual Xeon E5-2690 v4, GCC, Linux)
• +52.3% mean throughput on arm64 (Apple M4 Pro, clang, macOS)

Every game was positive on every repetition, on both platforms. The best case was Jurassic Park at +98.4% on x86-64. The worst was Winter Gold at +22.5%. Both builds used plain -O3 -flto. No -march, no CPU-specific tuning, nothing that only works on the test machine.

My brother Luiz, who handled the macOS and arm64 side of this work, also put the 32-bit ARM build on a cheap quad-core Cortex-A55 TV box and ran Star Fox, one of the heaviest games on the platform because of its SuperFX coprocessor. Upstream Snes9x reached about 70 fps. Snes9x2010, the 'fast' fork people reach for on this kind of hardware, reached about 90. Snes9x-Z reached about 120.

That is one device and one game, a hands-on reading rather than a controlled benchmark. But it is the number that made the dial disappear for me. The accurate emulator, unchanged in behavior, was now faster than the fork that had traded away accuracy to get there.

Two Kinds of Waste Found Inside the Code

Before touching anything, I profiled with hardware performance counters. The picture was striking. The CPU was not waiting on memory. Cache misses were near zero. Branch mispredictions were about one percent. Instructions per cycle were high.

The processor was not stalled, starved, or confused. It was executing far more instructions than the job required, and had been doing so on every device it ever ran on for decades. That is the purest definition of waste I know: no bottleneck to widen, no cache to add, just work that could be removed. The first phase of the project, before any threading, took this route alone and delivered roughly 20% more throughput.

The second kind of waste was silicon sitting idle. Every device this emulator runs on today has more than one core. Almost none of that capacity was being used. The pixel renderer historically ran in lockstep with the emulated CPU on a single thread. Moving it onto its own thread, with a design where the two sides never share mutable state, turned a core that was already paid for and already drawing power into actual work.

I want to be honest about that second part. Simply adding the thread was not a win. The first measurement of the raw threaded renderer was slightly negative on average and clearly negative on several games. It became the largest single gain in the project only after two further rounds of measurement and redesign, both focused on when work is handed off to the second core, not just whether it is. 'Just parallelize it' is a slogan. The real work takes the same discipline as everything else.

What the AI Actually Did (and What It Did Not)

This project used an AI-driven iteration loop for most of the code changes, and I have no interest in hiding that. But the popular narrative about AI optimization gets it backwards.

The AI did not 'see' the optimizations. I have a list of things that source-level reasoning, mine and the model's combined, predicted would be wins and were not. The SuperFX coprocessor, about a fifth of Star Fox's frame time, was profiled in depth and closed without a change. A Mode 7 rewrite measured as noise and was reverted. Running the audio processor on its own thread was researched and rejected. Restructuring the sound CPU dispatch loop was tried, measured as a regression, and reverted.

That list is not a confession. It is the whole point. Optimization at this level is not a matter of insight. It is a matter of how many hypotheses you can afford to test, measure properly, and discard. Humans are bad at this loop, not because we are not smart, but because failing forty times in a row is exhausting, and the fortieth attempt tends to get less care than the first.

What the AI changed was the cost of that loop. Try, measure, revert, try again, at a pace where the fortieth attempt gets the same rigor as the first. The wins came from measurement, not brilliance. The AI made measurement cheap enough to do relentlessly.

I have a computer science background and thirty years of doing this for a living. Every decision about what to measure, what to trust, what counted as proof, and what not to ship was mine. This is not a story about a model replacing an engineer. It is a story about an engineer whose iteration budget went from dozens of experiments to hundreds.

Build the Judge Before You Ask for the Optimization

This is the most transferable lesson in the project, and it has nothing to do with emulators.

None of this would have been usable without a cheap, implacable judge of the result. An AI-driven iteration loop produces changes fast. Most of them are wrong in ways invisible to a human reading a diff. Without an oracle, every '5% faster' claim is a bet you cannot afford to take on code that millions of people run.

Here the oracle was the bit-exact check: hash the output, compare to upstream, fail on any difference. It caught things no human reviewer would have seen. When the second thread was introduced, a thread sanitizer caught four genuine data races that the output check could not detect by construction, because each race left pixels and audio intact regardless of which side won. All four are fixed. I mention them not as a flaw but as evidence of what a process looks like when it is actually looking.

Build the judge before you ask for the optimization. The judge is what turns AI's speed from a liability into an asset.

And here is the honest boundary. Emulators are the friendly case. Their output is deterministic and verifiable byte for byte. Most enterprise software has no cheap oracle, and that, not model capability, is why most organizations cannot do this yet. The technique generalizes exactly as far as your ability to build a judge. No further.

The Arithmetic Is Uncomfortable

The whole project took three days. Model usage cost under $30. The result is code that does the same work as before with 61% less CPU time on x86-64 and 52% less on arm64, running on a code base that reaches millions of devices.

To get 60% more headroom the traditional way, you buy a faster chip or wait a hardware generation. On a handheld, that option may not exist. On a server, it is a purchase order. In a data center, it is a construction project.

Here, the same headroom came from the chip already in the device, already drawing power, already paid for.

On a handheld, the gains are not abstract. Less CPU work per frame means less heat, which means the device stays out of thermal throttling longer. That means a game that ran fine for twenty minutes still runs fine at minute forty. It means longer battery life at the same performance level. It means room for a heavier shader or a run-ahead frame without giving anything up.

What This Points To

I don't think Snes9x is special. I think it is typical.

It is good code, written by good people, that nobody had the time budget to examine at this depth, because examining code at this depth has always been expensive and the payoff uncertain. So the performance headroom sat there, undisturbed, for decades, on every device it ever ran on. Not because anyone was careless. Because the economics of looking never worked out.

Multiply that by every piece of mature software in the world. Every library that was 'fast enough' in 2009 and never revisited. Every service whose hot path was last profiled by someone who has since left the company. Every idle core in every device running at fifteen percent utilization because the software it runs was written when one core was all there was.

The current story says the answer to all of that is more hardware. I think the sign is wrong. The cheapest compute on Earth is the compute you are already wasting, and for the first time, the cost of finding it has dropped below the cost of buying more.

Snes9x-Z is one data point. It happens to be a memorable one: the target was respected, the result was large, the proof was strict, and nobody had done it before. But it is still just one point. I would like to see a thousand more.

Source code and pre-built cores for Linux, Windows, Android, and macOS are at github.com/andrezaiats/snes9x-Z. Install it, run your favorite game, watch the CPU meter, and then ask what else in your stack is doing work that does not need to exist.

FAQ

Is Snes9x-Z's 61% speedup relative to a weak or outdated baseline?

No. The comparison is against current upstream Snes9x at commit 7a8878f1, dated September 4th, 2026. That is the version actively maintained and shipped in RetroArch today. It is not a slow or artificially constrained baseline, which is exactly what makes the result surprising.

How does bit-exact verification work in practice?

Every frame of video and every audio sample produced by Snes9x-Z is hashed and compared against the same output from unmodified upstream Snes9x, running the same ROM, the same input sequence, and the same number of frames. Any mismatch, anywhere in a run, fails the check and the change is not shipped. This was applied to a corpus of 22 ROMs for each change in the project.

Why should this matter to anyone who does not work on emulators?

The emulator is the case study, not the conclusion. The argument is that most mature software has significant performance headroom that was never recovered because the cost of finding it was too high. AI-assisted iteration changes those economics. The approach applies to any codebase where you can build a reliable correctness check, which is the hard prerequisite, not model capability itself.

What did the AI contribute versus what the human engineer contributed?

The AI drove the iteration loop: writing candidate changes, applying them, and reverting after measurement. The engineer decided what to measure, designed the verification rules, set the correctness threshold, and made every shipping decision. Roughly forty hypotheses were tested for each change that shipped. The AI's contribution was making that volume of testing economically feasible. The judgment about what to test and what to trust remained entirely human.

Can organizations apply this to their own codebases right now?

The technique generalizes exactly as far as your ability to build a correctness judge. For software with deterministic, verifiable output, the barrier is low. For most enterprise software, building a reliable oracle is the hard step. That is the primary obstacle, not model capability. Organizations that invest in strong test harnesses and reproducible benchmarks are best positioned to benefit from this approach today.