🚀 Lesson 3.4: Parallel Jobs & Burst Compilation

IJobParallelFor

When your work is "do the same independent thing to every element of an array," IJobParallelFor is the tool. Instead of one Execute() that loops, you write an Execute(int index) that handles one element — and the Job System calls it for every index, spread across all the worker threads:

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

[BurstCompile]
struct MoveJob : IJobParallelFor
{
    public float deltaTime;
    [ReadOnly] public NativeArray<float3> velocities;
    public NativeArray<float3> positions;   // element i is written by iteration i

    public void Execute(int index)          // called once per element
    {
        positions[index] += velocities[index] * deltaTime;
    }
}

You schedule it with two numbers — the length (how many indices) and the batch count (how many indices each worker grabs at a time) — plus the usual optional dependency:

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

// length = positions.Length, innerloopBatchCount = 64
JobHandle handle = job.Schedule(positions.Length, 64);
handle.Complete();

That single Schedule call fans 50,000 iterations out across every core. The main thread is free until Complete(), exactly as before — the only change is that many workers now share the loop.

Batches & the Worker Pool

The batch count (the second argument) controls granularity. The Job System doesn't hand each worker a single index — that would spend more time coordinating than working. Instead it hands out batches of consecutive indices, and idle workers "steal" more batches as they finish. This work-stealing keeps every core busy even if some elements are cheaper than others.

Rule of thumb for batch count: too small (like 1) and coordination overhead dominates; too large (the whole array in one batch) and you lose load balancing. For cheap per-element work, larger batches (64–128); for heavy per-element work, smaller batches (1–16) so stealing balances the load. Start around 32–64 and profile.

The Parallel-Write Rule

Because many workers run Execute at once, there's a hard rule: iteration index may write only to [index] of its output container. If two iterations could write the same slot, you have a race — and the safety system will refuse to schedule it.

So positions[index] += ... is fine (each iteration owns its slot), but "add my value into a shared total" is not — every iteration would fight over total. Reductions and many-to-one writes need different tools: a NativeParallelHashMap, a per-index output you sum afterward, or the .AsParallelWriter() variants of some containers.

Enter Burst

Parallelism spreads the work; Burst makes each piece dramatically faster. Burst is a compiler that takes the C# in your jobs and compiles it — ahead of time — into highly optimised native machine code, bypassing the general-purpose Mono/IL2CPP path. Turning it on is almost insultingly easy: add one attribute.

[BurstCompile]                       // ← that's the whole opt-in
struct MoveJob : IJobParallelFor
{
    public float deltaTime;
    [ReadOnly] public NativeArray<float3> velocities;
    public NativeArray<float3> positions;
    public void Execute(int index)
    {
        positions[index] += velocities[index] * deltaTime;
    }
}

The first time a Burst job runs, Unity compiles it (you'll see it in the Burst menu and a brief one-time cost); after that it's native. It's common to see a Burst-compiled parallel job run 5–20× faster than the same code without Burst — on top of the parallel speedup. This is the concrete reason the 25,600-entity scene in Lesson 4.1 is comfortable rather than a slideshow: its systems are Burst-compiled jobs.

What Burst Actually Does

Burst gets its speed from a few compounding wins:

• Native code via LLVM — it compiles to optimised machine code with aggressive inlining and no managed-runtime overhead.
• SIMD vectorisation — it packs several floats into one wide CPU register and operates on them together. This is why Unity.Mathematics (float3, float4) matters: those types map onto SIMD lanes, so a float3 add can be one instruction.
• Assumptions it's allowed to make — because jobs forbid managed state and aliasing, Burst can optimise far more boldly than a general C# compiler ever could.
• Fast math — optionally, it can relax IEEE floating-point strictness for extra speed where you don't need bit-exact results.

Burst's Constraints

Burst only compiles code that plays by the data-oriented rules — which is the same discipline jobs already demand:

• No managed types inside a Burst job — no classes, no managed arrays, no string (use FixedString), no boxing.
• No calls into most of the Unity managed API — stick to math, NativeContainers, and Burst-compatible functions.
• No try/catch in release — exceptions are supported only as editor-side safety checks, not as control flow.
• Both the struct and, for systems later, the relevant methods carry [BurstCompile].

If Burst can't compile something, it tells you at compile time (or falls back to non-Burst with a warning) — it won't silently ship slow code. In practice these constraints overlap almost perfectly with what a job is allowed to do anyway, so "make it a clean job" and "make it Burst-able" are nearly the same task.

Measuring the Win

Never assume a speedup — measure it, using the Profiler from Module 2. The Job System has its own timeline lane; a well-scheduled parallel job shows up as many short bars filling several worker threads while the main thread stays thin. Compare three versions of the same workload:

Figure 2: The two multipliers stack — parallelism across cores, then Burst's native/SIMD speedup on each core.

The exact numbers depend on the work and the hardware, but the pattern is reliable: parallelism gives you roughly a per-core multiplier, and Burst multiplies again on top. Toggle Burst off with Jobs ▸ Burst ▸ Enable Compilation to feel the difference in a single scene.

Hands-on Challenge

[BurstCompile]
struct HeightJob : IJobParallelFor {
    [ReadOnly] public NativeArray<float3> positions;
    public NativeArray<float> heights;
    public void Execute(int i) {
        heights[i] = math.sin(positions[i].x) * math.cos(positions[i].z);
    }
}
var h = new HeightJob { positions = pos, heights = hgt }.Schedule(pos.Length, 64);
h.Complete();

Summary

🚀 What's Next?

You have all three DOTS multipliers — packed data, parallel jobs, and Burst. In Lesson 3.5 you'll put them together in a mini-project: a Burst-compiled parallel field simulation that moves tens of thousands of points every frame — the direct on-ramp to ECS in Module 4.