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

Error out when the number of threads is modified after kokkos is initialized #104

Closed
mrtupek opened this issue Oct 8, 2015 · 7 comments
Closed
Assignees
Labels
Enhancement Improve existing capability; will potentially require voting

Comments

@mrtupek
Copy link

mrtupek commented Oct 8, 2015

In openmp, if the calling code changes the number of threads after initializing kokkos, we'd like the next parallel dispatch to throw an error notifying that the number of threads was changed and that this is not allowed by kokkos.

@mrtupek mrtupek changed the title Error out when the number of threads is modified after kokkos is initialized. Error out when the number of threads is modified after kokkos is initialized Oct 8, 2015
@nmhamster
Copy link
Contributor

I think the lightest overhead way to do this is put the error checking into a KokkosP tool and have it do that if s problem exists?

This would mean we don't need constant queries of the runtime that may prevent optimization.

Thoughts?

Si Hammond
Scalable Computer Architectures
Sandia National Laboratories, NM
[Sent remotely, please excuse typing errors]


From: mrtupek notifications@github.com
Sent: Thursday, October 8, 2015 11:54:54 AM
To: kokkos/kokkos
Subject: [EXTERNAL] [kokkos] Error out when the number of threads is modified after kokkos is initialized. (#104)

In openmp, if the calling code changes the number of threads after initializing kokkos, we'd like the next parallel dispatch to throw an error notifying that the number of threads was changed and that this is not allowed by kokkos.

Reply to this email directly or view it on GitHubhttps://github.com//issues/104.

@crtrott
Copy link
Member

crtrott commented Oct 9, 2015

Do we have an estimate on what the cost for that call is? We could also have it as a debugging option in Kokkos.

@nmhamster
Copy link
Contributor

Will vary by runtime. Its not the call overhead thats the problem, its that there is an external function call in the middle of something we want optimized :-(.

@nmhamster
Copy link
Contributor

Plus, I think recompiling for this is nuts and a waste of time when we can literally set an environment variables and run the detect.

@crtrott
Copy link
Member

crtrott commented Oct 9, 2015

Sure it is certainly a viable option. Might actually be a sensible way to push more debugging options into such external tools.

@crtrott crtrott added the Enhancement Improve existing capability; will potentially require voting label Oct 28, 2015
@crtrott
Copy link
Member

crtrott commented Nov 23, 2015

Me or Nathan is gonna check the overhead for doing the test (how is the empty kernel launch rate changed). If it is negligible add the check directly in Kokkos, alternatively add a tool.

@hcedwar
Copy link
Contributor

hcedwar commented Dec 9, 2015

Fixed by adding verification that thread count is unchanged when verifying that OpenMP backend is initialized.

@hcedwar hcedwar closed this as completed Dec 9, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement Improve existing capability; will potentially require voting
Projects
None yet
Development

No branches or pull requests

5 participants