A spike-based chip beat a CPU at graph search, and told us exactly where its edge ends
Shortest-path search is a clean, classical computation with no neural-network fuzziness, and a single SpiNNaker 2 chip now beats a modern laptop CPU on energy per query at it on almost every graph family tested. The result matters less for route planning than for what it demonstrates about honest unconventional-computing claims.
Source: Road to scalability for efficient graph search on massively parallel neuromorphic hardware, von Seeler, Offenberg, Michaelis, Kulvicius, Luboeinski, Lehr and Tetzlaff, arXiv:2606.28907 [cs.NE], 27 June 2026. Primary source. Read: the full HTML version of the preprint, including results, discussion and methods.
What the work claims
This is a primary result paper: a new parallel algorithm, NEURO-MAPP (Neuromorphic-based Min-Add Parallel Propagation), implemented on one SpiNNaker 2 chip and benchmarked against Dijkstra's algorithm running on a single core of an M1 Pro CPU.1 The claim is that for single-source shortest-path queries, NEURO-MAPP scales favorably in runtime for many graph types once the graph is large enough, and that it consumes less energy per query than the CPU implementation in almost all cases tested. The numbers behind that claim are specific: on random graphs, the CPU wins below roughly 30,000 vertices and 360,000 edges, and the chip wins above that crossover, ending up about 25 percent faster at the maximum size that fits on one chip, around 38,000 vertices. On small-world graphs the crossover is above 38,000 vertices, with runtime growing logarithmically in graph size (fit R-squared of 89.6 percent). On a five-dimensional grid graph of 32,768 vertices and 286,720 edges the chip is about 20 percent faster. On three-dimensional grids it loses on everything that fits on the chip. On a Manhattan airspace graph of 38,392 vertices and 639,582 edges it answers a query in 6.1 milliseconds versus 6.8 milliseconds on the CPU, at 2.4 millijoules per query versus 25.5 millijoules. That last figure, roughly a tenfold energy advantage on a real task, is the headline.
How it works
The mapping is the elegant part. Every vertex of the graph becomes a small program holding one number, its current estimate of the distance from the source. Every edge becomes a message that adds its own weight to whatever distance estimate passes through it; every vertex takes the minimum of the estimates arriving from its incoming edges and updates its state. Shortest paths then emerge as the steady state of purely local parallel relaxation, with no global data structure and no priority queue. This is Bellman-Ford style relaxation executed in rounds: the chip runs 152 lightweight cores, vertices are statically assigned to cores, and a lightweight coordinator starts a new iteration once every core signals it has drained its queue. The team added two practical pieces that carry most of the engineering weight: dynamic per-iteration timing so fast cores are not held to the slowest, and vertex-degree-aware partitioning for graphs like protein interaction networks where a few hub vertices would otherwise overload one core. Inter-core hops cost 12.5 nanoseconds, so message passing is cheap.
Energy was measured, not modeled: the search was looped for five seconds per input while power was sampled, power scaled linearly with vertex count (R-squared above 99 percent), and energy per query is that average power multiplied by the measured single-query runtime. The fully loaded chip draws under 500 milliwatts; the comparison CPU draws around 4 watts. All synthetic benchmarks ran 20 trials with 95 percent confidence bands, and the real-world tasks report medians with interquartile ranges.
Where a skeptic should push
The authors volunteer the strongest objections themselves, which is rare and worth noting. First, the fairness question: a 152-core chip against one CPU core. Their answer is that task-level runtime and energy are what deployment actually pays for, and that existing parallel CPU and GPU implementations of shortest-path search are typically less efficient than Dijkstra anyway. That is defensible, but it means the result is a comparison against a deliberately sequential baseline, not against the best possible conventional system. Second, and more damaging to any hype, their own asymptotic estimate says the energy advantage should eventually close: with power scaling linearly in graph size, random-graph energy goes as n log n and grid-graph energy as n times n to the one-over-d, both comparable to or worse than Dijkstra's n log n. The measured advantage rests on the chip's very low absolute system cost, not on asymptotic superiority, and the authors say so plainly. Third, everything beyond about 38,000 vertices is extrapolation from curve fits, not measurement; the multi-chip system that would test it was not yet available to them, though a 48-chip board exists as a stated next step. Fourth, for the Isomap integration, moving the distance matrix off the chip is a stated bottleneck, and the reported runtimes exclude data transfer entirely. Fifth, the losses are real and named: three-dimensional grids and German road networks (486 of them, from OpenStreetMap) run about an order of magnitude slower on the chip at the sizes tested. This is a paper whose claims stop exactly where its measurements stop.
The honest energy bar for organoid computing
Nothing in this paper involves living tissue, yet it is one of the most useful things published this year for anyone working on organoid intelligence, for two reasons: it sets the competitive bar, and it demonstrates the accounting discipline the field must adopt. The bar first. The energy-efficiency argument for biological computing is usually made at the level of the brain's 20-watt operating point, which is the wrong comparison. This paper shows what the right comparison looks like: a milliwatt-class unconventional substrate that answers a well-posed query for 2.4 millijoules against a modern CPU's 25.5, with the measurement boundary stated, trial counts reported, and losses disclosed. Silicon spike hardware can already do that today, repeatably, on a bench, with no incubator. Any claim that an organoid rig computes more efficiently than conventional hardware will from now on be measured against demonstrations of exactly this kind, not against peak accelerator datasheets.
The deeper lesson is in where the advantage comes from. The authors' own analysis shows the energy edge is not algorithmic elegance but cheap idleness: a fully loaded chip costs under 500 milliwatts because a sleeping core costs almost nothing, while a loaded CPU core costs watts. Energy efficiency at the system level is dominated by what the whole apparatus costs when it is not doing arithmetic. Now apply that lens to a living substrate. An organoid's neural tissue does indeed idle on microwatts of metabolic power, which is genuinely attractive under this paper's logic. But the organoid never exists alone: the incubator, the perfusion pump, the heated stage, the gas control, the amplifier front end and the host computer are all part of the apparatus, and they draw power continuously, including while the tissue is idling. Under the honest accounting this paper models, that overhead is charged against every query. Today's organoid-computing demonstrations are nowhere near publishing that number, and this paper makes clear that the number, not the neuroscience, is what will be asked for.
There is a real opportunity hidden in the mechanism. Distributed relaxation, where each node holds a scalar state and repeatedly applies a local min-plus update until the network reaches a fixed point, is a computation that recurrent neural dynamics performs natively. An organoid is, physically, a dense recurrent medium with collocated memory and continuous-time dynamics, which is precisely the hardware profile this paper shows can be powerful for exactly this algorithm class. The non-obvious implication is methodological: if someone mapped a relaxation-style computation onto tissue and then benchmarked it with this paper's discipline, crossover size, confidence intervals, wall-power energy per query and disclosed losses, the result would be legible to the entire unconventional-computing community. The blueprint is sitting in this paper, waiting to be run on a substrate that is alive. The threat is equally clear: if no such measurement appears, the niche this paper occupies, sparse event-driven computation with honest energy accounting, will have been claimed by silicon, and the organoid's pitch will be reduced to the parts of computation where silicon demonstrably struggles, a set that this paper does nothing to enlarge.
The bottom line
Established result: a single 152-core SpiNNaker 2 chip, drawing under 500 milliwatts fully loaded, computes single-source shortest paths with lower energy per query than a Dijkstra implementation on an M1 Pro core for every graph family tested, and with lower runtime beyond measured crossover sizes that range from about 30,000 vertices on random graphs to never on three-dimensional grids. Established by the authors' own admission: the energy edge is a low-absolute-power effect, not an asymptotic one, single-chip capacity is about 38,000 vertices, and everything larger is extrapolation. Hypothesis: the same min-add relaxation executed on a living recurrent substrate. For organoid intelligence, this paper is the measuring stick. Confirming evidence for the field would be an organoid benchmark that reports energy per completed task with the incubator and interface inside the boundary and still wins; breaking evidence is already here, in the sense that silicon spike hardware meets that standard today and organoid computing does not yet.
Frequently asked questions
What is NEURO-MAPP?
Neuromorphic-based Min-Add Parallel Propagation, a shortest-path algorithm where each graph vertex holds a distance estimate, each edge adds its weight to passing estimates, and each vertex keeps the minimum of what arrives. The computation is pure local relaxation run in parallel rounds, mapped onto the cores of a SpiNNaker 2 chip.
How big is the energy advantage?
On the Manhattan aerial-navigation graph the chip used 2.4 millijoules per query against 25.5 millijoules for the CPU implementation, and across all four synthetic graph families the chip used less energy per query in every case. Runtime wins appear only past size-dependent crossovers, and on 3D grid graphs the chip was slower throughout.
Is comparing one chip to one CPU core fair?
Partly. The authors argue task-level energy and time are what matter and that parallel CPU or GPU versions of shortest-path search are usually less efficient than Dijkstra. It is still a comparison against a sequential baseline, and results beyond one chip's capacity are extrapolations, both of which the authors state themselves.
Why does this matter for organoid intelligence?
It shows silicon spike hardware already meets the standard biological computing aspires to: measurable energy advantage per completed task with the full system boundary counted. Any efficiency claim for computing on living tissue will be judged against demonstrations like this one.
What could an organoid offer that this chip does not?
The chip's edge comes from cheap idle power, not from its algorithm. Living neural tissue is also a continuous-time recurrent medium with collocated memory, so relaxation-style computations like min-add are physically natural to it. If such a mapping were benchmarked with this paper's accounting discipline, it would be directly comparable to silicon for the first time.
What would count as proof against the organoid pitch?
If no organoid system can report energy per completed task including incubator, perfusion and readout electronics inside the measurement boundary and still beat a digital baseline, then the efficiency argument for biological computing fails on its own terms, whatever the tissue does neurobiologically.
References
- von Seeler, O., Offenberg, E., Michaelis, C., Kulvicius, T., Luboeinski, J., Lehr, A. B. and Tetzlaff, C. Road to scalability for efficient graph search on massively parallel neuromorphic hardware. arXiv:2606.28907 [cs.NE], 2026. https://arxiv.org/abs/2606.28907. Accessed 2026-09-09.