Where Sparsr fits
The application areas we have surveyed in depth, what each one needs from the machine, and — just as usefully — what Sparsr is not for.
The shape of a problem that suits Sparsr
Not a market list. These are the domains we have taken apart kernel by kernel, and what each one would actually run on.
-
Cheminformatics
All-versus-all similarity screening over molecular fingerprints. A 4096-bit fingerprint is one wide register, and against a transposed library the kernel needs only the wide logic and load/store instructions Sparsr already has. Our reference kernel matches RDKit exactly across every pair we have checked.
-
Hyperdimensional computing
A hypervector is one register rather than a tiled array, which removes most of the code that makes VSA implementations awkward on a CPU. Binding runs today; bundling and similarity search want the reduction unit and the rotate from the roadmap.
-
Quantum error correction
Stabilizer simulation and Pauli-frame sampling are wide XOR plus a population count. The working set for frame sampling is small enough to sit in on-chip memory, which is exactly the case a wide machine handles well.
-
Logic and fault simulation
Bit-parallel fault simulation puts one test pattern in each bit of a wide word, which is the cleanest zero-gap fit we have found: the kernel is pure wide bitwise logic on the instruction set as it stands.
-
Genomics and bioinformatics
Three kernels at three different costs. Bitsliced k-mer search runs on today's instruction set; population-count-based genotype work and bit-parallel sequence alignment each wait on a roadmap primitive.
-
Error-correcting codes
The purest arithmetic fit in the survey: addition over GF(2) is WXOR and multiplication is WAND, with no translation in between. Syndrome computation wants a parity reduction; quasi-cyclic codes want the wide rotate.
What runs today, and what is still being built
Two separate questions, so two columns. Hardware says whether the kernel is expressible on the instruction set as it stands. Access says what using it looks like from your side — and today, for every one of these, that still means a kernel someone has to write.
| Application area | Hardware | Access |
|---|---|---|
| Cheminformatics — fingerprint screening | ✅ Runs today | ⌨️ Custom kernel |
| Logic and fault simulation | ✅ Runs today | ⌨️ Custom kernel |
| Genomics — bitsliced k-mer search | ✅ Runs today | ⌨️ Custom kernel |
| Statistical physics — multi-spin Monte Carlo | ✅ Update kernel runs today; bit-parallel RNG needs the wide rotate 🚧 | ⌨️ Custom kernel |
| Hyperdimensional computing and VSA | 🚧 Needs the raw load/store path, the reduction unit and the rotate | 📦 Library in development |
| Quantum error correction and stabilizer simulation | 🚧 Needs the reduction unit | ⌨️ Custom kernel |
| Error-correcting codes | 🚧 Needs a parity reduction mode; quasi-cyclic codes also need the rotate | ⌨️ Custom kernel |
| Binary neural networks | 🚧 Needs the reduction unit and a wide XNOR | ⌨️ Custom kernel |
| Bitmap-index analytics and sparse query indexing | 🚧 Needs the reduction unit and a bit-granular container format | ⌨️ Custom kernel |
| Robotics — offline place-recognition and sensor fusion | 🚧 Downstream of the hyperdimensional computing work; needs no hardware of its own | 📦 Follows the HDC library |
Reading the two columns
The distinction that decides whether you evaluate Sparsr now or later.
-
✅ Runs today
The kernel is expressible on the instruction set as it stands — nothing in the hardware roadmap is in the way. This is where an evaluation is cheapest to start, because the only thing between you and a result is the kernel itself.
-
🚧 Being built
The kernel needs a wide instruction that does not exist yet. Each one is a tracked piece of work rather than an aspiration, and the architecture page lists them. Nothing here is blocked on anything but our own build order.
-
⌨️ Custom kernel
Using Sparsr for this today means writing the wide-data inner loop yourself, in assembly or in C/C++ through the intrinsics header. The free emulator means you can do that now, without hardware.
-
📦 Library in development
We are building a library that carries the kernels for you, so you write ordinary domain code and never touch the wide registers. The first is a PyTorch device for Torchhd. It is not released yet — this column says what is coming, not what you can install today.
-
Not on the list?
The pattern generalises: if your domain has a standard library with a stable set of inner loops, that library is exactly the kind of thing worth putting a Sparsr backend behind. Which one we build next is a conversation, not a fixed plan.
What Sparsr is not for
Every one of these is a genuine architectural mismatch rather than a gap we intend to close, and saying so is more useful to you than another row in the table above.
-
Floating-point numerics
Sparsr has no floating-point unit and is not getting one. If the values in your sparse matrix are real numbers rather than bits, this is the wrong machine — including for sparse linear solvers and for most scientific simulation.
-
Dense integer matrix multiply
Once operands are 8 bits or wider, a wide bitwise datapath is the wrong shape for the multiply-accumulate involved. Dense GEMM, and the neural network inference built on it, belong on a GPU or a tensor unit.
-
Pointer-chasing traversal
Graph traversal and index structures whose cost is fine-grained gather and scatter are bound by memory latency, not by how wide a register is. Width does not help, and we do not claim it does.
A missing instruction is not a rejection
Sparsr's instruction set is designed to grow, and adding a wide primitive is normal roadmap work rather than an exception. So if your kernel is bitwise, wide and sparse, the interesting question is not whether Sparsr can run it today — it is what it would cost to make it run well.
That conversation is the most useful thing we can offer a research group right now, and it is free.