Benchmarks
HST is benchmarked as an incremental runtime, not as a generic one-shot sparse multiply. The public summary below describes fixture-backed packs and the measurement rules used during technical evaluation.
Methodology
We compare HST against exact sparse-delta paths a technical team would actually try first: CSC delta, grouped CSC, and hand-tuned tile traversal where appropriate. Every run is interpreted alongside locality, visited nonzero fraction, error, and fallback behavior.
Four columns are withheld from the published sweep, and this is what they were. The raw file records how many nonzeros each path visited, and their ratio. That ratio is the rule the runtime uses to split an update between its two paths, so we do not publish it — the same fields are withheld from our released research CSVs for the same reason, and it would be odd to hold the line there and not here. Withheld: density, csc_touched_nnz, hst_scanned_nnz, active_tilerow_nnz. Nothing on this page depends on them. Every ratio we quote is a ratio of two timings, and both timings are still in the file — hst_flat_vs_csc_reuse is csc_reuse_flat_ms / hst_sched_flat_ms, hst_flat_vs_active is active_flat_ms / hst_sched_flat_ms, and the same holds for all nine ratio columns. Recompute any figure here from the timings and you should land on the number we printed; if you do not, we would like to know.
All timing is in-process wall clock against the standalone C++ runtime; HST ships as an embedded library, so there is no transport in the measured path. Publishable reports pin matrix size, seed, update pattern, active columns, tile size, budget, error target, hardware, and date.
Unless a table says otherwise, every number on this page comes from the v10 high-locality sweep run on 2026-06-30 on an Apple M1 Max (arm64, 64 GB), and the raw CSVs for it are published under /benchmarks/. The headline figures are steady-state at batch width 8, with the schedule reused across calls. Both conditions move the result: the same sweep at batch width 1, or without reuse, is close to parity or below it. Rebuilding the same source under a second compiler, on one machine over the same operator set, has moved results by 3–7x against the first compiler as baseline — larger than any algorithmic change we have made. That comparison was run on our x86 bench box rather than on the machine this sweep used, so it bounds the risk without describing this run. A number is only comparable against another built the same way, and this sweep’s CSVs do not record which compiler built it, which we are treating as a gap rather than a detail.
Why batch width 8 and not 16. Batch width 16 is the most flattering column in this sweep and we have stopped quoting it as a headline. Two of our own sessions on the same harness disagree on it by about 23% while widths 1 through 8 reproduce between the same sessions to under 1%, and at width 16 the harness dispatches its baseline through a different hand-written code path than the one widths 1–8 use — so the comparison is not the same comparison. Until that is settled, the width-16 figures below stand as recorded, not as claims. Width 8 is the widest column we are willing to lead with.
Operating envelope
A high-locality v10 sweep at 60k by 60k, run 2026-06-30 on an Apple M1 Max (arm64), pushes the top local schedule to 2.65x over exact CSC at batch width 8 with the schedule reused. Scattered updates stay below parity at every batch width measured — 0.05x at width 1 rising only to 0.15x at width 16 — which is the point: route those back to the exact path.
Source: v10 C++ harness, N=M=60,000, fill 0.90, row fanout 1, B=16 for plotted steady-state curves. Lines include schedule build amortized over repeated lookups. B=16 is the unsettled column described above; the shape of these curves — local schedules clearing parity after the first reuse, scattered ones never clearing it — holds at every width measured, the peak value is what moves.
Top line
2.65xBest measured high-locality schedule versus CSC exact delta, at batch width 8 with the schedule reused. At batch width 1 the same sweep tops out at 1.25x. Batch width 16 reads higher still, at 2.83x, but we no longer headline it — see the note below. Source: hst-highlocal-sweep-raw-20260630.csv, hst_flat_vs_csc_reuse.
Active path
10.95xPeak HST win versus active tile traversal in the same v10 sweep, one dirty tile at batch width 4. Source: hst-highlocal-sweep-raw-20260630.csv.
Sweep wins
25/30High-locality cases where steady-state HST beat CSC once the schedule is reused. Without reuse, 5 of the same 30 beat CSC. Scattered cases stay gated. Source: hst-highlocal-sweep-raw-20260630.csv.
This table is batch width 16 throughout, because the reuse-curve file behind it was only run at that width. Read it as recorded data rather than as a headline: width 16 is the column two of our sessions disagree on by about 23%, and the one where the baseline runs through a different code path than widths 1–8. The figure we lead with, 2.65x, is width 8. Source: hst-highlocal-payoff-20260630.csv.
Fixture-backed packs
Hybrid router and locality stress test using low-rank skipped-delta tile sketches under a configured error target.
A stateful Phi-cache skipped-work recovery harness exists in the tree, but as of the 2026-07-17 x86 run its benchmark entry point crashes the runtime (munmap_chunk(): invalid pointer). We are not publishing results from it and not shipping it in an evaluation pack until that is fixed.
The 60k x 60k v10 sweep behind the tables on this page: fixed operator, varied dirty-tile locality and batch width, compared against exact CSC delta. Raw CSVs are published alongside the summary.
Scattered updates should route to the exact path. The evaluation question is fallback rate and overhead on representative streams, not a universal no-cost promise.
Production context
Video frames change in localized regions. User activity clusters temporally. Simulation grids perturb around initial conditions. These are the shapes where HST should reduce realized work.
The honest evaluation includes both wins and exits: clustered streams, partly scattered streams, and cases where exact recompute remains the right route. Contact HorneSci for the full benchmark suite, raw CSVs, and customer-specific evaluation package.
Multi-threading
When many state vectors update at once, the delta-apply partitions across batch columns. We do not publish a scaling factor here; ask for the run you care about and we will measure it on your shape.
Separately, the delta-propagation rule used by the data-center telemetry hierarchy is specified and machine-checked in TLA+: the model proves that propagating deltas along affected paths yields the same aggregate as a full recompute. It is a proof about the propagation math, not about the threading implementation.
Adaptive heat demo
The heat-diffusion demo uses a 1000 x 1000 grid with a moving localized source. It compares full recompute, CSC exact delta, and HST scheduled delta while reporting latency, touched work, and error against the full path. The memory figures on that page are estimates derived from touched nonzeros, not measured allocations, and are labeled as such. Its data file carries HST’s own touched-nonzero count per frame, which is the readout the page displays; the baseline’s count is withheld for the reason given above, so the estimate is published rather than re-derivable.