Hi everyone!
I’m Mrigesh Thakur, a GSoC 2025 contributor, and I’m incredibly excited to work on Project #8: Replace Brian’s Just-In-Time Compilation Mechanism under the mentorship of Marcel Stimberg, Dan Goodman, and Benjamin Evans.
What This Project Is About
Brian currently uses Cython for runtime JIT compilation, but this approach introduces significant compilation delays and maintenance overhead. The project aims to:
- Replace Python/Cython-based runtime data structures (like dynamic arrays, spike queues) with their C++ counterparts.
- Enable direct memory sharing between Python and C++ with minimal overhead.
- Optimize performance by eliminating redundant Python/C++ boundary crossings.
- Potentially explore alternatives to Cython like lightweight weave-like compilation backends.
The goal is to streamline the runtime backend, reduce compilation bottlenecks, and improve simulation performance while preserving the flexibility and interactivity that Brian is known for.
More Details
You can find a detailed write-up here:
Proof of Concept + Research Repo
Would love to hear any suggestions, feedback, or ideas you might have related to this direction!
Looking forward to learning from and collaborating with this amazing community 
3 Likes
Also, just putting this down here — here’s the full proposal for the project:
Link to Proposal
If you have any thoughts, suggestions, or feedback on it, I’d really appreciate it. Always happy to iterate and improve based on your insights!
Hey everyone,
Excited to share the first blog post for the project! While it’s not project-specific yet, it lays the foundation by walking through how Brian2 actually works under the hood.
It’s a deep-dive — about an hour’s read — because I didn’t want it to be just another high-level overview. My aim was to make it intuitive, practical, and beginner-friendly, so that anyone jumping into Brian (especially future contributors) can build a solid mental model of what’s happening behind the scenes :)
Would love your feedback or thoughts if you give it a read!
Cheers!
Hey everyone … `:)
Continuing my journey into understanding and contributing to Brian2, I’ve been digging into the internals of the SpikeQueue
— and here’s what I’m working on right now:
Currently, here’s how spike pushing works in Brian2:
# 1. Generated Cython code calls a Python method
{% block maincode %}
_owner.push_spikes() # Python method call!
{% endblock %}
# 2. Python method extracts spikes and calls another Python method
def push_spikes(self):
events = self.eventspace[: self.eventspace[len(self.eventspace) - 1]]
if len(events):
self.queue.push(events) # Another Python call!
# 3. Finally calls the C++ implementation through Cython
def push(self, np.ndarray[int32_t, ndim=1, mode='c'] spikes):
self.thisptr.push(<int32_t*>spikes.data, spikes.shape[0])
So essentially:
Compiled Cython → Python → Python → Cython → C++
I’m currently working on this PR to streamline the flow and reduce this overhead — more soon!
Also, this week’s blog continues my deep dive into Brian2 internals — this time on how code generation works and how equations are transformed into executable code.
Read it here: Blog
1 Like
Hi everyone! 
Quick update on my GSoC work:
Over the past week, I focused on removing Python overhead from the SpikeQueue
data structure and started integrating the C++ version of DynamicArrays
into Brian2 for improved runtime performance.
Here are the key PRs from this phase:
-
Eliminate Python Layer Calls in Synapses
Codegen Templates for SpikeQueue Operations
https://github.com/brian-team/brian2/pull/1643
-
Remove Python SpikeQueue Fallback and Make Cython Version Mandatory
https://github.com/brian-team/brian2/pull/1649
-
Add C++ DynamicArrays
in Brian2 for Runtime Mode
https://github.com/brian-team/brian2/pull/1650
And as always, here’s my weekly blog post documenting the journey. This week, I even added a fun little animation showing how SpikeQueue works — feel free to check it out!
Brian2: How We Made Spike Processing Faster by Eliminating Python Overhead
Thanks!