Put HST lower in the stack as a user-space runtime layer inside a fully sandboxed Linux VM, then measure whether sparse workloads can be transparently routed through it — instead of being called by hand from one demo.
perf statbaseline_csc — exact CSC reuse-delta every step. The honest sparse baseline.
library_hst — rebuild an HST schedule every step, then apply. Naive "call HST by hand": pays schedule-build cost on every update.
runtime_hst — a node that caches schedules keyed by the dirty-tile-set and gates by density. The caller just submit()s updates; the node decides HST-vs-CSC. This is the runtime layer.
| dirty pattern | density | baseline_csc | library_hst | runtime_hst | runtime / library |
|---|---|---|---|---|---|
| scattered64 | 0.04 | 31.8 ms | 1175.8 ms | 31.2 ms | 37.7× |
| one_tile32 | 1.00 | 25.0 ms | 65.2 ms | 28.5 ms | 2.29× |
| four_tiles32 | 1.00 | 42.1 ms | 169.0 ms | 52.8 ms | 3.20× |
| eight_tiles32 | 1.00 | 58.7 ms | 281.7 ms | 80.8 ms | 3.49× |
The runtime layer recovers ~all of CSC's performance (it routes scattered updates away from HST) while running 2.3–37.7× faster than naive library-HST calls. The schedule cache is the whole point of putting HST in the stack as a runtime instead of a manual call.
In-process only. A daemon / IPC / REST front destroys the sub-millisecond win. The "node" is a linked library, not a service.
Batch=1 doesn't beat CSC. Recovering CSC parity is the win at B=1; beating CSC needs the batched B≥8 kernels from the v10 envelope (up to ~2.5× at B=16).
User-space only. No BIOS, kernel drivers, bootloader, or host process injection — matches the tasking guardrails.