A browser evolution simulator scales to 33 million positions by splitting each tick into several GPU passes

8192 by 4096 is 33,554,432 positions ^[1]. One 32-bit value for each of them is 134,217,728 bytes, or 128 MiB exactly ^[2]. The post lists what a cell needs beyond what occupies a position: an age, a species, an energy level, individual traits, and temporary data used while calculating the next state ^[5]. Hold the first four as separate 32-bit fields per position and the resident set is five buffers of 128 MiB, 640 MiB, before any temporaries ^[3].

So the genome does not travel with the cell. Species-level data is stored once per species instead of being duplicated for every position ^[6]. The split also cuts what each shader has to bind: a shader that updates energy does not need access to everything about a cell, and the renderer has no reason to see temporary movement requests ^[7]. The author writes that the layout is shaped not only by what needs to be stored but by how that data moves through the GPU ^[8].

The harder rewrite is ordering. In the C# version a cell inspected its neighbours, chose an action, and changed the shared world immediately, so the next cell in the loop saw the result ^[9]. "This meant that iteration order had quietly become part of the simulation rules," the author wrote on dev.to ^[10].

On the GPU there is no reliable ordering between thousands of parallel invocations, and two cells can see the same empty position and both decide to move into it ^[11]. A tick therefore runs in three stages. Cells first write an Intent describing what they want to do, while the world stays unchanged. Claims are then competing requests for shared outcomes, and where several cells want one position the conflict is resolved by a predefined rule. Apply modifies the world last ^[12]. The author's stated cost for this is additional temporary memory and several compute passes ^[13].

For that structure to transfer to your simulation, two things have to hold. Your conflicts have to be resolvable by a rule that does not depend on who ran first, because the Claim stage replaces order with policy. And you have to accept that the world lives on the GPU: the new version keeps no full CPU-side copy, and JavaScript handles the UI, camera and user commands ^[14]. Copying the state into JavaScript after every tick was the option considered and rejected, on the grounds that transferring that much data becomes its own bottleneck ^[15].

The old web build topped out at 200 by 200, which is 40,000 positions, so the new world holds about 839 times as many ^[4]. The post does not report tick times, frame rates or the GPU it ran on. Without those numbers the 33 million describes an allocation and a design, not a measured throughput. The engineering that matters here is in the layout and the staging.

One more constraint shows up at the far end of the zoom. Once a cell is smaller than a pixel, the distant view is built from aggregated regions of the world ^[16].