Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate and document performance effects when working with Subgroups #283

Open
denisalevi opened this issue Apr 13, 2022 · 1 comment

Comments

@denisalevi
Copy link
Member

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
Copy link
Member Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant