Checkpoint — math types & verification

01why

Why does `float4 c = a + b;` (Unity.Mathematics) give you SIMD more reliably than writing a scalar loop and hoping it auto-vectorizes?

1. afloat4 uses less memory than four floats
2. bThe float4 add IS four-wide arithmetic by construction — it compiles to one vector instruction with nothing for the compiler to infer, whereas a loop must be proven vectorizable
3. cfloat4 runs on a separate coprocessor
4. dLoops can't be vectorized at all in Burst

02why

Unity.Mathematics deliberately mirrors HLSL/shader conventions (lower-case float4, math.dot, swizzles). What's the practical payoff?

1. aIt makes the code shorter to type
2. bGameplay and graphics math become the same vocabulary, so a team carries fewer translation errors between CPU simulation and GPU rendering and reasons about both with one model
3. cIt lets C# code run on the GPU automatically
4. dIt's required by the Burst compiler

03how

Using v.xz (a swizzle) instead of manually reading v.x and v.z into a new float2 is preferred because:

1. aSwizzles are just shorter to write; performance is identical
2. bA swizzle is a lane operation the hardware does directly, where manual .x/.z recombination is scalar copying that's often slower and less clear
3. cManual access doesn't compile under Burst
4. dSwizzles automatically normalize the vector

04how

Mixing Mathf.Sqrt / System.Math into hot Burst numeric code (instead of math.sqrt) tends to hurt because:

1. aThose functions are deprecated
2. bThey're scalar and sometimes double-based, so they're not the vector idiom and can force width-halving float↔double conversions
3. cThey throw exceptions under Burst
4. dThey only work on the main thread

05how

In the Burst Inspector, you see `vmulss` and `vaddss` in a loop you expected to be vectorized. What does the `ss` suffix tell you?

1. aScalar single — one value per instruction; the loop did NOT vectorize, so hunt for the branch/dependency/opaque call that stopped it
2. bSIMD single — it vectorized perfectly
3. cSigned short — an integer conversion happened
4. dNothing meaningful; suffixes are cosmetic

06why

Your Burst micro-benchmark of a million multiplies reports a speed implying billions of ops in nanoseconds. Most likely explanation?

1. aBurst genuinely achieved that throughput
2. bThe loop's result was never used, so dead-code elimination deleted the loop entirely — you timed an empty loop and measured nothing
3. cThe CPU overclocked during the test
4. dThe timer has nanosecond precision errors

07how

The correct defense against DCE deleting your benchmark loop is to:

1. aAdd more iterations
2. bMake the result observable — write it to a NativeArray, return it, or accumulate into an output the caller reads — so the compiler can't prove the work is dead
3. cDisable Burst for the benchmark
4. dUse double instead of float

08why

Why should a benchmark that decides an architecture choice run several untimed iterations first, then report a median from a release build rather than a single Editor sample?

1. aTo make the test take longer and seem more rigorous
2. bThe first runs pay one-time costs (compilation, cold caches, page faults) and Editor safety checks inflate numbers — warmup plus release build plus a stable central value measure steady state, not startup or debug overhead
3. cMedians are always larger than means, giving a safety margin
4. dRelease builds disable the CPU cache