Research 132 (no code): where the batch executor's cost sits (an element's passes through memory; a batch's fixed cost about 6,500 instructions, 1 us, measured by 1024 against 256 lanes: fewer lanes are slower, so 024's L1 sizing was the wrong lever; a candidate's tail about 250), what the database literature measured of the same shape (X100, Kersten 2018's cycles and instructions a tuple, Sompolski 2011, Gubner 2017's in-register aggregation, Photon, Ertl and Gregg), the ways judged by the philosophy (a batch program made once at load; register tiles with threaded dispatch as the one general way past the floor; a table of fused operations and AOT C out), and the deciding experiment with its bar first (three bodies in tiles of 4, 8, 16: within 1.3x the compiled code's cycles an element, or it is not the answer); 041 lanes data

1 files changed, 4 insertions, 0 deletions

diff --git a/research/experiments/041-batches/runs.sh b/research/experiments/041-batches/runs.sh
index 190a3d2..6f3a4e8 100755
--- a/research/experiments/041-batches/runs.sh
+++ b/research/experiments/041-batches/runs.sh
@@ -44,3 +44,7 @@ counts)
 *) echo "runs.sh suite NAME ROUNDS [WORK ...] | counts NAME [WORK ...]" >&2
     exit 2 ;;
 esac
+# 2026-10-08-lanes.jsonl (research 132): b9's code with BATCH 1024, 512 and
+# 256 (core/module-batch.c's enum), suite-run 5 rounds twice (ms: the two
+# medians) and costs/time.c's sum0, ops0 and nest under icount 3 rounds:
+# a batch's fixed cost is (the instructions' difference) / (the batches').