-
Notifications
You must be signed in to change notification settings - Fork 12
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
Fix and optimize StateMonitor template #201
Labels
Comments
denisalevi
added a commit
that referenced
this issue
Apr 14, 2021
This was referenced Apr 14, 2021
denisalevi
added a commit
that referenced
this issue
Apr 14, 2021
denisalevi
added a commit
that referenced
this issue
Apr 14, 2021
denisalevi
added a commit
that referenced
this issue
Aug 4, 2021
denisalevi
added a commit
that referenced
this issue
Aug 6, 2021
denisalevi
added a commit
that referenced
this issue
Mar 31, 2022
Fixes bug in #201, without optimizing it yet.
denisalevi
added a commit
that referenced
this issue
Mar 31, 2022
Now it actually tests something instead just failing to notify about issue #201 (which is solved now)
denisalevi
added a commit
that referenced
this issue
Mar 31, 2022
Fixes bug in #201, without optimizing it yet.
denisalevi
added a commit
that referenced
this issue
Mar 31, 2022
Now it actually tests something instead just failing to notify about issue #201 (which is solved now)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Statemonitor only works for <1024 recorded neurons and the implementation seems rather inefficient.
This is a follow-up issue from #50. Here are my relevant comments from that issue:
The StateMonitor is also not working working for many neurons. Currently the
StateMonitor
is called with 1 block and as many threads as there are Neurons (or Synapses etc) to record. So if there are more Neurons then the maximum number of threads, the kernel fails to launch.Originally posted by @denisalevi in #50 (comment)
And the global memory writes are not coalesced. Currently we have a 2D data structure of dimensions
indices x record_times
(vector of vectors) for each variable monitor. And we fill that in the kernel like thisFor coalesced writes we could just "transpose" the monitor data structure so we can use
We might have to resort the monitor in the end though since it might then not fit with the format that Brian expects to read back.
Originally posted by @denisalevi in #50 (comment)
The text was updated successfully, but these errors were encountered: