One GPU runs 65,536 Nintendo consoles, provided they all press the same button
NeSLE moves the emulator beside the learning algorithm, with a revealing gap between synchronized tests and independent play.
Mario has acquired 65,535 coworkers. They are all jumping on the boss’s schedule, which helps explain the productivity numbers.
The maker’s NeSLE repository reports roughly 13 million NES frames per second on an A100. The CPU, graphics processor and bus of each emulated console live inside a CUDA kernel. Game observations stay on the graphics card for reinforcement learning instead of making a commute back to the host.
The README’s phrase “one thread per console” makes the trick unusually easy to picture. A graphics card normally helps draw one game’s world. Here, it carries a crowd of separate little machines so a learning system has many chances to discover how Mario survives.
These are the maker’s measurements, and the README is the source for this demonstration. There is an important asterisk (naturally): randomized actions make its GTX 1050 Ti test about six times slower than the synchronized case. That prevents the largest number from becoming a promise about every training run.
A benchmark where everybody pushes the same button can still measure something useful, although it answers a narrower question than a benchmark where every Mario makes a different decision and the emulator has to deal with all of them. Like timing a cafeteria by handing every customer the same sandwich, the easy case removes work that returns when the orders differ.
There is a second useful distinction between getting through frames quickly and learning something useful from them. A fast simulation supplies opportunities. The training code still has to turn those opportunities into better behavior. Multiplying mistakes without improving the policy would merely give Mario a very efficient way to fall into the same hole.
For a reproducible comparison, the useful receipt includes the GPU, operating system, number of environments, observation mode and action pattern. Those describe the workload the next person can attempt. A bare speedup leaves them trying to rebuild dinner from a photograph of a plate.
The project remains a focused experiment rather than a universal NES replacement. Its limited mapper coverage matters if the intended workload extends beyond Mario. That is a useful boundary to know before volunteering an entire game shelf for graphics-card duty.
Moving more simulations beside the learner could reduce waiting elsewhere, provided each port can preserve the behavior the experiment needs. The unresolved work is both compatibility and whether faster experience keeps producing useful learning as the workload changes.
The README also identifies Windows training as a constrained path; an operating-system change can alter which limit appears first.
Mario still has to make the jump.