brian-team/brian2cuda

Investigate and document performance effects when working with `Subgroup`s

denisalevi opened this issue · 1 comments

Eventspaces are always defined per NeuronGroup (not per Subgroup). This means any kernel that has to work with neurons in the eventspace but perform some operation only on a Subgroup has to perform additional operations to determine which neurons in the eventspace belong to a Subgroup. This is relevant for the following operations:

  • Synaptic events: Currently, each thread reads one neuron ID from the eventspace. For subgroups, each thread checks if the neuron is in the subgroup and only those threads that read a neuron from the subgroup will perform synapse pushing / effect application. This is likely very inefficient for e.g. large neurongroups with many small subgroups.
  • Monitors: Both spike- and ratemonitors have to sort through the eventspace to get the spiking neuron IDs and the spiking neuron counter for a given Subgroup.

The effects of using too many (or any) subgroups should be investigated for Brian2CUDA, since the effects are likely worse than for C++ Standalone. And this should be documented.

EDIT: Current implementation of synaptic events is independent of whether subgroups are connected or just subsets of indices between the full neurongroups, see discussion in #284