-
Notifications
You must be signed in to change notification settings - Fork 406
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
Allow Kokkos Tools Interface to be built without Kokkos #4365
Allow Kokkos Tools Interface to be built without Kokkos #4365
Conversation
…essible functionality
Update: hahaoops. Definitely interferes with Kokkos builds. But this is a first step |
TODO: also have a Kokkos::Tools::parse_environment_variables edit: TODONE |
…off/kokkos into feature/reorg-isolate-tuning
…off/kokkos into feature/reorg-isolate-tuning
Thanks David! : - D I know I'm not a paying customer at the moment, but I would prefer a design where the Kokkos Tools interface were factored out of KokkosCore proper, rather than |
@mhoemmen : yeah, I'm right there with you. There's a model that achieves what you're asking for. Let me think about it. Actually, the ToolProgrammingInterface construct I added ages ago might be really helpful here, some of the stuff that's ifdef'd out is contained in there. Yeah, I think there's a path to what you want, I'll take a look today |
Okay, I'm going to recommend we review this as is, just see if it is an acceptable solution. All the ways of avoiding ifdefs have some small problems. Once we have the orthogonalization in place (which I want anyway), we can look at some cleaner, but backwards compatible methods of achieving this |
I am cool with this -- thanks for considering my use cases! : - ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks fine to me. I only have minor comments.
core/src/Kokkos_Core.hpp
Outdated
bool tune_internals; // deprecated | ||
bool tool_help = false; // deprecated | ||
std::string tool_lib = {}; // deprecated | ||
std::string tool_args = {}; // deprecated |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with @masterleinad, I don't see how the variable are deprecated. Don't you just change the way they are initialized?
core/src/impl/Kokkos_Core.cpp
Outdated
if (tools_init_arguments.tune_internals != | ||
Kokkos::Tools::InitArguments::PossiblyUnsetOption::unset) { | ||
tune_internals = (tools_init_arguments.tune_internals == | ||
Kokkos::Tools::InitArguments::PossiblyUnsetOption::on) | ||
? true | ||
: false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do you need a ternary operator here? Why is it not just
if (<not unset>)
tune_internals = (tools_init_arguments.tune_internals == Kokkos::Tools::InitArguments::PossiblyUnsetOption::on);
Same comment below for the help
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
left a few comments
@@ -57,11 +58,11 @@ int main(int argc, char* argv[]) { | |||
Kokkos::MDRangePolicy<Kokkos::Rank<2>> mdp({0, 0}, {1, 1}); | |||
Kokkos::Tools::Experimental::TeamSizeTuner team_tune_this( | |||
"team_tuner", teamp, TestTeamFunctor{}, Kokkos::ParallelForTag{}, | |||
Kokkos::Tools::Impl::Impl::SimpleTeamSizeCalculator{}); | |||
Kokkos::Tools::Experimental::Impl::Impl::SimpleTeamSizeCalculator{}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Impl::Impl::?
auto initialization_status = | ||
Kokkos::Tools::Impl::initialize_tools_subsystem(args); | ||
if (initialization_status.result == | ||
Kokkos::Tools::Impl::InitializationStatus::InitializationResult:: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Technically, you can directly write Kokkos::Tools::Impl::InitializationStatus::success
. Did you mean for Kokkos::Tools::Impl::InitializationStatus::InitializationResult
to be a strong enumeration?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No strong feelings about this one, game to spell it however
Co-authored-by: Damien L-G <dalg24+github@gmail.com>
Somehow still failing format :/ |
Added a newline at the end of the file, reran clang-format, now it's passing |
@crtrott - is there any possibility we can merge this before @DavidPoliakoff leaves Sandia? |
Closes #4327 (and #4326, for a bonus).
@sameershende @mhoemmen @artv3
This is a refactoring of the Tools infrastructure to allow Kokkos Tools to be used without Kokkos. In this PR, all I do is change how Tools is organized such that this is possible. Given permission, I'll share my repo that tests this functionality. This would allow other programming models (RAJA, or Sameer's collaborators) to use Kokkos Tools functionality, allow codes to use only Kokkos Tools, and ideally clean up our code.
This is still a WIP, I need to test more paths through this code, but it currently achieves its goals of allowing independent builds, and (I believe, CI will determine this) doesn't interfere with Kokkos builds