# GSoC2026:Fix outstanding issues in Brian2CUDA **URL:** \ **Category:** Development\ **Tags:** brian2cuda\ **Created:** [6 May 2026 13:58 UTC](https://brian.discourse.group/t/gsoc2026-fix-outstanding-issues-in-brian2cuda/1560 "2026-05-06T13:58:22Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![SinYita](https://yyz2.discourse-cdn.com/free1/user_avatar/brian.discourse.group/sinyita/32/960_2.png) [@SinYita](https://brian.discourse.group/u/SinYita)\ **Post date:** [6 May 2026 13:58 UTC](https://brian.discourse.group/t/gsoc2026-fix-outstanding-issues-in-brian2cuda/1560/1 "2026-05-06T13:58:22Z")
Hi everyone 👋 ! I am Weiyuan Du, and I am excited to have been selected for this year’s GSoC with the **Brian team**! This summer, I will working on resolving outstanding issues in Brian2CUDA. I am honored to be mentored by **Marcel Stimberg** , **Dan Goodman** , and **Ben Evans.** **What this project is about** Brian2CUDA was developed to accelerate neural simulations using GPUs. However, several hurdles currently exist that affect the user experience and performance. My primary focus this summer will be: 1. Add support for windows users by completing the Windows compatibility layer. 2. Reduce build times by exploring efficient compiler flags and introducing new caching/build mechanisms. 3. Implement a consistent and configurable logging system to improve transparency during simulation. 4. Refine the preference configuration and validation process for users gently. 5. Update and complete documentations. The ultimate goal is to make Brian2CUDA as easy to use as the standard Brian2 backends, allowing researchers to focus on their models rather than debugging their build environment.I would love to hear any suggestions, feedback, or pain points you’ve encountered while using Brian2CUDA. Looking forward to a productive summer with the amazing community! ☺ ☺ ---
**Author:** ![sivanni](https://yyz2.discourse-cdn.com/free1/user_avatar/brian.discourse.group/sivanni/32/617_2.png) [@sivanni](https://brian.discourse.group/u/sivanni)\ **Post date:** [12 May 2026 02:09 UTC](https://brian.discourse.group/t/gsoc2026-fix-outstanding-issues-in-brian2cuda/1560/4 "2026-05-12T02:09:01Z")
Hi SinYita, Good luck for your important job! We have practically sidelined Brian2CUDA device because of slow builds and often running out of memory. Possibility to profile memory use with Brian2CUDA would be useful. Have fun! Simo ---
**Author:** ![BernardM](https://yyz2.discourse-cdn.com/free1/user_avatar/brian.discourse.group/bernardm/32/947_2.png) [@BernardM](https://brian.discourse.group/u/BernardM)\ **Post date:** [23 July 2026 19:39 UTC](https://brian.discourse.group/t/gsoc2026-fix-outstanding-issues-in-brian2cuda/1560/5 "2026-07-23T19:39:59Z")
Maybe unrelated maybe useful but having discovered the CUpy (numpy on GPU) library recently I wonder if using that internally in brian instead of standard numpy could be useful! ---
**Author:** ![jane-street](https://yyz2.discourse-cdn.com/free1/user_avatar/brian.discourse.group/jane-street/32/972_2.png) [@jane-street](https://brian.discourse.group/u/jane-street)\ **Post date:** [21 August 2026 14:40 UTC](https://brian.discourse.group/t/gsoc2026-fix-outstanding-issues-in-brian2cuda/1560/6 "2026-08-21T14:40:28Z")
Can u share your proposal please. ---
**Author:** ![SinYita](https://yyz2.discourse-cdn.com/free1/user_avatar/brian.discourse.group/sinyita/32/960_2.png) [@SinYita](https://brian.discourse.group/u/SinYita)\ **Post date:** [4 September 2026 18:03 UTC](https://brian.discourse.group/t/gsoc2026-fix-outstanding-issues-in-brian2cuda/1560/7 "2026-09-04T18:03:47Z")
Hi everyone! I am happy to share my final report for Google Summer of Code 2026. Over the past four months, I worked on Brian2CUDA with the goal of making it easier to build, faster to compile, and easier to debug. In this report, I describe the main problems I worked on, the changes I implemented, the current state of the project, and the work that is still in progress. # Google Summer of Code 2026: Work Product Submission **Organization:** INCF, Brian2 Simulator **Project:** Fix outstanding issues in Brian2CUDA Weiyuan Du ([@SinYita](https://github.com/SinYita)) ## Project Abstract Brian2CUDA is an extension of the open-source spiking neural network simulator [Brian2](https://github.com/brian-team/brian2). It generates C++ and CUDA code, so models written in Brian2’s mathematical notation can run on NVIDIA GPUs. The backend already has strong runtime performance and is used by researchers, but several practical issues made it harder to use and maintain: limited Windows support, slow standalone compilation compared with cpp\_standalone and Brian2GeNN, and CUDA-side diagnostics based on unconditional `printf` and `std::cout output`. My work focused on three main goals: 1. Complete Windows support and add cross-platform CI that checks code generation and compilation without a GPU (Issue [#225](https://github.com/brian-team/brian2cuda/issues/225), [#320](https://github.com/brian-team/brian2cuda/issues/320)). 2. Reduce standalone compile time by removing Thrust and cuRAND from the public include graph (Issue [#179](https://github.com/brian-team/brian2cuda/issues/179)). 3. Add a C++/CUDA logging system that uses Brian2’s console log level, removes unused diagnostics at compile time, and sends host warnings and errors back to Python (Issue [#103](https://github.com/brian-team/brian2cuda/issues/103)). **GitHub repository:** [brian-team/brian2cuda](https://github.com/brian-team/brian2cuda) **Mentors:** [@mstimberg](https://github.com/mstimberg) (Marcel Stimberg), [@thesamovar](https://github.com/thesamovar) (Dan Goodman), [@bdevans](https://github.com/bdevans) (Ben Evans) ## Project Goals I organized the project around three user-facing problems: ### Phase 1: Windows compatibility Brian2CUDA did not yet have a complete Windows build path. I aimed to turn the empty `win_makefile` into a real nmake and nvcc build path, align it with Brian2’s cpp\_standalone MSVC support, and add CI that can catch code-generation and compile regressions on both Linux and Windows. ### Phase 2: Compilation speed For a typical model, almost every generated .cu file included objects.h, and objects.h pulled in Thrust, cuRAND, and full network and synapse types. This meant that the compiler paid the same cost many times. I focused on removing Thrust and cuRAND from the public include graph, so most translation units only see std::vector, raw pointers, and named helpers. ### Phase 3: CUDA-level logging Standalone CUDA code printed diagnostics unconditionally. I wanted to reuse Brian2’s existing logger, decide at compile time whether each message should exist, and save host warnings and errors so Python can show them after the standalone process exits. ## Work Accomplished ### Phase 1: Windows support and platform CI Brian2CUDA can now generate and compile CUDA standalone projects on Windows with MSVC 2022 and CUDA Toolkit 12.8 or earlier. - Replaced the empty win\_makefile with a full nmake makefile using separable compilation, nvcc linking, cudart.lib, and curand.lib. - Completed the MSVC path in `device.py`. When cpp\_compiler == `msvc`, Brian2CUDA now generates `win_makefile` and reuses Brian2’s`compile_source()`, including vcvars setup. - Passed Brian2 cpp\_compiler\_flags, including` /MP`, through `-Xcompiler` on Windows. - Added `test_platform.py` and a GitHub Actions matrix for Ubuntu 24.04 and Windows Server 2022 with CUDA 12.8. The test generates and compiles a small network without requiring a GPU. ### Phase 2: Compilation speed Before this work, a typical code object on master spent about 8–10 seconds in nvcc -dc even when the generated kernel was small. This happened because objects.h exposed Thrust types to every code object. **Original generated declarations:** ```cpp // Original: every code object had to parse this extern thrust::host_vector _dynamic_array_foo; extern thrust::device_vector dev_dynamic_array_foo; ``` I split this part of the work into stacked pull requests: - [#332](https://github.com/brian-team/brian2cuda/pull/332): Slim cuda\_utils.h, move cuRAND/RNG support behind rand.h, and include it only where needed. This also needed upstream [Brian2 pull request #1852](https://github.com/brian-team/brian2/pull/1852). - [#333](https://github.com/brian-team/brian2cuda/pull/333): Use public std::vector and named helpers, then introduce DeviceBuffer PImpl and type erasure so generated objects.cu no longer includes Thrust. **Compile times** (examples/mushroombody.py, N=1000, RTX 3080 Ti, CUDA 12.8): | Version | make -j12 | Typical code object | | --- | --- | --- | | **master** | 33 s | ~8–10 s | | **Thrust isolated** | 22 s | ~2–3 s | | **PImpl + type erasure** | **12.8 s** | ~2–3 s | ### Phase 3: CUDA logging Pull request [#338](https://github.com/brian-team/brian2cuda/pull/338) maps Brian2’s console level to `B2C_LOG_LEVEL`. `B2C_LOG_DEBUG` and `B2C_LOG_INFO` lines are removed by the preprocessor when they are not needed. Host warnings and errors are written to `results/cuda_log.txt` and then shown again through Brian2’s logger after the standalone process exits. ## Contributions During GSoC Period | Pull request | Description | Status | | --- | --- | --- | | **[#328](https://github.com/brian-team/brian2cuda/pull/328)** | Windows nmake/nvcc and Linux/Windows compile CI | **Merged** | | **[#332](https://github.com/brian-team/brian2cuda/pull/332)** | Slim headers and RNG on demand | **Open** | | **[#333](https://github.com/brian-team/brian2cuda/pull/333)** | Thrust isolation and DeviceBuffer PImpl | **Open** | | **[#338](https://github.com/brian-team/brian2cuda/pull/338)** | B2C\_LOG\_\* and host WARN/ERROR re-emit | **Open** | | **[#337](https://github.com/brian-team/brian2cuda/pull/337)** | Developer handbook | **Open** | | **[brian2#1852](https://github.com/brian-team/brian2/pull/1852)** | Forward compiler\_kwds from BinomialFunction | **Merged** | ## Current State and Next Steps Completed work includes the Windows build path, no-GPU compile CI, faster parallel compilation, CUDA logs that follow Brian2’s console level, and developer documentation. Remaining work starts with landing the stacked pull requests already in review: [#332](https://github.com/brian-team/brian2cuda/pull/332), [#333](https://github.com/brian-team/brian2cuda/pull/333), [#337](https://github.com/brian-team/brian2cuda/pull/337), and [#338](https://github.com/brian-team/brian2cuda/pull/338). The main follow-up for compilation speed is the ccache branch. Early tests show a large speedup for rebuilds when generated kernels have not changed. The next step is to keep checking cache stability and document when the cache is useful. Documentation also needs follow-up. Pull request [#337](https://github.com/brian-team/brian2cuda/pull/337), and [#338](https://github.com/brian-team/brian2cuda/pull/338) starts a developer handbook, and the user-facing documentation should describe the current Windows toolchain, including CUDA 12.8 and MSVC 2022, as well as the known CUDA 13 and Visual Studio 2026 limits. ## Acknowledgments I am very grateful to [@mstimberg](https://github.com/mstimberg) for his careful review and guidance throughout the project, especially on testing and finding the right bottleneck to solve first. I also want to thank [@thesamovar](https://github.com/thesamovar), [@bdevans](https://github.com/bdevans), and the Brian community for their feedback, support, and encouragement. I learned a lot during GSoC, both about Brian2CUDA and about maintaining real scientific software. This project made Brian2CUDA more practical for users and easier to maintain for future development. I plan to keep contributing after GSoC and help finish the remaining pieces. Looking forward to all kinds of guidance or feedbacks from the community and individuals. ☺