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

ENH Reuse TopK buffers #110

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

ENH Reuse TopK buffers #110

wants to merge 1 commit into from

Conversation

fcharras
Copy link
Collaborator

@fcharras fcharras commented Apr 26, 2023

Before going forward on the KNN I'd like to add this enhancement for the TopK, this PR exposes a function _make_get_topk_kernel that returns a closure that will held references definitions of kernels AND to buffers that will be re-used if successive calls to _make_get_topk_kernel are performed.

The current top-k top level functions in main include an allocation and de-allocation at each calls. (The kernel definitions are still cached by the lru_cache).

This fit the usecase for the KNN that will consist in slicing the input data and running the same pairwise distance + TopK kernels for each slice, and aligns with the behavior of the sum and argmin reduction kernels in the reduction .

Copy link
Collaborator

@ogrisel ogrisel left a comment

Choose a reason for hiding this comment

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

The docstring for the _make_get_topk_kernel kernel looks good but as far as I can see, you did not add a unit test that checks that the closure tricks works as expected when doing repeated calls to the same closure, in particular for both possible values of reuse_result_buffer.

Other than that, LGTM (I just did a very shallow review).



@lru_cache
def make_range_kernel(n_items, work_group_size):
Copy link
Collaborator

Choose a reason for hiding this comment

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

Maybe range => arange to match the numpy function name?

Otherwise one can get confused with the "range" name from SYCL terminology.

@fcharras
Copy link
Collaborator Author

The unit test is a bit technical with the closure-style definition of things everywhere but it should be possible, I'll look into it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants