<feed xmlns='http://www.w3.org/2005/Atom'>
<title>pure/docs/research/132-batch-executor-floor-and-the-way-past.md, branch master</title>
<subtitle>Verified execution runtime unifying state, persistence, and replication.
</subtitle>
<id>http://git.yeowoo.org/pure/atom?h=master</id>
<link rel='self' href='http://git.yeowoo.org/pure/atom?h=master'/>
<link rel='alternate' type='text/html' href='http://git.yeowoo.org/pure/'/>
<updated>2026-10-08T13:36:27Z</updated>
<entry>
<title>Research 132 and 133 corrected: the per-batch cost was icount's three rounds over one round's batches, 3x too high; about 2,300 instructions (0.33 us) in a small block, 0.90 us in knapsack's (38% of its time, not 20%)</title>
<updated>2026-10-08T13:36:27Z</updated>
<author>
<name>eunhhu</name>
<email>necpition205@gmail.com</email>
</author>
<published>2026-10-08T13:36:27Z</published>
<link rel='alternate' type='text/html' href='http://git.yeowoo.org/pure/commit/?id=3e3f008b942106cedb59ebca760376274c2fcb84'/>
<id>urn:sha1:3e3f008b942106cedb59ebca760376274c2fcb84</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Research 133: register tiles measured (132's deciding experiment): past the bar on roots (0.71x the compiled code's cycles a step), not on knapsack (4x) or BFS (2.4x), as NEON has no gather and a tile's lanes go out and in one by one; tight passes of the batch executor's own shape in the same run at 1.2x (BFS) and 0.4x (knapsack, clang): the shape is right and the 3x is implementation, so 132's A (a batch program made once at load, loops tight by type, width and stride, fewer passes) is the way; tiles kept aside for chains of arithmetic; 132, 024 and CHECKPOINT say so</title>
<updated>2026-10-08T12:39:18Z</updated>
<author>
<name>eunhhu</name>
<email>necpition205@gmail.com</email>
</author>
<published>2026-10-08T12:39:18Z</published>
<link rel='alternate' type='text/html' href='http://git.yeowoo.org/pure/commit/?id=66e3f7d2adbc752b1e7a6c052675868a564314d4'/>
<id>urn:sha1:66e3f7d2adbc752b1e7a6c052675868a564314d4</id>
<content type='text'>
</content>
</entry>
<entry>
<title>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</title>
<updated>2026-10-08T12:08:06Z</updated>
<author>
<name>eunhhu</name>
<email>necpition205@gmail.com</email>
</author>
<published>2026-10-08T12:08:06Z</published>
<link rel='alternate' type='text/html' href='http://git.yeowoo.org/pure/commit/?id=43815a41bfab2f561bf69ecb0bd5de75bef3678a'/>
<id>urn:sha1:43815a41bfab2f561bf69ecb0bd5de75bef3678a</id>
<content type='text'>
</content>
</entry>
</feed>
