Investigate and document performance effects when working with `Subgroup`s
denisalevi opened this issue · 1 comments
denisalevi commented
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.
denisalevi commented
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