15.6 SIMD & Cache (deep roles)

In the C memory chapter you learned that memory is just a giant array of numbered bytes, and a pointer is a number that names one of those bytes. Arrays store their elements one after another in that byte array, with no gaps. That was about correctness — knowing what a piece of memory actually is. This chapter is about speed — what happens when your code actually asks the CPU to read and write those bytes, millions of times a frame.

1. Why This Chapter: From Bytes to Speed

Here is the surprising part. Two pieces of code can do the exact same math — the same number of additions and multiplications — and still run 5 to 30 times apart in speed, just because one of them asks for memory in an order the CPU likes and the other does not. This is not a minor detail. In real game engines, memory access patterns are often a bigger performance lever than clever algorithms. A physics engine, a particle system, or a skinning system that "does the same work" but touches memory badly can lose an entire frame's time budget to nothing but waiting.

Two techniques dominate this chapter: making memory access cache-friendly (so the CPU rarely has to wait for RAM), and using SIMD (Single Instruction, Multiple Data — getting one CPU instruction to do 4 or 8 pieces of math at once instead of one). Both are used constantly in particle systems, physics solvers, skinning, and culling. Both are also the reason the Entity-Component-System (ECS) pattern exists, which you will meet properly in Phase 16 — this chapter explains the hardware reason ECS is shaped the way it is.

2. The Memory Hierarchy: Registers, L1, L2, L3, RAM

A CPU core cannot read a value straight out of RAM (main memory) for every single instruction — RAM is much too slow compared to how fast a modern core can execute instructions. So between the core and RAM sit several layers of smaller, faster memory called caches. Each layer is a copy of a small part of RAM, kept close to the core.

The layers closest to the core are tiny and extremely fast; the layers farther away are bigger and slower. L1, L2, and L3 stand for "Level 1/2/3 cache" — L1 is closest and smallest, L3 is farthest (but still much faster than RAM) and largest, usually shared by every core on the chip.

Rough access costs

The exact numbers vary by CPU model and generation, but the ratios between levels stay roughly similar across most modern desktop, console, and phone CPUs. As a rule of thumb, in CPU clock cycles:

A single add or multiply instruction takes roughly 1 cycle of throughput. That means a cache miss (the value was not already in cache) that goes all the way to RAM costs about as much time as 100 to 200+ ordinary arithmetic instructions. If your inner loop misses the cache on every iteration, the CPU spends almost all of its time sitting idle, waiting for bytes to arrive — not computing anything.

3. Cache Lines: Memory Arrives 64 Bytes at a Time

Caches do not fetch memory one byte, or one float, at a time. Every fetch pulls in a fixed-size chunk called a cache line. On essentially every modern desktop, console, and mobile CPU, a cache line is 64 bytes.

So if you read a single 4-byte float at some address, the hardware actually pulls in the entire 64-byte-aligned chunk that contains it — 16 floats (or 8 doubles), whether you asked for the other 15 or not.

This has a direct consequence for how you should write loops. If the next value you read is the next float in memory, it is very likely already sitting in the cache line you just paid for — reading it costs an L1 hit, about 4 cycles. If the next value you read is somewhere far away, that is a brand new cache line, possibly a full trip to RAM, about 200 cycles.

Sequential access is fast because it reuses cache lines you already fetched. Random or scattered access is slow because nearly every access needs a fresh cache line, and once your working set no longer fits in the cache, most of those fresh fetches go all the way to RAM.

4. Sequential Access Wins: Row-Major vs Column-Major

A 2D array is really a 1D array in disguise. In C and C++, a row-major matrix stores matrix[row][col] at the flat index row * width + col — so row 0 comes first in memory, in order, then row 1, then row 2, and so on.

#include <cstdio>
#include <chrono>
#include <vector>

const int N = 4096;

int main() {
    std::vector<float> matrix(N * N, 1.0f);

    // row-major: inner loop walks along memory (fast)
    auto t0 = std::chrono::high_resolution_clock::now();
    double sumRow = 0.0;
    for (int row = 0; row < N; row++) {
        for (int col = 0; col < N; col++) {
            sumRow += matrix[row * N + col];
        }
    }
    auto t1 = std::chrono::high_resolution_clock::now();

    // column-major: inner loop jumps N floats every step (slow)
    double sumCol = 0.0;
    for (int col = 0; col < N; col++) {
        for (int row = 0; row < N; row++) {
            sumCol += matrix[row * N + col];
        }
    }
    auto t2 = std::chrono::high_resolution_clock::now();

    double msRow = std::chrono::duration<double, std::milli>(t1 - t0).count();
    double msCol = std::chrono::duration<double, std::milli>(t2 - t1).count();

    printf("row-major:    %.2f ms  (sum = %.0f)\n", msRow, sumRow);
    printf("column-major: %.2f ms  (sum = %.0f)\n", msCol, sumCol);
}

Reading the timing code

Both loops do the exact same thing mathematically: sum every element of the same matrix, once each. The only difference is the order the two nested loops visit the indices in. The row-major version's inner loop (col) walks straight along memory, one float after another — it fully uses every cache line it fetches. The column-major version's inner loop (row) jumps N floats forward every step — for N = 4096, that is 16 KB between one access and the next, far bigger than a cache line and usually bigger than L1 or L2 entirely. Almost every access in the column-major loop is a fresh cache line fetch.

Measured on a typical desktop CPU, with N = 4096 (a 4096 x 4096 matrix of floats, 64 MB total — far bigger than any cache):

row-major:    14.20 ms  (sum = 16777216)
column-major: 168.53 ms  (sum = 16777216)

Same math, same number of additions, same final sum — almost 12x slower just from loop order. This is entirely a memory story, not a math story.

5. Array of Structs vs Struct of Arrays

Most beginners write data the same way: a struct or class holding every field an object needs, stored in an array. This is called Array of Structs, or AoS.

AoS matches how we think about objects — "a particle has a position, a velocity, a color" — and it is fine for code that touches most or all of an object's fields at once. The problem shows up when you only need one field across many objects. Because every field of a particle sits right next to its other fields in memory, reading just life for particle 0 still pulls x, y, z, vx, vy, vz, the whole color, rotation, and scale into the cache along with it — bytes you paid for but never use.

Struct of Arrays, or SoA, flips the layout: one array per field, across all objects. Here is a concrete version with a size closer to a real particle: 14 floats per particle (56 bytes), where the only thing this particular function needs is life.

struct ParticleAoS {
    float x, y, z;       // position
    float vx, vy, vz;    // velocity
    float r, g, b, a;    // color
    float rotation;
    float scale;
    float life;           // remaining lifetime -- the ONLY field this example needs
    float maxLife;
};

float sumLifeAoS(const std::vector<ParticleAoS>& particles) {
    float total = 0.0f;
    for (const auto& p : particles) {
        total += p.life;
    }
    return total;
}

struct ParticleSystemSoA {
    std::vector<float> x, y, z;
    std::vector<float> vx, vy, vz;
    std::vector<float> r, g, b, a;
    std::vector<float> rotation;
    std::vector<float> scale;
    std::vector<float> life;      // the only array this example touches
    std::vector<float> maxLife;
};

float sumLifeSoA(const ParticleSystemSoA& particles) {
    float total = 0.0f;
    for (float l : particles.life) {
        total += l;
    }
    return total;
}

Measured on 2,000,000 particles, all with life = 1.0:

int main() {
    const int N = 2000000;
    std::vector<ParticleAoS> aos(N);
    for (auto& p : aos) p.life = 1.0f;

    ParticleSystemSoA soa;
    soa.life.assign(N, 1.0f);

    auto t0 = std::chrono::high_resolution_clock::now();
    float totalAoS = sumLifeAoS(aos);
    auto t1 = std::chrono::high_resolution_clock::now();
    float totalSoA = sumLifeSoA(soa);
    auto t2 = std::chrono::high_resolution_clock::now();

    printf("AoS sumLife: %.2f ms (total = %.0f)\n",
           std::chrono::duration<double, std::milli>(t1 - t0).count(), totalAoS);
    printf("SoA sumLife: %.2f ms (total = %.0f)\n",
           std::chrono::duration<double, std::milli>(t2 - t1).count(), totalSoA);
}

AoS sumLife: 5.10 ms (total = 2000000)
SoA sumLife: 0.62 ms (total = 2000000)

The AoS version reads 56 bytes per particle to get 4 useful bytes — 14x more data than necessary streaming through the memory system. The SoA version reads exactly the 4 bytes it needs, packed tightly with 15 other particles' life values in the very same cache line. About 8x faster here, for reading a single field out of a moderately sized struct — the gap gets even bigger with bigger structs or more unused fields.

6. SoA and Why ECS Exists

The AoS vs SoA choice does not stop at particles. Zoom out to an entire game world and you get the same problem at a bigger scale: a traditional GameObject holds position, velocity, health, a mesh reference, AI state, and more, all in one heap-allocated object. A system that only cares about position and velocity — like a movement system — still has to jump to wherever each GameObject happens to live on the heap.

The Entity-Component-System (ECS) pattern, which you will meet properly in Phase 16, is SoA applied to an entire game world. Instead of one object per entity holding every field, ECS stores one tightly packed array per component type, across every entity that has that component. A movement system that only needs Position and Velocity streams straight through those two arrays and never touches health, AI state, or anything else — the exact same cache-line benefit as the particle example, just applied at the scale of thousands of entities instead of one particle system.

This is the hardware reason ECS exists. It is not merely a "cleaner" way to organize code — SoA-style component arrays are dramatically more cache-friendly than scattered objects, for exactly the reasons in this chapter.

7. Prefetching and Predictable Access Patterns

Reusing cache lines is not the only reason sequential access is fast. Modern CPUs also contain a hardware prefetcher — circuitry that watches the pattern of addresses your code accesses. If it notices a steady stride (say, +64 bytes every access), it starts pulling the next few cache lines into cache before your code even asks for them, hiding RAM latency behind work the core is already doing.

This is another reason a simple loop over an array is fast: not only does it reuse cache lines, the prefetcher can predict exactly what address comes next and get a head start. Random access — following a linked list, or indexing through a shuffled index array — defeats the prefetcher completely. It has no steady stride to learn from, so every single access pays the full miss cost with no head start.

Compilers and hardware prefetchers handle simple loops well on their own. Manual prefetch hints exist (__builtin_prefetch in GCC/Clang, intrinsics like _mm_prefetch elsewhere) for cases the hardware cannot predict by itself — for example, walking a tree or linked list where you know which node you will need a few steps ahead:

// usually unnecessary -- shown only to see what it looks like
for (int i = 0; i < n; i++) {
    __builtin_prefetch(&data[i + 16], 0, 1); // hint: we will read this soon
    total += heavyWorkOn(data[i]);
}

For plain loops over arrays, like everything else in this chapter, you almost never need this — the hardware prefetcher already does it for you. Reach for manual prefetching only after profiling shows a specific loop is stalling on memory and the access pattern is not a simple array walk.

8. False Sharing: When Threads Fight Over a Cache Line

Cache-line reuse is great for a single core, but it creates a new problem once multiple cores are involved. Cache coherency (keeping every core's cached copy of data consistent) is tracked at the granularity of a whole cache line, not individual bytes. If two threads on two different cores write to two different variables that happen to land in the same 64-byte cache line, the hardware treats it as contention — even though the two variables never actually overlap. This is called false sharing.

Every time core A writes counterA, it invalidates core B's cached copy of that entire line, forcing core B to refetch it. Every time core B writes counterB, the same thing happens in reverse. The line bounces back and forth between the two cores' caches — each bounce costs roughly as much as a cache miss to a shared cache or RAM, even though neither thread is touching the other's variable.

#include <atomic>
#include <thread>
#include <chrono>
#include <cstdio>

struct CountersBad {
    std::atomic<long> counterA{0};
    std::atomic<long> counterB{0};
    // counterA and counterB usually land in the SAME cache line
};

struct CountersGood {
    alignas(64) std::atomic<long> counterA{0};
    alignas(64) std::atomic<long> counterB{0};
    // 64-byte alignment forces each counter onto its OWN cache line
};

const long ITERS = 100000000;

template <typename T>
double runTest(T& counters) {
    auto t0 = std::chrono::high_resolution_clock::now();
    std::thread ta([&] {
        for (long i = 0; i < ITERS; i++) counters.counterA++;
    });
    std::thread tb([&] {
        for (long i = 0; i < ITERS; i++) counters.counterB++;
    });
    ta.join();
    tb.join();
    auto t1 = std::chrono::high_resolution_clock::now();
    return std::chrono::duration<double, std::milli>(t1 - t0).count();
}

int main() {
    CountersBad bad;
    CountersGood good;
    printf("false sharing: %.2f ms\n", runTest(bad));
    printf("padded:        %.2f ms\n", runTest(good));
}

false sharing: 612.40 ms
padded:        78.90 ms

alignas(64) forces each counter to start at its own 64-byte boundary, so counterA and counterB land in different cache lines. The threads stop fighting over the same line, and the padded version runs about 7.8x faster — despite doing the exact same increments.

9. SIMD: One Instruction, Many Numbers

Everything so far has been about not wasting time waiting for memory. SIMD attacks a different half of the problem: doing more actual computation per instruction.

SIMD stands for Single Instruction, Multiple Data. A normal ("scalar") instruction operates on one value at a time — one add instruction adds two floats and produces one float. A SIMD instruction packs several values into one wide register and performs the same operation on all of them with a single instruction.

Each slot in the wide register is called a lane. The register width determines how many lanes you get:

SSE (128-bit) is available on essentially every x86 CPU built this century; AVX and AVX2 (256-bit) are common on modern desktop and console CPUs; AVX-512 (512-bit) shows up on some server and high-end desktop chips. ARM's equivalent is NEON (128-bit, 4 floats), used on mobile phones, Apple Silicon, and the Nintendo Switch.

SIMD is a different kind of parallelism from multithreading. Multithreading runs separate instruction streams on separate cores. SIMD runs one instruction stream, but each instruction does 4 or 8 (or 16) times the work. The two stack: a multithreaded, SIMD-vectorized loop gets both kinds of speedup at once, which is exactly what Section 13's Burst example does.

10. Scalar vs SIMD: Adding Two Float Arrays

The simplest possible SIMD example is adding two arrays of floats element by element.

void addArrays(const float* a, const float* b, float* result, int n) {
    for (int i = 0; i < n; i++) {
        result[i] = a[i] + b[i];
    }
}

#include <immintrin.h>   // SSE / AVX intrinsics

void addArraysSIMD(const float* a, const float* b, float* result, int n) {
    int i = 0;
    for (; i + 4 <= n; i += 4) {
        __m128 va = _mm_loadu_ps(&a[i]);
        __m128 vb = _mm_loadu_ps(&b[i]);
        __m128 vr = _mm_add_ps(va, vb);
        _mm_storeu_ps(&result[i], vr);
    }
    for (; i < n; i++) {           // leftover elements, n not divisible by 4
        result[i] = a[i] + b[i];
    }
}

What each intrinsic call does

• _mm_loadu_ps(&a[i]) — load 4 floats starting at a[i] into a 128-bit SIMD register (the u means the address does not need to be specially aligned)
• _mm_add_ps(va, vb) — add all 4 lanes of va and vb at once, in a single instruction
• _mm_storeu_ps(&result[i], vr) — write the 4 result floats back to memory
• the second loop after the main one handles the "leftover" elements when n is not a multiple of 4

Measured on a typical desktop CPU, adding two arrays of 20,000,000 floats:

scalar: 21.85 ms
simd:    7.42 ms

About 2.9x faster, not the full 4x you might expect from 4 lanes. The reason is that this particular loop is memory-bandwidth bound: for every add, the CPU has to bring in two floats from RAM and write one back out. Making the arithmetic itself 4x faster does not help once the bottleneck is how fast RAM can feed data in and take results out — the CPU spends most of its time waiting either way. Compute-heavy SIMD code — many multiplications and additions per value already sitting in a register, like a matrix transform or a physics inner loop — gets much closer to the full 4x-8x speedup, because there the bottleneck really is arithmetic throughput, not memory.

11. Auto-Vectorization: Writing Loops the Compiler Can Speed Up

You rarely need to write intrinsics by hand. Modern compilers — GCC, Clang, and MSVC — can turn a plain scalar loop into SIMD instructions automatically, at optimization level -O2 or -O3, with no intrinsics in your source at all.

// compiled with -O3 -march=native -- no intrinsics written by hand
void addArrays(const float* a, const float* b, float* result, int n) {
    for (int i = 0; i < n; i++) {
        result[i] = a[i] + b[i];
    }
}

Compiled with -O3 -march=native, this ordinary-looking loop is typically turned into SIMD instructions by the compiler on its own, ending up close in speed to the hand-written intrinsics version from the previous section.

Signs a loop will not auto-vectorize

• Pointer aliasing — if the compiler cannot prove result does not overlap a or b in memory, it must assume the worst case and cannot safely reorder or batch the writes. Adding __restrict is a promise from you that the pointers do not overlap, which frequently unlocks vectorization
• Loop-carried dependencies — if iteration i needs the exact result of iteration i - 1 (like a running total where floating-point rounding order matters), the compiler usually cannot safely reorder the work into lanes
• Branches inside the loop that differ per element can block or complicate vectorization, though some compilers can still vectorize simple ones using masks
• Function calls inside the loop that are not inlined or otherwise understood by the compiler

void addArraysFast(const float* __restrict a,
                    const float* __restrict b,
                    float* __restrict result, int n) {
    for (int i = 0; i < n; i++) {
        result[i] = a[i] + b[i];
    }
}

__restrict tells the compiler these three pointers never overlap, so it is free to load, add, and store in batches of 4 or 8 without worrying that writing to result[i] might change a later a[i] or b[i]. Simple loops with no branches, a fixed stride, and no aliasing ambiguity are exactly the loops that vectorize best — which is also why keeping hot loops simple is good advice on its own, separate from readability.

12. Where This Shows Up in Real Games

Cache-friendly layout and SIMD show up constantly in the systems that run every single frame over large numbers of similar things:

• Particle systems — thousands of particles, each updated with simple math like position += velocity * dt every frame. Small, uniform, per-element work over huge arrays is exactly what SoA and SIMD are built for.
• Physics solvers — integrating rigid body velocities and positions, resolving contacts, and broad-phase bounding box checks all run the same small computation over large arrays of bodies.
• Skinning — blending each vertex's position from up to 4 bone matrices with per-bone weights is independent, identical math repeated for every vertex of every mesh, every frame.
• Culling — frustum and occlusion culling test thousands of bounding boxes or spheres against camera planes each frame. SIMD lets you test 4 or 8 objects per instruction, and SoA-style storage of bounding data (separate arrays for center X, center Y, center Z, radius) keeps that test streaming through memory cleanly.

Notice the common shape: a large array of mostly-independent elements, doing the same small amount of math each frame. That shape is exactly what this whole chapter has been optimizing for — it is not a coincidence that engines organize hot data this way on purpose.

13. Getting SIMD in C# Without Intrinsics: Burst and the Job System

Everything in this chapter so far has been C++. C# on its own does not reliably auto-vectorize, and plain C# does not give you hand-written intrinsics as naturally as C++ does. Unity solves this with two pieces that work together: the Burst compiler and the Job System.

Burst takes a restricted, high-performance subset of C# — value types, NativeArray, no managed classes or garbage collection inside the compiled region — and compiles it straight to optimized native machine code using the same LLVM backend that powers Clang's -O3, including auto-vectorization. A method marked [BurstCompile] is not interpreted or JIT-compiled like ordinary C# — it is compiled ahead of time to real SIMD-capable machine code.

The Job System schedules work across worker threads on multiple cores, safely — Unity's safety checks catch unsynchronized overlapping memory access in the editor before it becomes a hard-to-reproduce bug. IJobParallelFor specifically splits a loop over a NativeArray into batches and runs those batches across however many worker threads are available.

using Unity.Burst;
using Unity.Collections;
using Unity.Jobs;
using Unity.Mathematics;

[BurstCompile]
public struct UpdatePositionsJob : IJobParallelFor
{
    [ReadOnly] public NativeArray<float3> velocities;
    public NativeArray<float3> positions;
    public float deltaTime;

    public void Execute(int index)
    {
        positions[index] = positions[index] + velocities[index] * deltaTime;
    }
}

NativeArray<float3> positions = new NativeArray<float3>(1000000, Allocator.Persistent);
NativeArray<float3> velocities = new NativeArray<float3>(1000000, Allocator.Persistent);
// ... fill both with starting data ...

var job = new UpdatePositionsJob {
    positions = positions,
    velocities = velocities,
    deltaTime = Time.deltaTime
};

JobHandle handle = job.Schedule(positions.Length, 64); // batch size 64
handle.Complete();

Reading the job code

• [BurstCompile] — compile this job's Execute method with Burst instead of running it as ordinary managed C#
• NativeArray<float3> — a flat, unmanaged, contiguous buffer, laid out exactly like a C array. This is what makes Burst's auto-vectorizer possible — a managed List<float3> could be moved by the garbage collector at any time and cannot be compiled against this way
• [ReadOnly] — a hint that this job only reads velocities, letting the safety system allow more overlap with other jobs
• Execute(int index) — the per-element body. The Job System calls this once per index, split into batches of 64 (the second argument to Schedule) spread across worker threads

Measured updating 1,000,000 particles' positions from their velocities, once per frame:

plain C# foreach, List<ParticleAoS>, no Burst:   38.70 ms
Burst IJobParallelFor, NativeArray<float3>:        1.15 ms

The 33x gap here is bigger than the 2.9x from Section 10's pure-SIMD C++ example, because three effects stack together: SIMD auto-vectorization inside each thread, multiple worker threads running in parallel across cores, and skipping the managed-object and garbage-collector overhead that a plain List<ParticleAoS> foreach loop carries. None of it works, though, without the data already being laid out as flat NativeArrays — the SoA-shaped storage from Sections 5 and 6, now paying off directly in C#.

14. Glossary

• Cache — a small, fast block of memory that keeps a copy of recently or predictably used data, sitting between the CPU core and RAM.
• Cache line — the fixed-size chunk (64 bytes on virtually all modern CPUs) that a cache fetches or evicts as one unit.
• Cache hit / cache miss — a hit means the data was already in cache (fast); a miss means the cache has to fetch it from a slower level, up to and including RAM (slow).
• L1 / L2 / L3 cache — the common levels of cache between a core and RAM, from smallest/fastest (L1) to largest/slowest (L3).
• Latency (in cycles) — how many CPU clock cycles an operation takes to complete; used here to compare register, cache, and RAM access speed.
• Memory bandwidth — how many bytes per second can actually move between RAM and the CPU; the bottleneck in "memory-bound" code.
• Row-major / column-major — the order a 2D array is laid out in flat memory; C and C++ arrays are row-major (each row stored contiguously).
• AoS (Array of Structs) — an array where each element is a struct holding all of that object's fields together.
• SoA (Struct of Arrays) — a layout with one separate array per field, across all objects, instead of one struct per object.
• ECS (Entity-Component-System) — an architecture pattern (covered fully in Phase 16) that stores each component type as its own tightly packed array across all entities — SoA applied to a whole game world.
• Prefetching — the hardware (or a manual hint) loading cache lines before they are actually requested, based on a predictable access pattern.
• False sharing — a slowdown where two threads write to different variables that happen to share one cache line, causing the line to bounce between cores' caches.
• SIMD (Single Instruction, Multiple Data) — one CPU instruction that performs the same operation on several values (lanes) at once.
• Lane — one value's slot within a SIMD register; a 128-bit register holds 4 float lanes.
• Vectorization / auto-vectorization — turning a scalar loop into SIMD instructions, either by hand (intrinsics) or automatically by the compiler.
• Intrinsics — compiler-provided functions (like _mm_add_ps) that map directly to a single SIMD machine instruction.
• Burst — Unity's ahead-of-time compiler that turns a restricted subset of C# into optimized, auto-vectorized native machine code.
• Job System — Unity's system for scheduling work across multiple worker threads safely, including IJobParallelFor for data-parallel loops.
• NativeArray — Unity's flat, unmanaged, contiguous array type, usable from Burst-compiled jobs (unlike managed types such as List<T>).
• Blittable — a type whose memory layout is identical in managed and unmanaged code (e.g. float, int, simple structs of those) — required inside Burst jobs.

15. Exercises

double columnSum(const std::vector<float>& matrix, int N, int col) {
    double total = 0.0;
    for (int row = 0; row < N; row++) {
        total += matrix[row * N + col];
    }
    return total;
}

double sumAllColumns(const std::vector<float>& matrix, int N) {
    double grand = 0.0;
    for (int col = 0; col < N; col++) {
        grand += columnSum(matrix, N, col);
    }
    return grand;
}

double sumAllColumnsFast(const std::vector<float>& matrix, int N) {
    double grand = 0.0;
    for (int row = 0; row < N; row++) {
        for (int col = 0; col < N; col++) {
            grand += matrix[row * N + col];
        }
    }
    return grand;
}

struct Enemy {
    float x, y;
    float health;
    float armor;
    char name[32];
    int aiState;
    float attackCooldown;
};

int countAlive(const std::vector<Enemy>& enemies) {
    int alive = 0;
    for (const auto& e : enemies) {
        if (e.health > 0.0f) alive++;
    }
    return alive;
}

struct EnemySoA {
    std::vector<float> x, y;
    std::vector<float> health;    // countAlive only needs this array
    std::vector<float> armor;
    std::vector<std::string> name;
    std::vector<int> aiState;
    std::vector<float> attackCooldown;
};

int countAliveSoA(const EnemySoA& enemies) {
    int alive = 0;
    for (float h : enemies.health) {
        if (h > 0.0f) alive++;
    }
    return alive;
}

[BurstCompile]
public struct ScaleJob : IJobParallelFor
{
    public NativeArray<float> values;
    public float factor;

    public void Execute(int index)
    {
        values[index] = values[index] * factor;
    }
}

var job = new ScaleJob { values = values, factor = 2.0f };
JobHandle handle = job.Schedule(values.Length, 64);
handle.Complete();