Performance on AIBussin — AI applications, systems and books

Profile Before You Optimize

Mon, 10 Aug 2026 20:52:00 +0100

By now we have built dozens of automata.

The natural temptation is to make them faster.

The wrong first question is:

Which optimization trick should I use?

The right first question is:

Where is the time actually going?

Performance work begins with measurement, and with the doctrine Part VI starts from:

Optimize the verified implementation, not the first implementation that happens to render something plausible.

Running this book’s own earlier code turned up undefined helpers, wrong signatures and a misaligned FFT, all inside chapters that produced plausible figures. Speed means nothing until equivalence is established.

Vectorize the Update Loop

Mon, 10 Aug 2026 20:53:00 +0100

A cellular automaton is local.

That does not mean we should update it cell by cell in Python.

For dense grids, the same local rule is applied everywhere. That regularity is exactly what array programming is good at.

Start with the obvious implementation

def life_step_slow(grid):
    height, width = grid.shape
    next_grid = np.zeros_like(grid)

    for y in range(height):
        for x in range(width):
            total = 0
            for dy in (-1, 0, 1):
                for dx in (-1, 0, 1):
                    if dx == 0 and dy == 0:
                        continue
                    total += grid[(y + dy) % height, (x + dx) % width]

            alive = grid[y, x] == 1
            next_grid[y, x] = (
                total == 3 or (alive and total == 2)
            )

    return next_grid

This is useful because it states the mechanism clearly.

Run Cellular Automata on the GPU

Mon, 10 Aug 2026 20:54:00 +0100

Once the update is expressed as tensor operations, moving to a GPU becomes straightforward.

But a GPU is not automatically faster.

It wins when there is enough parallel work to amortize transfer and launch overhead.

A tensor implementation of Life

import torch
import torch.nn.functional as F

LIFE_KERNEL = torch.tensor(
    [[1.0, 1.0, 1.0],
     [1.0, 0.0, 1.0],
     [1.0, 1.0, 1.0]]
).view(1, 1, 3, 3)


def life_step(x):
    padded = F.pad(x, (1, 1, 1, 1), mode="circular")
    neighbors = F.conv2d(padded, LIFE_KERNEL.to(x.device))
    alive = x > 0.5
    born = neighbors == 3
    survive = alive & (neighbors == 2)
    return (born | survive).float()

Two things matter here beyond the convolution. First, this is the third life_step in the book (after Chapters 6 and 51) — same B3/S23 rule, new backend, bridged explicitly rather than silently redefined. Second, the padding mode is load-bearing: plain padding=1 zero-pads, which silently changes periodic boundaries into dead ones. Circular padding preserves the torus semantics every roll-based helper in this book assumes — verified bit-identical against the NumPy version on 20 random grids, where the zero-padded variant mismatched all 20 at the edges.

Use FFTs for Large Neighborhoods

Mon, 10 Aug 2026 20:55:00 +0100

Small local neighborhoods are cheap to evaluate directly.

Large smooth kernels are different.

Lenia taught us that a neighborhood may cover dozens of cells in every direction. At that scale, direct convolution can become expensive.

The Fourier transform gives us another route — provided the kernel is centered correctly, which is where the FFT bug this book had to fix lived.

Convolution becomes multiplication

For periodic domains:

convolution in space
        ↕
multiplication in frequency

So instead of sliding a large kernel over every location, we can transform both arrays, multiply them, and transform back.