The Neulite kernel is a Minimum Viable Product (MVP). The functionality provided by the official kernel is limited to: (1) calculating synaptic input, (2) calculating ion channels, (3) calculating calcium concentration, (4) calculating the cable equation (membrane potential), (5) detecting spike firing, and (6) propagating spikes. It is not a “Swiss Army knife” like NEURON or Arbor. Fundamentally, that’s because tasks other than those are the responsibility of the front-end (BMTK and bionet_lite), but there are other reasons as well.
Reason 1 We want to finish calculations even one millisecond faster. Many general-purpose simulators are fast, but they aren’t the fastest. This is because computational speed depends not only on the simulator but also on the model’s structure and scale, and the architecture of the machine running it.
For example, a random network is faster with NEST-style parallelization (random partitioning, round-robin distribution), while a network with dense local connections and sparse long-range connections is faster with MONET-style tile partitioning. If the neural firing rate is low, dynamic time-stepping is effective. If the system is not ‘stiff’ (Stiffness), an explicit method can be used. With GPUs, available techniques differ by generation, and parameters must be adjusted to the network scale (to avoid register spilling). Even on “Fugaku,” code must be written with awareness of loop tiling and cache blocking to prevent overflows from L1 and L2 caches.
In short, achieving the absolute fastest speed requires writing dedicated code. This isn’t possible with general-purpose simulators; in fact, to my knowledge, no simulator based on that concept even exists. Therefore, what is needed is a framework that is “fast enough as-is, but allows for optimization to the absolute limit.” This means concise C code with a clear data structure. That is the Neulite kernel.
Reason 2 The YAGNI principle. We do not want the responsibility of implementing features we do not use. Necessary features should be implemented by the people who need them and understand them best. For this reason, we have kept the kernel extremely simple.
Even if it seems difficult to do on your own right now, we plan to hold tutorials and workshops regularly. You can participate in these and implement new features while consulting with us. The kernel’s source code license is GPLv2, so if you add functionality, please share the code under GPLv2 for the sake of those who follow.
Reason 3 By strictly adhering to the MVP concept, the official kernel is only about 2,000 lines of code (and the MPI version around 2,500 lines). This means the entire kernel can be fed to an LLM for modification. For example, tasks like implementing a custom ion channel can likely be handled by an LLM, eliminating the need to do it manually.
Reason 4 It is extremely difficult for a single simulator to scale efficiently from a single-neuron simulation up to a whole-brain simulation. If the model scale is small (a few thousand compute nodes), it may be fine for all nodes to read a single configuration file. However, when running a whole-brain simulation on the entire “Fugaku” system, you must prepare configuration files for each node in advance, containing only the data that specific node needs to compute. If you don’t, file I/O will become a bottleneck, computation will halt, and the data simply won’t fit into memory.
In other words, a “one size fits all” strategy does not work. What is needed is a strategy where “simple things should be simple, and complex things should be possible.” This is why the official kernel will remain an MVP.
All extended kernels will be provided as “flavors,” separate from the official (“vanilla”) kernel.