Skip to content
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

Optimizations for template_similarity (numba and dependencies) #3405

Merged
merged 22 commits into from
Oct 7, 2024

Conversation

yger
Copy link
Collaborator

@yger yger commented Sep 13, 2024

  • Add the possibility to compute the template similarities (rather slow for the moment) using a numba kernel.
  • Remove the dependencies to sklearn in template_similarity without numba, since we do not plan anymore to add metric
  • Also adds prange in some other numba functions, with the keyword parallel=True (otherwise, prange is not activated, as far as I understood).

@zm711
Copy link
Collaborator

zm711 commented Sep 13, 2024

One thing to keep in mind is that the process of creating the threads is pretty expensive, so depending on the number of computations it can actually be beneficial to do the calculation serially rather than do the parallel operation. Not that we shouldn't do this, but we should just thing about common use case vs worst case scenario.

@yger
Copy link
Collaborator Author

yger commented Sep 13, 2024

Yes, but here on my machine the speed up is rather drastic, but I can do more benchmarks if needed. In its current form, the template_similarity is too slow (if max_lag_ms is not 0 this is really bad) for large number of templates. So one must optimize it. I've discussed with @samuelgarcia and made two proposals. One in PR #3174 involving PoolExecutor and this one, relying on numba. This is simpler I guess, but this is worth letting @samuelgarcia comment :-)

for count, shift in enumerate(shift_loop):
src_sliced_templates = templates_array[:, num_shifts : num_samples - num_shifts]
tgt_sliced_templates = other_templates_array[:, num_shifts + shift : num_samples - num_shifts + shift]
for i in numba.prange(num_templates):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would put the prange the very first loop.
I do not known if the thread are spawn for every shift loop.

In short I would invert the prange on template and the shift loop.

Could you try this and make benchmark ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've tried to invert the loops, and it does not make any difference

@alejoe91 alejoe91 added the postprocessing Related to postprocessing module label Sep 23, 2024
@yger
Copy link
Collaborator Author

yger commented Sep 24, 2024

For 500 templates with 384 channels (Neuropixels like) we have on a laptop (for 0.1 ms of max_lag_ms)

  • default implementation: 5.1s
  • numba implementation: compilation time 10.6s, run time 1.1s
  • poolexecutor: 9s (but speed up on a desktop with more cores, i guess we see mostly overhead here)

@alejoe91
Copy link
Member

@yger could you add a test that checks that numba and numpy implementations give the same results?

@yger
Copy link
Collaborator Author

yger commented Sep 25, 2024

Done, tests are passing

@samuelgarcia
Copy link
Member

Merci Pierre. This is really cool.

@samuelgarcia samuelgarcia merged commit 80cc888 into SpikeInterface:main Oct 7, 2024
15 checks passed
@yger yger deleted the numba_similarity branch October 7, 2024 15:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
postprocessing Related to postprocessing module
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants