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

Allow Kokkos Tools Interface to be built without Kokkos #4365

Merged
merged 44 commits into from
Nov 11, 2021

Conversation

DavidPoliakoff
Copy link
Contributor

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

@DavidPoliakoff
Copy link
Contributor Author

Update: hahaoops. Definitely interferes with Kokkos builds. But this is a first step

@DavidPoliakoff
Copy link
Contributor Author

DavidPoliakoff commented Sep 27, 2021

TODO: also have a Kokkos::Tools::parse_environment_variables edit: TODONE

@DavidPoliakoff DavidPoliakoff marked this pull request as ready for review September 27, 2021 18:45
@mhoemmen
Copy link
Contributor

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 #ifdef'd. That would make downstream applications that love to hard-code their build systems grumpy, though.

@DavidPoliakoff
Copy link
Contributor Author

@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

@DavidPoliakoff
Copy link
Contributor Author

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

@mhoemmen
Copy link
Contributor

I'm going to recommend we review this as is, just see if it is an acceptable solution.

I am cool with this -- thanks for considering my use cases! : - )

core/src/impl/Kokkos_Error.cpp Outdated Show resolved Hide resolved
core/src/impl/Kokkos_Core.cpp Outdated Show resolved Hide resolved
Copy link
Member

@Rombur Rombur left a 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.

Comment on lines 92 to 95
bool tune_internals; // deprecated
bool tool_help = false; // deprecated
std::string tool_lib = {}; // deprecated
std::string tool_args = {}; // deprecated
Copy link
Member

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_Command_Line_Parsing.cpp Show resolved Hide resolved
core/unit_test/tools/TestIndependence.cpp Show resolved Hide resolved
core/src/Kokkos_Core.hpp Outdated Show resolved Hide resolved
core/src/impl/Kokkos_Command_Line_Parsing.cpp Show resolved Hide resolved
core/src/impl/Kokkos_Command_Line_Parsing.hpp Outdated Show resolved Hide resolved
core/src/impl/Kokkos_Command_Line_Parsing.hpp Outdated Show resolved Hide resolved
core/src/impl/Kokkos_Core.cpp Show resolved Hide resolved
Comment on lines 598 to 603
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;
Copy link
Member

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

Copy link
Member

@crtrott crtrott left a 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

core/src/impl/Kokkos_ViewMapping.hpp Outdated Show resolved Hide resolved
core/src/impl/Kokkos_ViewMapping.hpp Show resolved Hide resolved
@@ -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{});
Copy link
Member

Choose a reason for hiding this comment

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

Impl::Impl::?

core/src/impl/Kokkos_Command_Line_Parsing.hpp Outdated Show resolved Hide resolved
Developer: David P automation moved this from Awaiting Feedback to In progress Nov 10, 2021
auto initialization_status =
Kokkos::Tools::Impl::initialize_tools_subsystem(args);
if (initialization_status.result ==
Kokkos::Tools::Impl::InitializationStatus::InitializationResult::
Copy link
Member

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?

Copy link
Contributor Author

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>
@DavidPoliakoff
Copy link
Contributor Author

Somehow still failing format :/

@DavidPoliakoff
Copy link
Contributor Author

Added a newline at the end of the file, reran clang-format, now it's passing

@DavidPoliakoff DavidPoliakoff moved this from In progress to Awaiting Feedback in Developer: David P Nov 10, 2021
@nmhamster
Copy link
Contributor

@crtrott - is there any possibility we can merge this before @DavidPoliakoff leaves Sandia?

@crtrott crtrott merged commit ff083d4 into kokkos:develop Nov 11, 2021
Kokkos Release 3.6 automation moved this from Awaiting Feedback to Done Nov 11, 2021
@DavidPoliakoff DavidPoliakoff moved this from Awaiting Feedback to Done in Developer: David P Nov 11, 2021
@nmhamster
Copy link
Contributor

@crtrott / @dalg24 - thanks for the help with this one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants