Checkpoint — entity jobs & dependencies

01why

Why is the chunk the natural unit of parallel distribution, requiring no locks between cores?

1. aChunks are small enough to fit in registers
2. bChunks are independent by construction — each holds its own entities' data contiguously and iteration order was never guaranteed, so different chunks share no memory and impose no ordering: exactly the precondition for lock-free parallel work
3. cThe job system copies each chunk before processing
4. dChunks are processed on the GPU

02how

You write an IJobEntity whose Execute takes one entity's components, then call ScheduleParallel. At what granularity does it actually run?

1. aOne thread per entity
2. bPer-chunk across worker threads — the generated job distributes matching chunks over cores, each thread calling your Execute for every entity in its chunk
3. cEntirely on the main thread, sequentially
4. dOne entity at a time, but Burst-compiled

03how

In an IJobEntity, `ref LocalTransform transform` vs `in Velocity velocity` — what's the difference the safety system cares about?

1. aref is faster than in
2. bref declares a write to LocalTransform; in declares read-only access to Velocity (the per-parameter [ReadOnly]) — driving which jobs conflict and which can run concurrently
3. cin copies the component, ref doesn't
4. dThere's no functional difference

04how

When is dropping from IJobEntity down to IJobChunk actually justified?

1. aAlways — IJobChunk is faster
2. bWhen you need a concrete capability the chunk view provides: array-wide operations, enabled-mask handling, or chunk-level metadata — not merely 'for performance,' since IJobEntity already compiles to a tight per-chunk loop
3. cOnly when Burst is disabled
4. dWhen you have fewer than 100 entities

05why

A JobHandle passed into another Schedule call expresses what, and how does chaining them help?

1. aIt copies the first job's data into the second
2. bIt declares 'this job must finish before that one'; chaining handles builds a dependency graph the system runs with independent branches concurrent and dependencies serialized
3. cIt merges the two jobs into one
4. dIt forces both jobs onto the same thread

06why

Why does Schedule return immediately instead of running the job, and why is that essential rather than merely convenient?

1. aIt's a bug that will be fixed
2. bDeferred, non-blocking scheduling lets you queue a whole graph in microseconds so the system can then run it all across cores; if Schedule blocked until done, jobs would run one at a time and there'd be no parallelism
3. cSchedule runs the job but on a background timer
4. dIt returns early only when the job is trivial

07why

The most common JOB performance mistake isn't a race (the system catches those). What is it?

1. aUsing too many chunks
2. bCalling Complete too early/often — each Complete stalls the main thread, so completing after every job serializes the graph and is worse than not using jobs (you paid scheduling overhead for nothing)
3. cMarking too many inputs [ReadOnly]
4. dScheduling on the wrong core

08why

How does over-completing relate to a Module 2 structural-change sync point?

1. aThey're unrelated mechanisms
2. bThey're the same phenomenon: a sync point drains in-flight jobs (a forced Complete of everything) before moving memory; an eager Complete is a self-inflicted version of that same main-thread barrier — both stall and discard concurrency
3. cSync points speed up completion
4. dOver-completing prevents sync points