sPyNNaker icon indicating copy to clipboard operation
sPyNNaker copied to clipboard

Better call to clear_connection_cache

Open Christian-B opened this issue 3 years ago • 4 comments

Currently before and after a run there is a loop through projections to call vertex.clear_connection_cache

Would it not be better to just loop over the Vertices? If yes that will be much easier after GlobalData

Also does it have to happen every run or only after a reset? If After a reset could it somehow be called during reset

Also does it need to happen before AND after each run?

Christian-B avatar Apr 22 '22 13:04 Christian-B

If it is easier to loop over vertices that should be fine to do. I think it is necessary to check that the vertex supports the right interface for this of course (presumably something like accepts incoming synapses); those in projections definitely do as that is checked, but the check can be done in a loop too.

The clearing has to happen before a new run i.e. before the second and subsequent runs. It shouldn't happen immediately after a run either as that is too early; the user will only request the data after control is returned back to them after a run. The data is cached in case they ask for weights and then delays separately for example as the data is extracted all at once even if the user asks for it in parts.

Note that if the weights don't change during a run (for which I believe there is an interface) it isn't technically necessary to clear the cache since subsequent requests for the weights and delays should then result in the same data being returned...

rowleya avatar Apr 22 '22 13:04 rowleya

currently it is if isinstance(post_vertex, AbstractAcceptsIncomingSynapses):

Christian-B avatar Apr 22 '22 14:04 Christian-B

Looking deeper. the only AbstractAcceptsIncomingSynapses is AbstractPopulationVertex which iterates over the machine vertices if they isinstance HasSynapses

Christian-B avatar Apr 22 '22 14:04 Christian-B

The clearing has to happen before a new run i.e. before the second and subsequent runs. It shouldn't happen immediately after a run either as that is too early; the user will only request the data after control is returned back to them after a run. The data is cached in case they ask for weights and then delays separately for example as the data is extracted all at once even if the user asks for it in parts.

See #1171 for why this isn't true.

rowleya avatar Apr 22 '22 15:04 rowleya