23. AoS vs SoA, measured

Same data, four ways

For three chapters you’ve heard that layout matters. Now we measure it. This book’s repository has a benchmark harness that stores the same particles (x, y, vx, vy, mass, health) in several ways and runs the same loops over each:

// aos: an array of objects
ps[i].x

// aos-packed: one Float64Array, 6 per item
f[i * 6 + 0]

// soa: one Float64Array per field
x[i]

// aosoa8: blocks of 8, SoA inside a block
f[blk * 48 + 0 * 8 + lane]

All four hold identical numbers. Only where those numbers sit in memory changes.

What each loop actually loads

The loop we care about most is update-xy: x += vx * dt and y += vy * dt for every particle. It needs four of the six fields. Step through what each layout drags into the cache to get them:

The wins

Here is update-xy with 100,000 particles, from this book’s committed benchmark run:

Reading a single field shows the effect even more strongly, because SoA reads exactly one column and nothing else:

Notice that packed AoS already captures a big part of the win. It keeps AoS order but drops the object headers, the pointers and the boxed numbers from chapter 22. So part of SoA’s advantage is simply typed storage, and part is locality: SoA goes further only because it also stops loading the unused fields.

Random order is where object arrays suffer most. The random-x suite reads x and vx at shuffled indexes, so the prefetcher can’t help, and every object is a pointer to chase:

The loss: materialization

Sometimes the code really does want an object. Maybe it pushes particles into a list, or hands them to a library. With SoA there is no object, so it has to be built:

function get(s, i) {
  return {
    x: s.x[i], y: s.y[i],
    vx: s.vx[i], vy: s.vy[i],
  };
}

const s = {
  x: new Float64Array([1, 2]),
  y: new Float64Array([3, 4]),
};
function get(s, i) {
  return { x: s.x[i], y: s.y[i] };
}
const a = get(s, 0);
const b = get(s, 0);
console.log(a, b);
console.log(a === b);
a.x = 99;
console.log(s.x[0]);

Every call allocates a fresh object, so get(s, 0) === get(s, 0) is false. That’s the identity problem from chapter 4: an optimizer must never let a program notice. And it costs time. The materialize suite builds an array holding one real object per element:

There’s a twist. The get-objects suite hands each element to a small function that wants an object, but doesn’t keep it. There, in this book’s run, SoA did not lose: V8 inlined the function and removed the temporary object altogether. Whether materializing costs anything depends on whether the object escapes, which is exactly the question Viscosity’s escape analysis must answer. A TypeScript experiment by Zap found the same shape: SoA wins on reading a few fields and loses when whole objects must be rebuilt^[3].

Small collections and AoSoA

With only 1,000 particles, everything fits in cache, and the picture shrinks:

AoSoA is a compromise with its own trade-offs. Inside a block, each field is contiguous: 8 doubles is exactly one cache line, and a natural fit for SIMD lanes. ISPC builds this into the language as soa<8>, keeping ordinary pts[i].x syntax while storing blocks^[5][4], and its performance guide recommends it when vector loads matter^[6]. But every random access must work out a block and a lane, a division and a remainder. In plain JavaScript, without SIMD, that arithmetic is pure cost.

Hot/cold splitting

You don’t have to move every field. If a loop touches x, y, vx and vy every frame but name and health almost never, move just the busy fields into columns:

const hot = {
  x: new Float64Array(n),
  y: new Float64Array(n),
  vx: new Float64Array(n),
  vy: new Float64Array(n),
};
const cold = [{ name: 'a', health: 100 }];

Measure it yourself

These numbers came from one cloud machine. Your phone or laptop has different caches and a different engine version. Run it:

Your turn

function toSoa(ps, fields) {
  const s = {};
  // your code here
  return s;
}

const ps = [{ x: 1, y: 2 }];
console.log(toSoa(ps, ['x', 'y']));

function aosoaAt(i, f) {
  // your code here
}

console.log(aosoaAt(10, 2));

What you learned

• AoS vs SoA is a trade-off. SoA won in this book’s run when a loop touched a few fields of many elements, and in shuffled access.
• Packed AoS captures part of the win, by dropping headers, pointers and boxed numbers; SoA adds locality on top.
• Materialization (rebuilding objects from columns) is SoA’s weakness: it allocates, and it creates new identities. If the object doesn’t escape, the engine may remove it.
• Small collections barely benefit: the data already fits in cache.
• AoSoA stores blocks of SoA: cache- and SIMD-friendly inside a block, but random access pays for index arithmetic.
• A hot/cold split moves only the busy fields into columns.

Next: how to trust any of these numbers. Benchmarking honestly.