Simulating 30 Million microbes in Browser

GigaFloppa — Mon, 14 Sep 2026 22:51:22 +0000

Simulating 30 Million Microbes in the Browser

WebGPU gives the browser direct access to modern GPU capabilities — not just for rendering, but also for general-purpose computation through compute shaders.

But how far can we actually push it? What happens if, instead of running a small compute demo, we try to build a full simulation with tens of millions of active objects?

That is what I wanted to find out.

Background

For this experiment, I decided to revive an evolution simulator I had written many years ago and move its core logic from the CPU to the GPU.

The original simulator was written in C# and had a fairly conventional architecture: a two-dimensional array of objects, a separate list of living cells, and a foreach loop that executed their logic once per tick.

Each cell would inspect its surroundings, choose an action, and immediately modify the shared world. That simple model was enough for populations to emerge, compete, and evolve over time.

The old web version supported worlds of up to 200 × 200 cells. This time, I wanted to push that to 8192 × 4096 — roughly 33 million positions, each of which can potentially contain a living cell.

First, Memory

With 33 million positions, even a single 32-bit value per position already takes about 128 MiB.

And one value is nowhere near enough. A cell also needs an age, species, energy level, individual traits, plus temporary data used while calculating the next state of the simulation.

On the CPU, the natural solution is to put all of that into a Cell object. At this scale, however, that approach gets expensive very quickly. Adding just one extra 4-byte field per position can potentially cost another 128 MiB.

So in the GPU version, I split the simulation state across several arrays. One stores the basic information about what occupies each position, while energy and individual traits are kept separately. Species-level data, such as the genome, is stored independently rather than duplicated for every cell. Temporary data needed only during a tick lives in its own buffers as well.

This separation is useful for more than just reducing memory usage.

Different compute passes need different pieces of state. A shader that updates energy does not need access to everything about a cell, while the renderer has no reason to see temporary movement requests.

As a result, the memory layout is shaped not only by what needs to be stored, but also by how that data moves through the GPU.

From Sequential to Parallel Ticks

In the old version, the game simply walked through the list of living cells one by one.

A cell inspected its neighbors, chose an action, and immediately changed the shared world. The next cell would then see the result of that change.

This meant that iteration order had quietly become part of the simulation rules.

That model does not translate directly to the GPU. Thousands of cells can be processed in parallel, and there is no reliable ordering between them.

For example, two cells might see the same empty position at the same time and both decide to move into it.

To handle this, a tick is now split into several stages.

First, cells make their decisions and write an Intent describing what they want to do. At this point, the world itself remains unchanged.

Next come Claims. These represent competing requests for shared outcomes. If several cells want to occupy the same position, the conflict is resolved separately according to a predefined rule.

Only after those conflicts have been resolved does the Apply stage actually modify the world state.

This approach requires additional temporary memory and several compute passes, but it removes the dependency on the unpredictable execution order of thousands of parallel GPU invocations.

How Do You Render 33 Million Cells?

At this point, the world already lives and evolves on the GPU.

So there is an obvious question: why send all of it back to the CPU just to draw it?

One option would be to copy the world state into JavaScript after every tick and render it from there. But with tens of millions of positions, transferring that much data would quickly become a bottleneck of its own.

The new version therefore does not maintain a full CPU-side copy of the world. The data needed for rendering stays on the GPU, while JavaScript mostly handles the UI, camera, and user commands.

Zooming out creates a different problem.

Eventually, an individual cell becomes smaller than a single pixel. At that point, drawing every cell separately no longer makes much sense.

Instead, the distant view is built from aggregated regions of the world. The farther the camera zooms out, the less important any individual cell becomes and the more useful the larger picture is: population density, resources, and the distribution of species.

Results

For a stress test, I filled the entire available world with living cells.

Even under that load, the simulation manages roughly 5–10 full ticks per second on my machine.

Of course, 5–10 ticks/s is not some universal measure of WebGPU performance. The actual speed depends on the GPU, browser, simulation settings, and the number of living cells.

What matters to me is the broader result: a simulation with tens of millions of active objects can run at a practical speed entirely inside a regular browser tab.

Conclusion

When I started this remake, the main challenge I wanted to explore was simple: how large could a living, evolving world become while still running entirely inside the browser?

The answer turned out to be: surprisingly large.

Tens of millions of active objects are a perfectly workable scale. But reaching that scale requires more than simply porting existing CPU code to the GPU. The data layout and the simulation logic themselves have to be redesigned around parallel execution.

If you'd like to see the simulation in action, the current version is available here: The Strongest Survives on itch.io.

DEV Community: GigaFloppa