Concurrent Game of Life Cycle Explorer
This project uses Conway's Game of Life as a clean concurrency case study. The rule set is simple, every generation is deterministic, and each cell update depends only on its local neighborhood. That makes it easy to verify correctness and easy to split the work across workers.
The page is organized around two different goals. The interactive board below lets you explore the simulation itself. The benchmark section further down is where the real performance claim lives. That separation matters because a browser animation is useful for interaction, but the authoritative concurrency result should come from the Go implementation rather than from browser rendering behavior.
How to read this page: the visible board is the simulation. A concurrent implementation runs in the background and checks that it produces the same generations. The benchmark section below then shows the measured runtime difference for the Go version under a fixed workload.
Both sides use the same Game of Life rule set, so the boards should match exactly after each step.
The browser is useful for interaction, but the authoritative performance result is the Go benchmark shown below.
Click the board to toggle cells, randomize a new pattern, or run and pause the animation at your own pace.
What This Shows
Game of Life is useful here because it is easy to understand and deterministic. Every generation is produced from the same local rule, so it is straightforward to verify that a concurrent implementation matches a sequential one exactly.
This page therefore does two jobs. First, it lets you interact with the simulation itself. Second, it shows that the concurrent implementation produces the same results as the visible sequential simulation.
The real speed evidence for this project comes from the Go implementation, where the same workload runs without browser messaging and canvas overhead. The benchmark setup in this repository uses a 160x160 board with 4800 live cells seeded from a fixed random seed. Each benchmark iteration computes one full next generation. The concurrent version splits the rows across 8 workers.
This result is the expected shape. The concurrent version is faster because row updates can be computed independently, but it is not 8x faster just because there are 8 workers. Worker scheduling, memory access, coordination overhead, and the finite board size all limit the gain. A measured speedup of about 2.91x on this workload is therefore credible and worth showing.
Conclusion
This project works well because the responsibilities are separated cleanly. The browser page shows the simulation and confirms that sequential and concurrent evolution agree. The Go benchmark then provides the actual performance evidence. Together, those two pieces make the project easy to understand, easy to verify, and honest about what concurrency is improving.
Back to projects