Merging neurongroups for performance improvement

[Vafa-Andalibi]

Hello,

I'm one of the developers of the CxSystem. Checking the COBAHH example I noticed that combining the neuron groups into one and virtually separate them cause a huge performance improvement (At least x2). Of course this can be implemented in CxSystem where the user defines multiple groups and CxSystem combines them into one in the backend. Is there any downside to this? If not, why doesn't Brian do it internally? (i.e. when there are multiple separate neurongroups are defined in the script, brian combines them into a single neurongroup in the backend to improve performance.)

Thanks,

[mstimberg]

Hi, I'm not sure I understand completely: In the COBAHH example, there's only one group -- or do you mean that splitting them up would lead to worse performance? In general, we do advise users to model as much as possible within a single group, i.e. all neurons that share the same equations (e.g. regardless of whether they are excitatory/inhibitory, or which layer in a feed-forward network, etc.) should be modeled with a single NeuronGroup. It's not only a performance question, it can also make for a more compact description (e.g. in the COBAHH example, you only need one object for the excitatory synapses, instead of one for E->E and one for E->I). Having said that, the simulation time shouldn't be much affected (I just tried with COBAHH and it changes very little), for runtime (i.e. not using C++ standalone) the overhead should increase a little but for complex equations like in COBAHH this does not noticeably affect the runtime. It could have a stronger effect on the preparation time (analyzing the equations, etc.), because a lot of work is redundant (although the redundancy should be reduced with our recently introduced caching mechanisms).

Sooo, to sum up: I'm neither convinced this is a real problem, nor that Brian should do something about it internally :) To decided whether two groups can be merged is non-trivial, and dealing with the translation between "internal model" and "user model" will further complicate things.