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.

Sign up for GitHub

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

Jump to bottom

SYCL: Make sure to use a large enough workgroup size for tree traversal #931

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

SYCL: Make sure to use a large enough workgroup size for tree traversal #931

wants to merge 1 commit into from

Conversation

masterleinad
Copy link
Collaborator

Forcing the workgroup size for the tree traversal to 1024 for SYCL, improves the tree traversal by 25% in the DBSCAN benchmark.

@masterleinad masterleinad marked this pull request as ready for review August 22, 2023 17:35
@aprokop aprokop added the performance Something is slower than it should be label Aug 22, 2023
aprokop
aprokop reviewed Aug 22, 2023
View reviewed changes
Copy link
Contributor

@aprokop aprokop left a comment

Choose a reason for hiding this comment

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

Should nearest be changed too? Should the kernel in MST be changed as well?
Does it affect all kernels?

src/details/ArborX_DetailsTreeTraversal.hpp
// FIXME_SYCL
#ifdef KOKKOS_ENABLE_SYCL
if constexpr (std::is_same_v<ExecutionSpace, Kokkos::Experimental::SYCL>)
policy.set_chunk_size(1024);
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you please add a comment on the considerations that went into choosing 1024?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Not quite sure if there is much behind it rather than that choosing the maximum gave much better performance (than 32 which is what the compiler chose) and I couldn't find a different workgroup size that gave better results (but results don't differ much choosing between 256 and 1024 threads per workgroup).

Copy link
Contributor

Choose a reason for hiding this comment

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

Can you please post the results in this issue for different workgroup sizes?

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'll share it privately.

Copy link
Contributor

@dalg24 dalg24 Aug 23, 2023 •
edited
Loading

Choose a reason for hiding this comment

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

Please cc me

@masterleinad
Copy link
Collaborator Author

Looks like the MST algorithm (ArborX::MST::find_component_nearest_neighbors) already gets a good workgroup size (we might get a couple of percent better performance by choosing 128 or 256 instead of 32).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@aprokop aprokop aprokop left review comments

@dalg24 dalg24 dalg24 left review comments

Assignees
No one assigned
Labels
performance Something is slower than it should be
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@masterleinad @dalg24 @aprokop