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

Restore some type-erasure to transform_mpi to avoid debug bloat #1390

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
43 changes: 13 additions & 30 deletions libs/pika/async_mpi/include/pika/async_mpi/transform_mpi.hpp
Original file line number Diff line number Diff line change
Expand Up @@ -52,6 +52,7 @@ namespace pika::mpi::experimental {
using pika::execution::experimental::continues_on;
using pika::execution::experimental::just;
using pika::execution::experimental::let_value;
using pika::execution::experimental::unique_any_sender;
using pika::execution::experimental::unpack;

// get mpi completion mode settings
Expand All @@ -63,40 +64,22 @@ namespace pika::mpi::experimental {
execution::thread_priority::boost :
execution::thread_priority::normal;

if (completions_inline)
{
auto f_completion = [mode, f = std::forward<F>(f)](auto&... args) mutable {
return just(std::forward_as_tuple(args...)) | unpack() |
dispatch_mpi(std::move(f)) | trigger_mpi(mode);
};
auto f_completion = [f = std::forward<F>(f), mode, completions_inline, p](
auto&... args) mutable -> unique_any_sender<> {
unique_any_sender<> s = just(std::forward_as_tuple(args...)) | unpack() |
dispatch_mpi(std::move(f)) | trigger_mpi(mode);
if (completions_inline) { return s; }
else { return std::move(s) | continues_on(default_pool_scheduler(p)); }
};
Comment on lines +67 to +73
Copy link
Contributor

Choose a reason for hiding this comment

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

The inline branch returns s as an any sender - the non inline returns an any sender of an any sender - do they get collapsed into one create, or can/should we just expand the other branch to just return one?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

In if (completions_inline) { return s; }, s is not going to get wrapped again and even a move construction should be avoided because of NRVO.

In the second branch there will indeed be two unique_any_senders. It's a tradeoff between debug bloat and wrapping. The first commit on this PR (aae6046) doesn't type-erase s; it only type-erases whatever is returned. That on its own already significantly reduces bloat, and then type-erasing s reduces bloat a bit more.


if (requests_inline)
{
return std::forward<Sender>(sender) | let_value(std::move(f_completion));
}
else
{
return std::forward<Sender>(sender) | continues_on(mpi_pool_scheduler(p)) |
let_value(std::move(f_completion));
}
if (requests_inline)
{
return std::forward<Sender>(sender) | let_value(std::move(f_completion));
}
else
{
auto f_completion = [mode, p, f = std::forward<F>(f)](auto&... args) mutable {
return just(std::forward_as_tuple(args...)) | unpack() |
dispatch_mpi(std::move(f)) | trigger_mpi(mode) |
continues_on(default_pool_scheduler(p));
};

if (requests_inline)
{
return std::forward<Sender>(sender) | let_value(std::move(f_completion));
}
else
{
return std::forward<Sender>(sender) | continues_on(mpi_pool_scheduler(p)) |
let_value(std::move(f_completion));
}
return std::forward<Sender>(sender) | continues_on(mpi_pool_scheduler(p)) |
let_value(std::move(f_completion));
}
}

Expand Down
Loading