pure/docs/research/084-parallel-syncs.md, branch masterVerified execution runtime unifying state, persistence, and replication.
http://git.yeowoo.org/pure/atom?h=master2026-09-27T13:11:19ZMeasure what moving saves off the owner would buy (084)2026-09-27T13:11:19Zeunhhunecpition205@gmail.com2026-09-27T13:11:19Zurn:sha1:87480ce170895f841c40930ce24a7a026646ae14
Nothing a thread can give: with writes saturated the device's one line of
syncs is the bottleneck, so zeroing the tail or compacting on another
thread only queues that device work behind the commits, and the owner's
idle gap is shorter than one journal commit. Built without compaction the
store is no faster; without compaction and without tail growth durable
posts gain 1.4% and the p99 drops 24% (17.4 to 13.3 ms). New blocks are the
tail latency, so the way to it is a store that rewrites its space in place,
a ring cleaned forward instead of compacted into new files.
Measure whether sharding owners by key would add writes (084)2026-09-27T12:57:51Zeunhhunecpition205@gmail.com2026-09-27T12:57:51Zurn:sha1:5e90a99dfdcc0a16f52213370cda29779571e36c
It would not, on this device. One file's syncs or four at once, the SD card
completes the same 510-690 commits per second, the latency growing with the
number of files. The scoreboard app with two owners, each with a store of
its own, took 23% fewer durable posts than one owner (median 16,230 against
20,974 a second) with 2-3x the p99: syncs queue, and each carries half the
events. One owner's group commit stays; cores serve reads, and writes grow
by making the sync itself cheaper.