Address inefficiencies in the SpikeQueue data structure

brian-team / brian2

Brian is a free, open source simulator for spiking neural networks.

http://briansimulator.org

Other

941 stars 221 forks source link

Address inefficiencies in the SpikeQueue data structure #169

Open mstimberg opened 11 years ago

mstimberg commented 11 years ago

Currently, there are two inefficiencies in the SpikeQueue implementations (both C++ and Python):

[ ] The "neurons to synapses" data structure is stored once per SpikeQueue -- if several pre or post pathways exist, this information is redundant across pathways
[ ] In the prepare stage before a run, the integer delays and "neurons to synapses" data structures are re-created from scratch every time, even if nothing changed.

mstimberg commented 10 years ago

Another inefficiency:

[x] Scalar delays (constant delay across synapses) are stored in a delay array in the same way as heterogeneous delays (and the delays are looked up in this array for every synaptic propagation)

thesamovar commented 10 years ago

Incidentally I was running the pure Python version of Brian on the tests, without the C++ spikequeue and it is incredibly slow. I guess we should improve this at some point.

thesamovar commented 9 years ago

This is fairly important for a 2.0 release I think. I don't remember what the current status of work on this is. Have we solved some or all of the problems?

mstimberg commented 9 years ago

Only the scalar inefficiency is fixed, the other two still remain. I don't think they are show-stoppers, though, the first one only affects multiple pre (or multiple post) pathways, a feature not used very often. The second is an inefficiency for multiple runs, but the unnecessary computation that is done involves a single pass over all synapses, this should be less than the time it takes to simulate a single time step.

thesamovar commented 9 years ago

OK!