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

pass MPI_Comm by value #15159

Merged
merged 2 commits into from May 9, 2023
Merged

pass MPI_Comm by value #15159

merged 2 commits into from May 9, 2023

Conversation

tjhei
Copy link
Member

@tjhei tjhei commented Apr 29, 2023

Based on the recent discussion to return MPI_Comm by value from respective functions (see #14599 #15086 ), I think it makes sense to treat MPI_Comm as in int-like structure (instead of a class).

This is consistent with how the MPI standard is defined (int the API MPI_Comm is passed by value).
OpenMPI defines MPI_Comm to be a pointer: https://github.com/open-mpi/ompi/blob/5d9186207e63625091c292fe6425f3178ce4245d/ompi/include/mpi.h.in#L447
MPICH has it defined as an int:
https://github.com/pmodels/mpich/blob/eb36ab149dacf1870834b1c227f4e516eeec248d/src/include/mpi.h.in#L279

@bangerth
Copy link
Member

More precisely, all MPI data types need to be (i) PODs -- that's just C -- and (ii) the object itself does not own resources, and so can be trivially copied. This does not imply that the data type is small and can be cheaply copied, but in practice the only two ways the second requirement can usefully be implemented is to store most of the information in tables that the MPI implementation owns and manages, and the MPI data types only store either pointers or indices into these tables.

I don't have a particular opinion about whether we should pass references or values. The patch is ok with me (but I'm not ethusiastic about it either); I'll let others chime in.

@bangerth
Copy link
Member

You probably want a changelog entry.

@bangerth
Copy link
Member

bangerth commented May 3, 2023

Can you add the changelog entry?

@tjhei
Copy link
Member Author

tjhei commented May 8, 2023

updated.

@@ -0,0 +1,5 @@
Changed: MPI communicators (of type `MPI_Comm`) are not treated as
Copy link
Member

Choose a reason for hiding this comment

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

Did you mean to say "now"?

@@ -0,0 +1,5 @@
Changed: MPI communicators (of type `MPI_Comm`) are not treated as
trivially copyable POD types throughout the library. This means that
we store and pass them by value and by reference.
Copy link
Member

Choose a reason for hiding this comment

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

and here

Suggested change
we store and pass them by value and by reference.
we store and pass them by value instead of by reference.

?

Copy link
Member Author

Choose a reason for hiding this comment

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

somebody was clearly half asleep when he wrote these two sentences in the changelog entry. :-)

Copy link
Member

Choose a reason for hiding this comment

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

Dad brain?

Copy link
Member Author

Choose a reason for hiding this comment

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

Certainly. 😃

@bangerth bangerth merged commit ff6432d into dealii:master May 9, 2023
13 of 14 checks passed
@tjhei tjhei deleted the mpi_comm_by_value branch May 9, 2023 18:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants