Results — HorneSci

Headline

Throughput: 15–21×
Processor load: −38%
Memory: −61%
Freshness: 102×

Intel Core i7 node, clocks pinned, 2026-07-18. Sustained throughput on this run hit the limit of the surrounding test rig. The two throughput figures are medians over 21 timed windows: 15× over all of them, then 21× over the last ten, once the run had settled — not a spread with the truth somewhere in between. Each of these four figures, and the window-by-window throughput the first one is a median of, are published as recorded: summary, every window.

What changes

Before and after.

Before, the system rebuilds its whole result every cycle, whether or not much of the input moved. After, it keeps the part of the result that nothing touched and rebuilds only the part that changed. The output is identical to the bit, so nothing downstream has to be re-checked. It is a deployment result rather than a result about our method: six things changed between the two runs and five of them are architecture — how the work is split, moved and stored — with only the final combining step ours. We did not run the third arm that would separate the two, so our own share of the 15× is not established here.

The heat demonstration below is one step of that: 10.7 ms to rebuild a million-cell field, 0.23 ms to update it, with about 2% of the field moving.

When the gain appears

Where it fits, and where it does not.

When it does not fit, this is slower than doing nothing: roughly half the speed of a good existing implementation when nothing moves between cycles. We publish that case because a site showing only its wins is the one a careful reader stops believing.

The question is asked per step of your computation, not of the whole program. One program can be part in and part out. A step that does not qualify runs whole and reports what moved, and the steps after it can still take the short path. That is a regime, not a failure, and it is what the runtime does on its own at run time from timings it measures on your machine.

Ask, per step	What it means
Is the operator fixed between cycles?	Whatever the step runs over keeps its shape and its values between cycles: the same grid, the same network, the same weights. The input moves; the operator does not. If it is rebuilt, reassembled or re-linearized each cycle, there is nothing to carry forward. This is the most common no, and it is unchanged. The operator does not have to be sparse; a dense one qualifies.
What fraction of its input changes, where the operator reads it?	Against a tuned library the break-even sits at roughly six to ten percent of the input. Below that the short path wins; above it, it loses and should. This is the one question that wants a measurement rather than a conversation.
Does anything merge the changes before that point?	A step that runs over a batch or a sequence in one call sees the union of everything that moved across every position in that call, and the union is far denser than any one position. We measured a case with two to six percent moving per position and fifty to seventy percent moving in the union, which is a loss. Ask what a batch counts: independent updates that share one setup, which helps, or positions that share one call, which hurts.
Does the step run enough times to pay for its setup?	Preparing the operator once costs on the order of fifty to a hundred and twenty applies to earn back, measured on large dense weights. A step that runs a handful of times is not worth preparing.
Is the expensive step a sum, not a solve?	If the cost is a factorization or a forward/back substitution, solving for unknowns rather than adding known contributions up, none of the rows above rescue it. We have measured a real power-system library where everything else held and it was still a no.
Does the state live in one process?	We link into the program already holding the data. The saving is well under a millisecond a call, which a network hop would erase.

An assessment walks your own computation step by step and measures how far each one sits from these on your own hardware, before anything is committed. Nothing is sent to us.

By workload shape

Selected results.

Measured wall-clock improvement, each row against the baseline named beside it. A ratio without its baseline is not a result.
Workload	What it does	Compared against	Result
Sensor hierarchy rollup	Readings rolling up continuously through a fixed six-level group hierarchy — the shape a grid or plant monitoring loop has. Measured on Theodolite’s published UC4 streaming benchmark, not on a system in production.	The benchmark’s own stock implementation, on the same machine.	15–21×
Physical field updates	A million-cell heat field with a moving source, about 2% of it moving per step. Same run as the demonstration below.	Rebuilding the field from scratch each step. Against a hand-written incremental version instead, the same run gives 1.3×.	47×
Camera analytics	Fixed-camera video analysis on live streams. The gain tracks how heavy the per-region work is; on light analytics this loses, because decoding the video dominates.	Reprocessing the whole frame, every frame.	2.8–17.6×
Sensor fusion	Industrial identification streams fused in real time. A second reader type on the same pipeline measured 6.8×; a camera-heavy variant of it lost.	Re-fusing the full state on every reading.	9.9×
Fluid simulation	Two-dimensional smoke, about 5% of cells active per step. Past roughly a fifth of the grid moving it stops winning, which is the small-part condition doing what it says above.	A hand-written incremental version that tracks its own active cells. Against a from-scratch rebuild the same run gives 8.8×.	3.7×

The sensor hierarchy rollup row is published in full, window by window, under /benchmarks/, alongside the reuse sweeps and the recorded run behind the heat demonstration.

Working demonstrations

Run it yourself.

These run in your browser, on data recorded from real hardware.

Video: 2.8–17.6×
Heat diffusion: 10.7 → 0.23 ms
Raw data: CSV

How we measure

How the numbers are taken.

Before and after in the same process, in the same run.
Compared against two baselines: the path the system runs today, and a tuned incremental version written by hand.
Each report names the hardware, the date, the workload size and the settings used.
Results checked against the original computation for exactness.

Get this number for your own workload.

An assessment puts your own system on the bench and reports what it could run at. It starts with a call.

Book a discovery call →

How engagements work