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

Deprecate InitArguments struct and replace it with InitializationSettings #5135

Merged
merged 11 commits into from
Jul 7, 2022

Conversation

dalg24
Copy link
Member

@dalg24 dalg24 commented Jun 23, 2022

I drafted a replacement struct for InitArguments. At this time it is still missing the implicit conversion from InitArguments. I haven't put any thought into the name yet. I am looking for early feedback on the design, that is public member function to set the values that can be chained and "private" macros to query if a variable is set and and get its value.

Copy link
Contributor

@masterleinad masterleinad left a comment

Choose a reason for hiding this comment

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

I think this is conceptionally (interface-wise) good. I'm not quite sure if we really need the getter-functions but they seem to be good for testing at least.
As discussed elsewhere, we also need to see what issues we would need to revolve for interfaces taking the InitArguments right now.

@cz4rs
Copy link
Contributor

cz4rs commented Jun 23, 2022

I would be in favor of adding the getters as well. This obviously gets complicated for the cases where the variable is not set (what to return? the optional itself?).

@nliber
Copy link
Contributor

nliber commented Jun 23, 2022

I like this interface as well.

While I don't see a need for getters, maybe a way to print out the configuration?

@PhilMiller
Copy link
Contributor

I would favor getters and making the members private, so that the compiler will enforce that all modifications go through the setters, rather than doing weird stuff with clunky name modifications in macros.

@dalg24 dalg24 changed the title Deprecate InitArguments struct and replace it with <PLACEHOLDER> Deprecate InitArguments struct and replace it with InitializationSettings Jun 30, 2022
@dalg24 dalg24 marked this pull request as ready for review July 1, 2022 23:53
@dalg24 dalg24 force-pushed the new_init_args_struct branch 3 times, most recently from fff711c to 6840b43 Compare July 4, 2022 12:23
Copy link
Contributor

@masterleinad masterleinad left a comment

Choose a reason for hiding this comment

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

Looks like a guard for the deprecated struct is missing:

/var/jenkins/workspace/Kokkos/core/unit_test/TestInitializationSettings.cpp:56:11: error: no type named 'InitArguments' in namespace 'Kokkos'
  Kokkos::InitArguments arguments;
  ~~~~~~~~^
1 error generated.
core/unit_test/CMakeFiles/KokkosCore_UnitTest_Default.dir/build.make:94: recipe for target 'core/unit_test/CMakeFiles/KokkosCore_UnitTest_Default.dir/TestInitializationSettings.cpp.o' failed

// Prevent "unused variable" warning for 'args' input struct. If
void OpenMPTargetSpaceInitializer::initialize(
const InitializationSettings& settings) {
// Prevent "unused variable" warning for 'settings' input struct. If
// Serial::initialize() ever needs to take arguments from the input
Copy link
Member

Choose a reason for hiding this comment

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

Wrong comment. It should be OpenMPTarget::initialize()

Copy link
Member Author

Choose a reason for hiding this comment

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

You're right I hadn't seen it. Considering that I will remove that code in #5144, I would rather not fix here though.

@@ -100,45 +99,105 @@ void declare_configuration_metadata(const std::string& category,
metadata_map[category][key] = value;
}

ExecSpaceManager& ExecSpaceManager::get_instance() {
void combine(Kokkos::InitializationSettings& out,
Kokkos::InitializationSettings const& in) {
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 this function?

Copy link
Member Author

Choose a reason for hiding this comment

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

It replaces void combine(InitArguments& out, InitArguments const& in) and we use it in initialize(InitializationSettings const&)

Copy link
Contributor

@masterleinad masterleinad left a comment

Choose a reason for hiding this comment

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

Overall, this looks good to me. Just a few questions/suggestions/nitpicks.

core/src/Kokkos_Core_fwd.hpp Show resolved Hide resolved
Comment on lines +104 to +118
#define KOKKOS_IMPL_COMBINE_SETTING(NAME) \
if (in.has_##NAME()) { \
out.set_##NAME(in.get_##NAME()); \
} \
static_assert(true, "no-op to require trailing semicolon")
KOKKOS_IMPL_COMBINE_SETTING(num_threads);
KOKKOS_IMPL_COMBINE_SETTING(device_id);
KOKKOS_IMPL_COMBINE_SETTING(num_devices);
KOKKOS_IMPL_COMBINE_SETTING(skip_device);
KOKKOS_IMPL_COMBINE_SETTING(disable_warnings);
KOKKOS_IMPL_COMBINE_SETTING(tune_internals);
KOKKOS_IMPL_COMBINE_SETTING(tool_help);
KOKKOS_IMPL_COMBINE_SETTING(tool_lib);
KOKKOS_IMPL_COMBINE_SETTING(tool_args);
#undef KOKKOS_IMPL_COMBINE_SETTING
Copy link
Contributor

Choose a reason for hiding this comment

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

Nitpick: I know you didn't introduce this in this pull request, but I would prefer avoiding macros here and rather do

Suggested change
#define KOKKOS_IMPL_COMBINE_SETTING(NAME) \
if (in.has_##NAME()) { \
out.set_##NAME(in.get_##NAME()); \
} \
static_assert(true, "no-op to require trailing semicolon")
KOKKOS_IMPL_COMBINE_SETTING(num_threads);
KOKKOS_IMPL_COMBINE_SETTING(device_id);
KOKKOS_IMPL_COMBINE_SETTING(num_devices);
KOKKOS_IMPL_COMBINE_SETTING(skip_device);
KOKKOS_IMPL_COMBINE_SETTING(disable_warnings);
KOKKOS_IMPL_COMBINE_SETTING(tune_internals);
KOKKOS_IMPL_COMBINE_SETTING(tool_help);
KOKKOS_IMPL_COMBINE_SETTING(tool_lib);
KOKKOS_IMPL_COMBINE_SETTING(tool_args);
#undef KOKKOS_IMPL_COMBINE_SETTING
// clang-format off
if (in.has_num_threads) out.set_num_threads(in.get_num_threads);
if (in.has_device_id) out.set_device_id(in.get_device_id);
[...]
// clang-format off

Copy link
Member Author

Choose a reason for hiding this comment

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

Not changing as I do not agree with the suggestion

Comment on lines +1058 to +1060
Kokkos::Impl::InitializationSettingsHelper<std::string>::storage_type const
Kokkos::Impl::InitializationSettingsHelper<std::string>::unspecified =
"some string we don't expect user would ever provide";
Copy link
Contributor

Choose a reason for hiding this comment

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

Shouldn't this be in its own *.cc file since you already split the implementation of the struct into its own header file?

Copy link
Member Author

Choose a reason for hiding this comment

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

Considering that we will drop it when C++17 is available, I'd rather not create a source file.

Comment on lines +109 to +112
#define KOKKOS_IMPL_INIT_ARGS_DATA_MEMBER(NAME) \
impl_do_not_use_i_really_mean_it_##NAME##_

#define KOKKOS_IMPL_INIT_ARGS_DATA_MEMBER_TYPE(NAME) impl_##NAME##_type
Copy link
Contributor

Choose a reason for hiding this comment

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

I find the code here with all the macros very hard to read and would rather see more boilerplate.
For these two macros, in particular, I don't see much of a reason to not replace them with their definition.

Copy link
Member Author

Choose a reason for hiding this comment

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

This was introduced before we added the getters and was really handy then. I would rather wait until C++17 is available to refactor. Then I will get rid of the member type and "inline" all data member references.

core/src/impl/Kokkos_InitializationSettings.hpp Outdated Show resolved Hide resolved
@crtrott crtrott added the Blocks Promotion Overview issue for release-blocking bugs label Jul 6, 2022
@masterleinad masterleinad added this to In progress in Kokkos Release 3.7 -- 2022 Target Date via automation Jul 6, 2022
@masterleinad masterleinad added this to the Tentative 3.7 Release milestone Jul 6, 2022
…nitiliazationSettings setters in converting constructor
Copy link
Contributor

@masterleinad masterleinad left a comment

Choose a reason for hiding this comment

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

Good enough for me.

// Serial::initialize() ever needs to take arguments from the input
// struct, you may remove this line of code.
(void)args;
(void)settings;
Copy link
Contributor

Choose a reason for hiding this comment

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

Minor: I know it wasn't done like this originally, but why not just comment out the variable name in the function declaration?

@dalg24
Copy link
Member Author

dalg24 commented Jul 7, 2022

OpenMPTarget timeout is clearly unrelated

@dalg24 dalg24 merged commit 0093b1b into kokkos:develop Jul 7, 2022
Kokkos Release 3.7 -- 2022 Target Date automation moved this from In progress to Done Jul 7, 2022
@dalg24 dalg24 deleted the new_init_args_struct branch July 7, 2022 20:58
ndellingwood added a commit to trilinos/Trilinos that referenced this pull request Aug 26, 2022
compatibility update for kokkos deprecated code removal, corresponding
to kokkos/kokkos#5135
ndellingwood added a commit to trilinos/Trilinos that referenced this pull request Aug 30, 2022
compatibility update for kokkos deprecated code removal, corresponding
to kokkos/kokkos#5135
ndellingwood added a commit to trilinos/Trilinos that referenced this pull request Aug 30, 2022
compatibility update for kokkos deprecated code removal, corresponding
to kokkos/kokkos#5135
ndellingwood added a commit to trilinos/Trilinos that referenced this pull request Aug 30, 2022
compatibility update for kokkos deprecated code removal, corresponding
to kokkos/kokkos#5135
ndellingwood added a commit to trilinos/Trilinos that referenced this pull request Aug 30, 2022
compatibility update for kokkos deprecated code removal, corresponding
to kokkos/kokkos#5135
ndellingwood added a commit to trilinos/Trilinos that referenced this pull request Aug 30, 2022
compatibility update for kokkos deprecated code removal, corresponding
to kokkos/kokkos#5135
ndellingwood added a commit to trilinos/Trilinos that referenced this pull request Aug 30, 2022
compatibility update for kokkos deprecated code removal, corresponding
to kokkos/kokkos#5135
ndellingwood added a commit to trilinos/Trilinos that referenced this pull request Aug 30, 2022
compatibility update for kokkos deprecated code removal, corresponding
to kokkos/kokkos#5135
ndellingwood added a commit to trilinos/Trilinos that referenced this pull request Aug 30, 2022
compatibility update for kokkos deprecated code removal, corresponding
to kokkos/kokkos#5135
ndellingwood added a commit to trilinos/Trilinos that referenced this pull request Aug 30, 2022
compatibility update for kokkos deprecated code removal, corresponding
to kokkos/kokkos#5135
ndellingwood added a commit to trilinos/Trilinos that referenced this pull request Aug 30, 2022
compatibility update for kokkos deprecated code removal, corresponding
to kokkos/kokkos#5135
ndellingwood added a commit to trilinos/Trilinos that referenced this pull request Aug 30, 2022
compatibility update for kokkos deprecated code removal, corresponding
to kokkos/kokkos#5135
ndellingwood added a commit to trilinos/Trilinos that referenced this pull request Aug 30, 2022
compatibility update for kokkos deprecated code removal, corresponding
to kokkos/kokkos#5135
ndellingwood added a commit to trilinos/Trilinos that referenced this pull request Aug 31, 2022
compatibility update for kokkos deprecated code removal, corresponding
to kokkos/kokkos#5135
ndellingwood added a commit to trilinos/Trilinos that referenced this pull request Aug 31, 2022
compatibility update for kokkos deprecated code removal, corresponding
to kokkos/kokkos#5135
@ajpowelsnl ajpowelsnl mentioned this pull request Nov 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Blocks Promotion Overview issue for release-blocking bugs
Development

Successfully merging this pull request may close these issues.

None yet

7 participants