We Re-ran a Published NMDA Model—Without Changing the Science

The uncomfortable test

It is easy to make a simulator look fast when you control the model. You can choose friendly equations, trim the connectivity, lower the precision, or time only the most flattering part of a run.

So I wanted a test I did not design.

The candidate was the model published by Skaar, Haug and Plesser (2025) in A simplified model of NMDA-receptor-mediated dynamics in leaky integrate-and-fire neurons. Its explicit Brian2 benchmark is exactly the kind of workload that should expose a weak execution engine: nonlinear NMDA state, dense recurrent connectivity, delays, and a largest configuration of 20,480 neurons with 754,974,720 synapses.

The question was simple:

Can our independent Brian2-compatible execution engine run the published model more efficiently while preserving what the model actually computes?

This was not an attempt to replace the paper's approximation. The difficult explicit/general formulation was the point of the test.

First rule: keep the model recognisable

I used the authors' public implementation at commit 68e6dd970cfc6bab26459fcb8c34ee0f16560d9e. The original Brian2 declarations remained the input. They passed through our frontend, versioned intermediate representation and execution plan before reaching the Rust runtime.

For the primary CPU comparison, both paths used:

• float64 arithmetic;
• fixed-step RK4 integration;
• a 0.1 ms time step;
• one second of biological time;
• the original equations, connectivity and delays;
• the same state variables and monitoring scope.

No NMDA state was removed. No smaller network was substituted. No benchmark-specific Rust kernel detected this model and quietly took a shortcut.

That constraint matters because speed without model preservation would answer a different question.

Did the dynamics survive the new path?

Before looking at speed, I compared the numerical results. Identical-event validation passed at 640, 2,560, 5,120 and 10,240 neurons.

At 10,240 neurons, the maximum voltage difference was 8.33e-17 V; the maximum NMDA-gate difference was 3.72e-15. Discrete outputs also passed the deterministic gate.

The full 20,480-neuron configuration completed with all 754,974,720 synapses retained and 28 finite public output fields. But there is an important boundary: the deterministic same-event claim ends at 10,240 neurons. A successful full-scale execution is not the same thing as a full-scale deterministic comparison.

The CPU result

The fairest headline comes from matched eight-core Linux runs. Same machine, same core budget, same numerical contract, same biological duration, and the same compiled timing region.

Figure 1. Matched eight-core CPU scaling. Each speedup compares the two execution paths on the same host and workload.

The strongest result is not a spectacular single number. It is the shape of the series: the new backend stays ahead as the workload grows, reaching 2.10× at 10,240 neurons and 1.96× at the full 20,480-neuron scale.

There was a cost. Peak memory increased by 5.5% to 8.3% across these four configurations. That trade-off belongs beside the runtime result, not in a footnote.

MPI adds a capability Brian2 does not provide natively

Brian2 can use OpenMP threads on one machine, but it does not natively distribute one simulation across multiple machines with MPI. Its documented multiprocessing approach runs independent simulations in parallel, rather than partitioning one network across nodes.

The original Brian2 path therefore has no corresponding distributed baseline. That rules out a directly matched Brian2-versus-ours MPI comparison, and it means the multi-node result below should not be read as evidence that MPI itself is ineffective.

Our runtime does support MPI, so I tested two narrower questions.

First: on the same Linux host and the same 40 physical cores at 10,240 neurons, was MPI better than the shared-memory backend? Yes. The shared-memory run took 257.774 seconds; MPI took 153.675 seconds, a 1.68× same-resource improvement.

Second: if the same 40 MPI ranks were spread from one machine across four machines at 20,480 neurons, did the run become faster? Almost not at all.

Figure 2. MPI improved the same-host execution path, while fixed-rank multi-node placement saturated.

The single-node run took 588.812 seconds. Four-node placement took 586.537 seconds—only about a 0.4% change. Communication and synchronisation happen at every time step, so moving the same 40-rank workload farther apart did not help. This was a placement test with a fixed resource budget, not a comparison against Brian2, which has no corresponding multi-node path.

This negative scaling result is one of the most useful outcomes of the reproduction. It says the next optimisation target is not “more machines.” It is the communication pattern.

There is also a practically relevant cross-configuration result. At 20,480 neurons, dividing the published-path eight-core time of 4,443.328 seconds by our 40-rank MPI time of 588.812 seconds gives 7.55×. That is the observed improvement when moving from the tested eight-core original path to our distributed-capable 40-rank configuration.

I do not label the full 7.55× as an MPI-only speedup: the execution engine, resource budget and timing scope differ. The controlled result attributable to the MPI path is the 1.68× same-host, same-40-core comparison above. The 7.55× figure answers a different, practical question: how much faster was the available MPI configuration than the tested original configuration?

What about GPUs?

CUDA and Metal runs used a separate float32 validation contract, so they should not be placed in a speedup column beside the float64 CPU result.

The recorded warm medians were:

These numbers establish working GPU paths under their own contract. They do not support “GPU versus CPU” speedup claims across different hosts, precision and measurement scopes.

A network should still behave like a network

Numerical traces are necessary, but the original work also contains a decision-making network. I reproduced the authors' NEST fixture with 400 matched exact/approximate trials at each of five coherence levels: 2,000 pairs and 4,000 simulations in total.

Figure 3. Both models reproduced the rising decision trend and sustained selective activity.

This is a functional check, not an engine speed benchmark. NEST has different simulator semantics and timing scope. Its value here is showing that the model family still produces the behaviour that motivated it—not merely finite arrays at the end of a kernel.

What I think this result establishes

The reproduction gives me confidence in four narrow claims:

1. The published explicit/general Brian2 workload can pass through the new execution architecture without a model-specific rewrite.
2. Deterministic numerical agreement is extremely close through 10,240 neurons under the matched float64 contract.
3. On the matched eight-core Linux protocol, the new CPU backend is 1.13× to 2.10× faster, including 1.96× at the full 20,480-neuron workload.
4. On the same host and the same 40 physical cores at 10,240 neurons, the MPI path is 1.68× faster than the shared-memory backend.

It also identifies a clear boundary: fixed-rank multi-node MPI placement is currently limited by timestep-level communication. That finding is just as actionable as the speedups.

What it does not establish

• Deterministic same-event validation does not extend beyond 10,240 neurons.
• GPU measurements use float32 and are not direct denominators for the float64 CPU runs.
• The multi-node test holds total MPI ranks fixed; it is a placement experiment, not increasing-resource strong scaling.
• The 7.55× cross-configuration ratio combines a different execution engine and resource budget; it is not an MPI-only attribution.
• The NEST decision fixture checks functional behaviour, not Brian2 backend performance.
• One external workload cannot establish broad compatibility with every Brian2 model.

References

Skaar, J.-E. W., Haug, N., & Plesser, H. E. (2025). A simplified model of NMDA-receptor-mediated dynamics in leaky integrate-and-fire neurons. Journal of Computational Neuroscience, 53(3), 475–487. https://doi.org/10.1007/s10827-025-00911-8

Reproduction materials

The public result package contains the execution matrix, machine-readable tables, source record and reproducibility notes.

The original research is available as an open-access full text, and the corresponding implementation is in the authors' code repository.

The upstream repository had no licence file at the commit used, so its source remains external and is not copied into the public validation package.

For me, that is the real value of this exercise. It produced more than a faster run. It produced a result with an identity, a comparison that can be challenged, and a bottleneck that is now difficult to ignore.