Checkpoint — Burst, SIMD, aliasing

01why

Why does Burst compile only a subset of C# (blittable structs, native containers, no managed references) rather than the whole language?

1. aTo reduce Burst's own compile times
2. bBecause LLVM makes code fast by reasoning about the program (disjoint pointers, no hidden side effects), and managed constructs — movable GC objects, virtual dispatch, exceptions — are exactly what the optimizer cannot model
3. cBecause Unity hasn't finished implementing the rest yet
4. dBecause structs are easier to type than classes

02how

You mark a system [BurstCompile] and it runs several times faster with no other change. Where did the speed come from?

1. aThe system now runs on the GPU
2. bThe same source was recompiled through LLVM into vectorized native code, instead of running as general-purpose managed code
3. c[BurstCompile] increases the thread count
4. dIt skips the parts of the loop that don't change

03how

Vectorizing a numeric loop over 10,000 entities changes its arithmetic instruction count how, at 8-wide?

1. aReduces it by a small constant percentage
2. bDivides it by roughly the vector width — ~10,000 scalar ops become ~1,250 vector ops
3. cLeaves it the same but runs it on more cores
4. dDoubles it but halves memory traffic

04why

Auto-vectorization of `b[i] = a[i] * 2` requires the compiler to load 8 a-values, multiply, store 8 b-values. Why does the SoA chunk layout make this legal where an array-of-structs layout doesn't?

1. aSoA arrays are smaller
2. bIn SoA each component is a dense contiguous span, so 8 consecutive values are one aligned vector load; in AoS those 8 values are 64+ bytes apart, so no single cheap vector load gathers them
3. cAoS layouts can't be marked [BurstCompile]
4. dSoA disables bounds checking

05how

Which of these, left in a hot loop, silently prevents vectorization (loop still runs, just scalar)?

1. aUsing float instead of double
2. bA call into managed code the optimizer can't see into — it might have side effects, so iterations can't be proven independent
3. cDeclaring the loop variable outside the loop
4. dIterating backwards

06why

The core question aliasing answers is 'can these two pointers refer to overlapping memory?' Why does the answer decide whether a loop can vectorize?

1. aOverlapping pointers use more cache
2. bIf a store to the destination could change a not-yet-read source element, doing 8-at-a-time would compute different results than 1-at-a-time — so vectorization is incorrect, not just risky, unless overlap is ruled out
3. cAliased pointers can't be marked [ReadOnly]
4. dThe compiler needs the pointers to be the same type

07why

You pass the same NativeArray as both source and destination into a Burst routine that assumed they were disjoint (no-alias default). What happens?

1. aBurst throws an aliasing exception at runtime
2. bIt runs fast but produces silently wrong results — some elements computed against overwritten neighbors — and the wrongness can vary with the CPU's vector width
3. cIt falls back to scalar automatically and is correct but slow
4. dThe compiler refuses to build it

08why

Why is [ReadOnly] on a job's input container best understood as an anti-aliasing promise rather than mere documentation?

1. aIt renames the field for clarity
2. bIt promises nothing writes the container during the job, so no write can alias a read — letting the compiler hoist/cache reads and the scheduler run multiple readers in parallel
3. cIt compresses the container in memory
4. dIt's required syntax for all job inputs