Mentors: Marcel Stimberg <marcel.stimberg@inserm.fr>, Dan Goodman <d.goodman@imperial.ac.uk>, Benjamin Evans <B.D.Evans@sussex.ac.uk>
Skill level: Intermediate/Advanced
Required skills: Python, C++
Time commitment: Full time (350 hours)
Forum for discussion
About: Brian is a clock-driven spiking neural network simulator that is easy to learn, highly flexible, and simple to extend. Written in Python, it allows users to describe and run arbitrary neural and synaptic models without needing to write code in any other programming language. It is built on a code-generation framework that transforms model descriptions into efficient low-level code. In Brian’s “runtime mode”, the generated code can interact with Python code by accessing the same data structures in memory. To make this work seamlessly, Brian makes use of Cython. This approach comes with two major disadvantages: 1) Cython compilation is slow (it generates a lot of code for error checking, etc.). For Cython, this is not a big downside, since it is commonly used to compile libraries once, but for Brian it matters since it needs to compile dynamically generated code frequently 2) We need to maintain a third code generation target besides Python and C++, with small but non-trivial differences to both of them.
Aims: The aims of this project are to:
- Replace the Python data structures that are currently used from within Cython code (dynamic arrays and the “spike queue”) by C++ equivalents
- Research solutions to call the compiled C++ code from Python and make it directly access the memory in the shared data structures storing the simulation variables. This could build upon existing just-in-time compilation technologies such as numba, or a package such as scipy-weave.
- Implement the above solution, and refactor the current code to make use of it
Project website: GitHub - brian-team/brian2: Brian is a free, open source simulator for spiking neural networks.
Tech keywords: Python, C++, compilation, JIT
Hello!
I love this project!
I’m really love computational neuroscience and want to build my career in this space. I’ve been working with NeuroML and have experience with spiking neural networks, particularly in modeling and simulation. Given my background, I’d love to contribute to this project. What areas should I focus on to best prepare myself? Would a deeper dive into JIT compilation techniques (maybe Numba?) or a stronger understanding of C++ memory management for neural simulations be most beneficial? What do you suggest?
Dear @namita-ach, many thanks for your interest in the project. This project is a bit different from the others we propose, in that there will be a significant “exploratory” component where we figure out what the best approach will be. Therefore, in addition to getting an idea of how Brian works, it would be good to get an overview of existing solutions to interface C/C++ and Python (Cython, ctypes, cffi, …). Regarding the way Brian’s runtime code generation currently works with Cython, I invite you to run the code posted below. It will simulate a (very simplified and not very interesting) neuron model and record its activity over time. You can find its generated code in the directory that gets printed out. Hopefully that should give you a bit of an idea of what the generated code looks like at the moment, and how it links between Python and Cython/C++. Please include a (not too detailed) “walkthrough” through these files, and in particular how the final C++ code accesses memory that was allocated on the Python side, in your application (in case you decide to apply, of course 
)
Don’t hesitate to ask any questions you will most likely have about this.
from brian2 import *
from brian2.codegen.runtime.cython_rt.extension_manager import get_cython_cache_dir
try:
clear_cache("cython") # Just to make sure that we start with a clean slate
except Exception:
pass # there might be nothing to clear
prefs.codegen.target = "cython"
prefs.codegen.runtime.cython.delete_source_files = False
# A not-so-interesting example of a neuron simulation
neurons = NeuronGroup(10, "dv/dt = -v / (10*ms) : 1", method="exact")
neurons.v = "rand()"
state_monitor = StateMonitor(neurons, "v", record=True)
run(25*ms)
print("Generated code in:", get_cython_cache_dir())
# Just to show that the simulation worked, not generating any Cython code
plt.plot(state_monitor.t/ms, state_monitor.v.T)
plt.show()
Please also see our general guidelines for GSoC applications here: GSoC 2025 | The Brian spiking neural network simulator
Thank you for the insights! I’ll explore the existing solutions for interfacing C/C++ with Python and go through the code to understand how Brian’s runtime code generation works.
and there is typo in the guidelines url you provided it shoude be 2025 after posts/
i.e GSoC 2025 | The Brian spiking neural network simulator 
Thank you, @mstimberg, for all the details!
I hope all the Brain projects get selected by Google. But if Brain gets only one slot, which project would be your top priority out of the 3?
Hello @mstimberg, I am Karthik Sathish, a junior year student from IIT Roorkee. I would like to work on this project. This would be my work flow for the next 2 days:
Understand the current Just in Time architecture that Brain follows (I want to know which part of the architecture is making it run slow.)
Once I figure out the actual problem, I will look for the possible alternatives.
If I face any problem in the journey, I will write it down here.
Indeed, sorry about that! I edited my post to fix the link.
We don’t have a priority project as such. If we only get one slot, we’d select the participant/project combination that we estimate to have the highest chance of achieving the aims of the project.
Hi @mstimberg sir,
I’m Sagar, I found this project exiciting! I am happy to work on it and would love if I can add any value to make Brian faster and better.
I have good C++ skills and some python experience, though I am still learning cython. I studied some of Brian’s code and understood parts of it, like how cython slows things down with extra checks and why switching to C++ for the heavy stuff (like neuron data) makes sense. Some parts were tricky for me, but I am starting to figure them out. I am trying to find a way to connect python and C++ smoothly (maybe with Numba) and looking for blocks that I can rewrite in C++ as of now. Please let me know if there is anything that I can improve.
Hi @Mavericks,
Please have a look at the example I posted earlier in this thread, working through it should make clearer (hopefully…). I wouldn’t try to rewrite things in C++ as of now – what is the most important thing for this project is a simple/lightweight way of exchanging data between Python and a compiled C++ extension. For a relatively simple data structure, e.g. a dynamic array (which could be just a class wrapping a std::vector in C++), how can we declare this data structure together with a Python wrapper (which could be written in Cython) and use it both from Python and from the compiled C++ code, both accessing the same underlying memory. Not sure whether this is clear – please let me know if not 
Actually, we are not that much worried about the slow speed of execution in Cython (despite the additional error checks, it is not much slower than “pure” C++), but about the speed of compilation. If you look at the C++ code that is generated from the Cython code, you can see that it is huge compared to what it would look like if you wrote it in C++.