-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Improve slow monitor performance #143
Improve slow monitor performance #143
Conversation
This fixes an issue where slow StateMonitor clocks incurred state pull operations on every tick. Additionally, operations across StateMonitor and run_regularly operations are consolidated, reducing transfers to the minimum necessary.
Instead of pulling the entire state of a particular model, we can just pull the individual variables requested by each StateMonitor / run_regularly operation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the late review. This looks great! I only recently realized that Brian2GeNN is pulling all the variables when using a StateMonitor
– this is a nice improvement. I made two minor comments. Let me know if you don't have the time to take them into account, I can also fix these details myself.
Done. Test failures seem to point to a bug revealed by brian-team/brian2@aff91cb outside of the scope of this PR, I believe. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All looks great to me, thanks!
Yes, the failures do not seem to have anything to do with this PR. |
In my previous pull request (#140) I introduced support for slower clocks for StateMonitor objects, but failed to notice that the necessary data transfers are not rolled into the code objects, but are rather processed (somewhat) parsimoniously in the engine template.
This pull request expands on the general principle of minimizing unnecessary transfers in the following ways:
StateMonitor
s are only transferred in the required iterations, rather than at every tick as beforeStateMonitor
andrun_regularly
operations, including both'start'
and'end'
slots for SMsSince this was a little too much to ask of Jinja, I've placed the consolidation logic into device.py, providing the template with the names of the variables to be pulled, along with their periods.