Skip to content

[SYCL] Check that some device global uninitialized before locking #18041

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

Conversation

Alexandr-Konovalov
Copy link
Contributor

Count number of not done initialization of device globals and take a lock only if something is not initialized yet.

Count number of not done initialization of device globals and take a
lock only if something is not initialized yet.
@vinser52
Copy link
Contributor

@maarquitos14 Could you please review this PR? We expect some performance improvement from these changes.

std::lock_guard<std::mutex> Lock(MDeviceGlobalInitializersMutex);
for (const device &Dev : Devs) {
auto Key = std::make_pair(Program, getSyclObjImpl(Dev)->getHandleRef());
MDeviceGlobalInitializers.emplace(Key, BinImage);
auto [Iter, Inserted] = MDeviceGlobalInitializers.emplace(Key, BinImage);
Copy link
Contributor

Choose a reason for hiding this comment

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

I have a couple of questions:

  1. I see MDeviceGlobalInitializers is an std::map. Do we really need the elements to be sorted? If not, we can change to std::unordered_map, which should provide better performance.
  2. Are we expecting the inserted elements to be consecutive? Could we use emplace_hint instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

  1. I see MDeviceGlobalInitializers is an std::map. Do we really need the elements to be sorted? If not, we can change to std::unordered_map, which should provide better performance.

Sure, done.

  1. Are we expecting the inserted elements to be consecutive? Could we use emplace_hint instead?

The key is a pair of pointers. I'm not sure what can be say about order of them.

Copy link
Contributor

@maarquitos14 maarquitos14 Apr 23, 2025

Choose a reason for hiding this comment

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

The key is a pair of pointers. I'm not sure what can be say about order of them.

Yep, that is my concern too. Maybe it's worth it to try and measure to see if it helps? I'll approve anyway in case you want to do that in a separate PR.

Copy link
Contributor

@maarquitos14 maarquitos14 left a comment

Choose a reason for hiding this comment

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

LGTM.

@vinser52
Copy link
Contributor

@maarquitos14 Should we merge it?

@maarquitos14
Copy link
Contributor

@maarquitos14 Should we merge it?

I don't have merge permissions, pinging @intel/llvm-gatekeepers should help.

@steffenlarsen steffenlarsen merged commit f21034e into intel:sycl Apr 24, 2025
25 checks passed
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.

4 participants