Skip to content

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

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
Open
masterleinad 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

masterleinad wants to merge 1 commit into from

Conversation

@masterleinad
Copy link
Collaborator

@masterleinad masterleinad commented Aug 21, 2023

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

@aprokop aprokop Aug 22, 2023

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

@masterleinad masterleinad Aug 22, 2023

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

@aprokop aprokop Aug 23, 2023

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

@masterleinad masterleinad Aug 23, 2023

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

masterleinad commented Sep 12, 2023

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

@dalg24 dalg24 dalg24 left review comments

@aprokop aprokop aprokop 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