Sparse linear algebra
spmv, csr, csc, sparse, matvec, A @ x, scipy.sparse, Eigen SparseMatrix, cuSPARSE.
Fit Test
Does HST fit your workload?
Copy the prompt below into Claude Code, Cursor, or whatever coding agent you already point at your repo. It greps the codebase, works through six questions, and comes back with a verdict. No dependencies, no code changes, nothing sent to us. If you'd rather do it by hand, the same six questions are laid out below — the process is identical.
Time~5 min by agent, ~20 by hand
Installnothing
Data sent to usnone
Passing score6 of 6
Run it with an agent
Paste this at your repo.
Works with any coding agent that can read files. It reads only — it never runs, modifies, or uploads anything. Nothing here talks to us; the whole assessment happens inside your own tooling, and the answer is yours whichever way it lands.
You are assessing whether a specific optimization applies to this codebase.
Read only — do not run, modify, or install anything.
THE PATTERN, precisely:
A large sparse operator (a matrix, or a graph with fixed edges) stays FIXED across
calls. Each step, a small and clustered part of the input changes. Some aggregate
over that operator (a sum, weighted sum, count, max, min) is recomputed from
scratch every step. When this holds, the recompute can touch only the parts of the
operator the changed inputs reach and skip the rest, exactly — no approximation.
Most codebases do NOT have this pattern. Your job is to find that out fast and say
so plainly. A confident "not a fit" is a correct and useful answer; do not stretch
to find one.
STEP 1 — Find candidate loops.
Search for code that repeatedly recomputes an aggregate over a large, unchanging
structure. Useful leads:
- sparse linear algebra: spmv, csr, csc, matvec, "A @ x", scipy.sparse,
Eigen::SparseMatrix, cuSPARSE
- whole-graph quantities per tick: rollup, propagate, recompute, refresh,
invalidate
- hierarchical aggregation: parent/child rollups, group-by over a fixed hierarchy
- fixed-topology models: grid/network models, node/edge/branch/bus tables,
sensor hierarchies
- scheduled full recomputes: a cron, timer, or stream window that reruns over
all state
Pick the three strongest candidates. For each, note file:line, what it computes,
and how often it runs. If nothing turns up, stop and report "not a fit".
STEP 2 — For the strongest candidate, answer all six. Cite file:line for each.
All six must hold. They fail independently, so five of six is a no, not a
near-miss. Answer yes / no / unsure, and say why.
1. FIXED OPERATOR. Is the matrix or graph literally the same object across
calls, values included?
No if it is rebuilt, reassembled, relinearized, or re-solved each step.
A stable sparsity pattern with CHANGING VALUES is also a no — the values
have to be fixed too. Most simulation and optimization code fails here.
2. DECOMPOSABLE AGGREGATE. Can the result be updated by adding a contribution
rather than recomputed whole?
Yes: sums, weighted sums, counts, max, min, linear combinations.
No: percentiles, quantiles, softmax, medians, distinct counts, ratios with a
moving denominator, sorting, anything downstream of a normalization. If the
SLO is a p95 or p99, treat that path as a no even if a sum sits underneath.
3. SMALL CHANGE. What fraction of the input changes per step?
Under ~5% good, 5-15% marginal, over 30% no. If the code applies per-item
events to a state store, the change is probably sparse. If it re-reads a full
snapshot each cycle, check whether most values are actually identical between
snapshots — often they are.
4. CLUSTERED AND REPEATING. Do changed items group together in the operator's
own index space, and do consecutive steps change overlapping sets?
No if scattered uniformly, or uncorrelated step to step. This fails most
often and cannot be tuned around. Proxy: does an update happen because
something occurred AT A PLACE (a site, segment, subtree) or because A PERSON
OR TRANSACTION did something? Places cluster. Transactions scatter.
5. IN-PROCESS. Is the recompute reachable as a library call from inside the
process holding the state, in code this team can modify?
No if it is inside an unmodifiable third-party product, or only reachable
over the network. This is decisive: one delta application saves well under a
millisecond, and any network round trip costs milliseconds — transport eats
the entire benefit many times over.
6. BIG ENOUGH AND COSTLY. How many distinct state variables does the operator
index? Under ~10,000, full recompute is already cheap and there is nothing
worth removing. Separately: what does the recompute cost today? Look for
benchmarks, profiling output, logged timings, performance issues, SLO
definitions. If nobody is waiting on this, the answer is no even when
everything else passes.
STEP 3 — Rule out these false positives before concluding "fit":
- Sparse data, dense computation: inputs sparse, every step still touches the
whole operator. Fails Q3.
- Already solved incrementally: a materialized view, a stream processor's
incremental operator, or an existing dirty-flag cache. Little left to gain.
- Solvers that rebuild each step: FEM, optimization, simulation loops that
reassemble or refactor per iteration. Fails Q1.
- Transactional updates: orders, sessions, messages, accounts. Scattered by
construction. Fails Q4.
- Neural network inference or training: activation and weight deltas are dense
in practice whatever the apparent sparsity. Fails Q1 and Q4.
- Small hot loop: fast and frequent, but the state behind it is small. Fails Q6.
STEP 4 — Output exactly this, and nothing else:
Verdict: strong fit / marginal / not a fit
Candidate: <file:line — what it computes, how often>
1 fixed operator yes / no / unsure — why, with file:line
2 decomposable yes / no / unsure — why, with file:line
3 change under 5% yes / no / unsure — why, with file:line
4 clustered + repeating yes / no / unsure — why, with file:line
5 in-process yes / no / unsure — why, with file:line
6 big enough + costly yes / no / unsure — why, with file:line
Cost today: <what the recompute costs, or "not established">
Deciding factor: <the one question that settled it>
Still unsure: <what you would need to measure to close the gaps>
All six yes is a strong fit. One or two unsure and the rest yes is marginal.
Any no is a no. Do not soften a no.
The pattern
What HST actually does.
HST accelerates one narrow pattern:
A large sparse operator — a matrix, or a graph with fixed edges — stays fixed. Each step, a small and clustered part of the input changes. Some aggregate over that operator (a sum, a weighted sum, a max) has to be recomputed, and today it's recomputed from scratch.
When that holds, the recompute can touch only the parts of the operator the changed inputs reach and skip everything else. The result is exact — the same answer full recompute gives, to floating-point roundoff. Not an approximation.
Most codebases don't have this pattern. The point of this page is to find that out fast.
Step 1
Find the loop.
You're looking for code that repeatedly recomputes an aggregate over a large, unchanging structure. Things that tend to lead there:
Whole-graph quantities per tick
Rollups, propagation, recompute, refresh, invalidate.
Hierarchical aggregation
Parent/child rollups, group-by over a fixed hierarchy.
Fixed-topology models
Grid or network models, node/edge/branch/bus tables, sensor hierarchies.
Scheduled full recomputes
A cron, timer, or stream window that reruns over all state.
Pick your three strongest candidates. Note where each one lives, what it computes, and how often it runs. If nothing turns up, you're done — HST doesn't apply.
Step 2
Six questions.
All six have to hold. They fail independently, so five out of six is a no, not a near-miss. Answer as you go — the verdict at the bottom updates live, and nothing you enter leaves your browser.
Is the operator fixed?
Is the matrix or graph literally the same object across calls, values included?
- Yes
- Topology and coefficients load once and get reused across many computations, and changes arrive as occasional configuration events rather than per-step.
- No
- It's rebuilt, reassembled, relinearized, or re-solved each step.
Most simulation and optimization code fails right here — the operator changes every iteration by design. A stable sparsity pattern with changing values is also a no; the values have to be fixed too.
Your answer
Does the aggregate decompose?
Can the result be updated by adding a contribution, instead of recomputed whole?
- Yes
- Sums, weighted sums, counts, max, min, and linear combinations of those.
- No
- Percentiles, quantiles, softmax, medians, distinct counts, ratios with a moving denominator, sorting, and anything downstream of a normalization.
If the SLO you care about is a p95 or p99, treat that path as a no even if there's a sum underneath it.
Your answer
Is the change small?
What fraction of the input actually changes per step?
- Yes
- Under ~5% is good. 5–15% is marginal.
- No
- Over 30%. Somewhere around two-thirds of state changing per step, plain full recompute wins outright.
If the code takes per-item events and applies them to a state store, the change is probably sparse. If it re-reads a full snapshot each cycle, check whether most values are actually identical between snapshots — often they are.
Your answer
Do the changes cluster, and repeat?
Do the changed items group together in the operator's own index space, and do consecutive steps change overlapping sets?
- Yes
- Changes group by region, subtree, or segment, and one step's changed set looks a lot like the last.
- No
- Scattered uniformly, or the changed set is uncorrelated step to step.
This is the one that most often fails, and there's no way to tune around it. Quick proxy: does an update happen because something occurred at a place — a site, a segment, a subtree — or because a person or transaction did something? Places cluster. Transactions scatter.
Your answer
Can you call it in-process?
Is the recompute reachable as a library call from inside the process that holds the state, in code your team can modify?
- Yes
- You can link a library into the process that owns the state and call it directly.
- No
- It's inside a third-party product you can't change, or the only way to reach it is over the network.
This one is decisive. At realistic sizes a single delta application saves well under a millisecond, and even an in-datacenter round trip costs tens of milliseconds — the transport eats the entire benefit many times over. This is why HST ships as an embedded library and not as a hosted service.
Your answer
Is it big enough, and is it costing you?
How many distinct state variables does the operator index — and what does the recompute cost today?
- Yes
- Well over ~10,000 state variables, and there's evidence somebody is waiting: benchmarks, profiling output, logged timings, performance issues, an SLO.
- No
- Under ~10,000 the full recompute is already cheap and there's nothing worth removing. And if nobody is waiting on this, the answer is no even when everything else passes.
A faster version of something nobody waits for is worth nothing.
Your answer
Step 3
Check it isn't a false positive.
These look like fits and aren't:
Sparse data, dense computation
Inputs are sparse, but every step still touches the whole operator. Fails Q3.
Already solved incrementally
A materialized view, a stream processor's incremental operator, or an existing dirty-flag cache is already doing this. Little left to gain.
Solvers that rebuild each step
Finite element, optimization, simulation loops that reassemble or refactor per iteration. Fails Q1.
Transactional updates
Orders, sessions, messages, accounts. Scattered by construction. Fails Q4.
Neural network inference or training
Activation and weight deltas are dense in practice whatever the apparent sparsity. Fails Q1 and Q4.
Small hot loop
Fast and frequent, but the state behind it is small. Fails Q6.
Step 4
Write it down.
A few lines is enough. This worksheet fills in from your answers above — copy it into your own notes, or paste it into a discovery email.
All six yes is a strong fit. One or two unsure, rest yes, is marginal. Any no is a no.
Where this could go
The narrowness is mostly a software limit.
Everything on this page is HST in software today. Software can only exploit structure that's coarse and stable, which is what makes the six questions strict. Hardware relaxes that. Fine-grained dependency tracking, sparse-aware scheduling, locality-aware caches, and specialized data movement could reach patterns software can't justify chasing: smaller deltas, looser clustering, operators where recompute was never expensive enough to bother in the first place.
Whether that broadens where HST wins, and by how much, is an engineering question. It takes building and benchmarking to answer, and we won't put a number on it in advance. If your workload came close on the six questions, that's reason enough to talk.
What's next
Either answer is a complete answer.
Marginal or strong fit — the next step is measurement, which this assessment deliberately skips. What settles it is a trace of real updates: for each step, which state variables changed. Dirty fraction, clustering, and step-to-step stability all fall out of that directly, and they turn every "unsure" above into a number.
Not a fit, or not sure — still worth a short conversation. A no on one workload doesn't say much about the next one, and the six questions are easy to read too strictly on your own. We look at this pattern all day. Half an hour usually settles whether there's anything here, sometimes on a workload you hadn't thought to test.
Book a discovery call and bring the worksheet. You'll get a straight answer either way, and if there's a fit anywhere in your stack, this is the fastest way to find it.
Answer the six questions.
Nothing is sent anywhere. The verdict updates as you go.