Distillation

Date: July 30, 2026

• 🟡 (21:25) SWAR benchmark results: naive byte loop median 279.6 ms (357.6 MiB/s, runs [270.7, 279.6, 281.2, 284.1, 275.8]). Uint32Array SWAR (4×) median 144.7 ms (691.0 MiB/s, runs [144.7, 141.4, 146.7, 145.3, 139.5]). BigUint64Array SWAR (8×) median 127.6 ms (783.6 MiB/s, runs [127.6, 128.9, 126.9, 123.7, 128.2]).
• 🟡 (21:25) SWAR benchmark speedup vs naive: Uint32Array SWAR 1.93×, BigUint64Array SWAR 2.19×.
• 🟡 (21:25) Correctness verification: BigUint64Array SWAR implementation is actually CORRECT, not wrong as user expected. Verified across (a) 4096-byte sample with ~95% zero diff, (b) all bytes 0xff stress test (65536 pairs), (c) 1,000,000 random 8-byte pairs, (d) cross-byte carry stress (4×0x7f × 0xff byte pattern). All tests passed for both Uint32 and BigUint64 implementations.
• 🟡 (21:25) Mathematical explanation: SWAR trick ((a & mask) + (b & mask)) ^ ((a ^ b) & sign) with mask=0x7f7f7f7f is correct per byte lane because the 0x7f mask strips each byte's high bit, preventing cross-byte carry propagation. Lane width (4 vs 8 bytes) affects throughput only, not correctness. The formula in src/bspatch.ts:520 lifted to 8-byte lanes is mathematically equivalent to the 4-byte version.
• 🟡 (21:25) Benchmark setup details: 100 MB buffer, narrow-gap diff (~95% zero diff bytes), 5 independent runs, 5 reps per run, 3×8 MB warm-up iterations before measurement (JIT + GC stabilization). Per-run time = single-call median across reps.
• 🟡 (21:25) Benchmark script location: /tmp/opencode/swar-bench.mjs (extended with additional correctness verification tests beyond the original 4096-byte sample).
• 🟢 (21:25) User's premise about BigUint64Array carry issue was incorrect — the 0x7f per-byte mask prevents cross-byte carries regardless of lane width.