Skip to content

Repository files navigation

Connectome Energy Optimization — Neuromorphic Transition

Languages: Türkçe · Deutsch · Français · Español


This repository documents a complete software optimization research phase on connectome-scale spiking neural network simulation. It reports what worked, what did not, and where the hard ceiling is — with measured numbers, not speculation.


Table of Contents

  1. What This Is
  2. Research Question
  3. Methodology
  4. Benchmark Results
  5. What Worked
  6. What Did Not Work
  7. The Software Ceiling
  8. Limitations and Honest Assessment
  9. Why Neuromorphic Hardware Is Next
  10. Repository Structure
  11. Running Benchmarks
  12. Literature

What This Is

A research project studying the energy cost of simulating biologically realistic spiking neural networks on general-purpose CPU/GPU hardware.

The biological model is the FlyWire whole-brain connectome of Drosophila melanogaster: 139,255 neurons and approximately 54.5 million synapses, reconstructed from electron microscopy data (Dorkenwald et al., Nature 2024).

The project does not propose a new neural network architecture, a new training algorithm, or a new machine learning application. It asks a narrower question: how much energy does it take to run a biologically faithful simulation of a real connectome, and can that cost be reduced substantially on hardware that exists today?

This is hardware-agnostic research into execution models for spiking network simulation. The results are reported from a single workstation. They are not claimed to generalize beyond the tested hardware and the tested biological regime.


Research Question

Can connectome simulation be shifted from timestep-centric dense matmul execution to event-centric sparse message-passing execution, while preserving biological fidelity — and can that execution model eventually scale to mouse-level connectomes on commodity hardware?

The primary metric throughout is:

joules_per_bio_second  (J/bio-s)

The energy in joules consumed to simulate one second of biological time. Lower is better.

The acceptance rule, applied without exception to every experiment:

ACCEPT  =  (joules_per_bio_second decreases)  AND  (parity_pass = true)

A result that reduces energy but breaks biological fidelity is rejected. A result that improves speed but does not reduce energy is not considered success.

Parity definition

Strict parity (the acceptance gate used throughout this phase):

  • Spike count within tolerance band vs. CPU reference
  • Active neuron ratio within tolerance
  • Spike timing deviation within tolerance
  • Intervention response consistency

Functional parity (used only for exploratory approximation research):

  • Regional and circuit firing-rate regime preserved
  • Dominant activity motifs preserved
  • Behavioral response direction and magnitude preserved

Functional parity does not substitute for strict parity as an acceptance criterion.


Methodology

Hardware

Single workstation. Power measured via HWiNFO64 sensor polling (see docs/cpu-guc-olcumu-hwinfo64.md). All reported energy figures are wall-power measurements, not hardware performance counter estimates.

Benchmark protocol

  • Biological duration: 10 seconds (primary), 1 second and 0.1 second for smoke tests
  • Run kind: warm (setup excluded from energy measurement, 2 runs)
  • Timestep: dt = 0.1 ms (100,000 steps per 10 bio-seconds)
  • Reference: Brian2 CPU simulation of the same model, same timestep, same connectivity
  • Parity gate: every candidate is checked against the CPU reference before any energy result is accepted

All benchmark runs are defined by JSON manifests in benchmarks/manifests/. Results are fully reproducible from the manifest plus the data in third_party/fly-brain/.

What "accepted" means

A result marked ACCEPTED in the tables below passed the parity gate and showed reduced energy compared to the prior accepted baseline. A result marked REJECT passed neither, or passed one but not the other. Analysis steps did not produce a candidate; they produced measurements used to bound future experiments.


Benchmark Results

All values are joules_per_bio_second (J/bio-s), warm 10-second run, measured on a single workstation.

Main optimization trajectory

Step Approach J/bio-s Decision Key finding
Baseline Brian2 CPU (reference) 4,367 Reference Starting point
Step 3/4 Event-driven v1 (PyTorch) 772 ACCEPTED 82.3% reduction; most gain from work reduction, not kernel tuning
Step 5.4 Fanout-sorted exact 716 ACCEPTED Same edge count, lower per-edge traversal cost
Step 5.5 Mixed-fidelity v1 709 ACCEPTED Community 6 exact, Community 4 mixed, remainder mean-field
Step 6.1 Lazy rate primitive 704.67 REJECT Primitive went lazy; skip space did not open; gain within noise
Step 6.2 Core activation density Analysis Core is recurrently self-sustained; skip gates cannot fire
Step 6.3 Core step-fixed cost profile Analysis Software ceiling ~424 J/bio-s; target band unreachable

Target band: 87–145 J/bio-s. This band is not arbitrary; it is the estimated requirement for the same execution model to remain viable at mouse-scale connectome size on single-node commodity hardware.

Rejected GPU-native variants (Step 5, event-driven path)

These were all tested against the same accepted event-driven baseline (772 J/bio-s):

Variant J/bio-s vs. baseline
Grouped scatter 1,972 +155%
Active index compression 1,304 +69%
CUDA extension v1 831 +8%
CUDA extension kernel redesign 1,017 +32%
Prefetch Python loop ~770 ≈ baseline
Community-aware exact prototype 1,964 +154%

None of these beat the baseline. The community-aware prototype organized work differently but did not reduce work.


What Worked

Event-driven execution mode

The single largest gain came from switching the execution model, not from any kernel improvement.

  • Standard PyTorch (dense matmul): 5,362 J/bio-s
  • Accepted event-driven (sparse frontier): 772 J/bio-s
  • Reduction: 85.6%

Why: the FlyWire connectome is extremely sparse in activity. Across 100,000 timesteps, the simulation averages 3.476 active spikers per step out of 139,255 neurons (0.0025% active per step) and 532.973 traversed edges per step out of 54.5M synapses. Updating the full weight matrix every step is overwhelmingly wasted computation.

In the standard CUDA path, recurrent_matmul alone consumed 65.2% of total wall time. Switching to event-driven execution eliminates this for the vast majority of steps.

Fanout-sorted edge ordering (Step 5.4)

Sorting presynaptic neurons by fanout before traversal reduced per-edge memory access cost without changing the edge count or fidelity. Small but real gain: 772 → 716 J/bio-s.

Mixed-fidelity approximation (Step 5.5)

Replacing peripheral community activity with mean-field approximations while keeping the highest-activity community exact produced a measurable further reduction: 716 → 709 J/bio-s. Parity was maintained under the functional parity definition for the approximated communities.


What Did Not Work

Kernel engineering on the event-driven path

After switching to event-driven execution, the dominant cost shifted from GPU matmul to Python/host orchestration overhead (~67% of wall time in the event-driven profile). Writing custom CUDA kernels addressed the wrong layer; the overhead is not inside the kernel, it is in the Python dispatch loop surrounding it. Every custom CUDA variant produced worse energy than the accepted event-driven baseline.

Community-aware exact scheduling

Organizing computation by community (reordering, local buffers) did not reduce the amount of work performed. The community structure helps locality but not work count. The prototype ran at 1,964 J/bio-s, worse than the 772 J/bio-s baseline.

Lazy / deferred rate primitive (Step 6.1)

Making the rate computation lazy (only compute when inputs change) worked mechanically but did not open skip space, because the core domain fires almost every step. Gain was within noise; rejected.

Step skipping (Step 6.0 analysis)

The analysis found that output-empty steps exist (steps where no postsynaptic neuron receives enough current to spike), but state-dynamics-empty steps are almost nonexistent. The network state evolves on every step regardless. Skip gates cannot be reliably armed.


The Software Ceiling

Step 6.3 profiled the step-fixed cost blocks — the blocks that run every timestep regardless of spiking activity — on the accepted rate-approximation path:

Block Time (s) Share of total
Spike mask / bookkeeping 41.47 12.36%
Neuron update (v, g, reset) 35.34 10.54%
Refractory tracking 18.03 5.37%
Delay release/decay 14.87 4.43%
Delay write 9.96 2.97%
Delay roll 9.87 2.94%
Total step-fixed ~129.5 ~38.6%
Event-driven recurrent input 182.05 54.28%

These blocks operate over dense [batch, neurons] or [batch, delay_len, neurons] tensors. Their cost is proportional to the number of neurons in the domain, not to the number of active spikes. They cannot be skipped without changing the simulation semantics.

Theoretical ceiling calculation

Current accepted energy: 690.96 J/bio-s (rate approximation path)

  • If the heaviest single block (spike mask) were completely removed: ~605 J/bio-s
  • If all step-fixed blocks were completely removed: ~424 J/bio-s

424 J/bio-s is the software ceiling. Even if every dense state-update block could be eliminated at zero cost — which is not physically possible — the result would still be 3× above the target band of 87–145 J/bio-s.

Why the core cannot be bypassed

Step 6.2 measured the exact core activation density across 100,000 steps:

Metric Value
Steps with zero core events 8,589 (8.6%)
Typical step 2–3 exact events
Mean burst length 11.67 steps
Mean quiet length 1.10 steps
Stimulus-only steps 11,518
Recurrent-only steps 33,963
Both stimulus and recurrent 45,930

The core is recurrently self-sustained: 45,930 out of 100,000 steps had both external stimulus-driven and network-internal recurrent activity simultaneously. Silencing the stimulus does not silence the core. Average quiet intervals are 1.1 steps long — there is no contiguous quiet window to exploit for skipping.

The top 10 most active core neurons each fire approximately 4,065–4,122 times across 100,000 steps, a mean rate of ~40 Hz. They are not passive relay nodes; they are part of a dense recurrent circuit that sustains its own activity.


Limitations and Honest Assessment

Single model, single hardware, single activity regime. All measurements were made on one workstation, using one connectome (fly), under one stimulation protocol. Generalization to other connectomes, other hardware, or other activity regimes is not demonstrated.

The ~6.3× reduction is real but context-dependent. The baseline comparison is Brian2 CPU, which is a correct but not hardware-optimized simulator. Comparison to a hand-tuized CUDA-native Brian2 or a dedicated SNN simulator might yield a smaller improvement ratio. The absolute values (J/bio-s) are hardware-specific.

The target band of 87–145 J/bio-s is an extrapolation. It is derived from mouse-scale proxy assumptions (activity rate, edge count, commodity hardware envelope) using the same execution law. If those assumptions are wrong, the target shifts. The ceiling conclusion (424 J/bio-s) is a measured fact; the claim that this is insufficient rests partly on an extrapolation.

Mixed-fidelity approximation breaks strict parity. Steps 5.5 onward use functional parity, not strict parity, for the approximated communities. The approximated communities produce different spike patterns. Whether this is biologically acceptable depends on the scientific question being asked. It was accepted here as a research direction, not claimed as a validated biological model.

Parity measurement is against a software CPU reference, not a biological ground truth. Strict parity means "matches the reference Brian2 CPU simulation." Whether the reference simulation itself is biologically accurate is a separate question not addressed here.

The 424 J/bio-s ceiling assumes the current execution structure. A radically different algorithm (not incremental optimization of the current event-driven approach) could, in principle, have a different ceiling. This is not claimed to be the absolute lower bound of all possible software approaches.

The neuromorphic transition has not been prototyped. The Loihi 2 / Lava pathway is identified as the rational next step based on the software ceiling analysis, but no Lava code was written, no Intel hardware was accessed, and no energy measurements on neuromorphic hardware were made in this phase. The transition argument is analytical, not empirical.


Why Neuromorphic Hardware Is Next

The software phase exhausted the accessible optimization axes:

Axis Status
Graph work reduction (event-driven) Exhausted — at biological floor (~533 edges/step)
Per-edge cost reduction Plateau — marginal diminishing returns
Peripheral approximation Effective, included in accepted path
Core skip / lazy gates Blocked by recurrent self-sustaining dynamics
Core fixed-cost reduction Necessary but not sufficient; ceiling at 424 J/bio-s

The target band (87–145 J/bio-s) requires approximately 3–5× further reduction from the software ceiling. That reduction cannot come from software restructuring of dense state tensors on von Neumann hardware. It requires changing the substrate.

Neuromorphic processors such as Intel Loihi 2 process spikes as native events, maintain neuron state on-chip without DRAM round-trips, and do not execute a global dense update every timestep. The step-fixed costs that form the software ceiling are not step-fixed on neuromorphic hardware — they are event-triggered. This is why the analysis points to Loihi 2 / Lava as the next phase.

What maps naturally to Lava

The current Community-Aware Hybrid execution model has components that translate directly and components that require re-engineering:

Component Lava mapping
Exact core LIF neurons Natural → LIF-like Process
Spike-driven routing Natural → Dense / spike port connections
Community shards Natural → Process groups
Two-level scheduler Requires custom host orchestration
Mixed-fidelity mean-field layer Requires custom rate/aggregate Process
Delay wheel semantics Requires redesign
Benchmark harness Stays external; adapter layer needed

The transition is a re-architecture problem, not a port.


Repository Structure

.
├── README.md                          # This file (English)
├── README.tr.md                       # Turkish
├── README.de.md                       # German
├── README.fr.md                       # French
├── README.es.md                       # Spanish
├── proje-ozeti-2026-03-27.md          # Strategic summary memo
│
├── artifacts/
│   ├── input_semantics_diagnostics/   # Input parity diagnostic snapshots
│   ├── parity_diagnostics/            # Spike parity analysis outputs
│   ├── profiling/                     # CUDA and Python profiling JSONs
│   └── research/                      # Per-step smoke logs, CSVs, metrics
│
├── benchmarks/
│   ├── manifests/                     # Benchmark run definitions (JSON)
│   └── results/                       # Run outputs — gitignored (large, reproducible)
│
├── cuda_extensions/
│   └── fused_recurrent/               # Custom CUDA kernel source (cpp + cu)
│
├── docs/
│   ├── research/                      # Weekly research memos, Weeks 1–6
│   ├── step5-*.md                     # Step 5 experiment documentation
│   ├── step6-*.md                     # Step 6 experiment documentation
│   ├── execution-model-rfc-v0-2026.md # Community-Aware Hybrid engine design
│   ├── research-charter-2026.md       # Project charter with acceptance rules
│   └── enerji-odakli-arastirma-cercevesi.md
│
├── scripts/
│   ├── run_energy_benchmark.py        # Main benchmark runner
│   ├── build_*_metadata.py            # Community partition metadata builders
│   ├── diagnose_*.py                  # Parity and semantics diagnostics
│   └── profile_*.py                  # Profiling scripts
│
├── tests/
│   └── test_energy_benchmark.py
│
├── tools/
│   ├── energy_benchmark/              # Benchmark library (campaign, manifest, power, quality)
│   └── cuda_extensions/               # Extension loader
│
└── third_party/
    └── fly-brain/                     # [submodule] eonsystemspbc/fly-brain

Running Benchmarks

Prerequisites: Python 3.11+, PyTorch with CUDA, the fly-brain submodule initialized (git submodule update --init), and HWiNFO64 running with sensor polling enabled for real power measurement.

Run a benchmark:

python scripts/run_energy_benchmark.py \
  --manifest benchmarks/manifests/warm10-pytorch-event-driven-current.json

Run a parity smoke test:

python scripts/run_energy_benchmark.py \
  --manifest benchmarks/manifests/parity-smoke-pytorch-event-driven-vs-cpu.json

Build the CUDA extension (Windows):

scripts\build_fused_recurrent_extension.bat

Results are written to benchmarks/results/ (gitignored). Each result directory contains the manifest snapshot, raw metric CSV, and run logs.


Literature

Connectome data

Exact event simulation

Graph execution engines

Mixed-fidelity / approximation


Status

Software phase: complete. Steps 3 through 6.3 are finalized. The software ceiling is measured at approximately 424 J/bio-s. The target band of 87–145 J/bio-s is not reachable through further software optimization of the current execution model on this hardware.

Next phase: Lava / Loihi 2 feasibility study. Not started. No neuromorphic hardware measurements exist in this repository.


Birusk Çiğdem — Rusk Agency Software phase completed: March 2026

About

Connectome-scale SNN simulation energy benchmarks — software ceiling analysis for Drosophila whole-brain on GPU

Topics

Resources

Stars

2 stars

Watchers

0 watching

Forks

Releases

Contributors

Languages