October 2017 - devel - mailman3.cels.anl.gov

Re: [mpich-devel] Sessions Considering Changing MPI_COMM_WORLD
by Jed Brown 30 Oct '17

30 Oct '17

Note that MPI_COMM_WORLD isn't required to be a compile-time constant in the current standard and Open MPI doesn't treat it as one. (It is a link-time constant.) So regardless of potential performance impact, standard-compliant user code cannot treat it as a compile-time constant (e.g., by using it in a case statement). I'm also skeptical about ability to measure an impact on user code and thought your SC paper was about compile-time specialization in the MPI implementation. As one data point, PETSc does not reference MPI_COMM_WORLD except for some optional diagnostics and it would be pretty easy to remove. Kenneth Raffenetti <raffenet(a)mcs.anl.gov> writes: > Strictly speaking, compile-time objects like MPI_COMM_WORLD impose less > overhead than dynamically created ones. See our SC paper for more > details :). > > Ken > > On 10/30/2017 05:51 PM, Jeff Hammond wrote: >> This is going to cause horrible problems. I hate to say it, but the time >> for MPI to have avoided hidden state was in the 1990s. >> >> Lots of MPI libraries create their own communicator from the >> compile-time constant rather than a communicator argument. Breaking even >> a few of these will ruin MPI’s exhalted reputation in the HPC world. >> >> The better option is to provide new headers and libraries for sessions >> that break backwards compatibility. Or just have users opt-in to >> sessions by not using MPI_COMM_WORLD at all. That way you’re only >> breaking code that wants this feature rather than many that don’t. >> >> What’s your Fortran story? If you don’t have a trivial solution for >> users of mpif.h, you’ve lost approximately half if MPI’s users. >> >> Jeff >> >> On Mon, Oct 30, 2017 at 11:33 AM Bland, Wesley <wesley.bland(a)intel.com >> <mailto:[email protected]>> wrote: >> >> The sessions working group is working on a proposal that, among >> other things, would change the way MPI_COMM_WORLD works. As much as >> I don't want to take things out of context for those who aren't >> familiar with the proposal, I'm not going to summarize the whole >> thing here. If you need that, look here: >> https://github.com/mpiwg-sessions/sessions-issues/wiki/sessions_cheat_sheet >> >> >> On today's call, we were trying to decide the result of a backward >> compatibility break for the MPI_COMM_WORLD symbol. We want to keep >> the MPI_COMM_WORLD symbol to allow legacy codes to work, but we >> don't want to make it a compiler symbol anymore. It would only exist >> if you call MPI_INIT. To that end, MPI_INIT would look something >> like this: >> >> MPI_Init(...) { >> MPI_Comm *comm; >> MPI_Session *session; >> >> MPI_Session_init(..., session); >> MPI_Group_create_from_session_name(&session, "mpi://WOLRD", comm); >> MPI_COMM_WORLD = *comm; >> } >> >> The problem here is that MPI_COMM_WORLD is no longer the >> compile-time constant that it was before. For example, if you're >> using MPI_COMM_WORLD in a library, this would cause problems. >> >> The working group is trying to figure out the results of this to >> decide whether this would cause horrible problems. It seems that as >> long as applications are reasonably well behaved and check if the >> library is initialized first, they should work correctly. >> >> What is this community's opinion of this? >> >> Thanks, >> Wesley >> _______________________________________________ >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/devel >> >> -- >> Jeff Hammond >> jeff.science(a)gmail.com <mailto:[email protected]> >> http://jeffhammond.github.io/ >> >> >> _______________________________________________ >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/devel >> > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel

1 0

Re: [mpich-devel] Sessions Considering Changing MPI_COMM_WORLD
by Kenneth Raffenetti 30 Oct '17

30 Oct '17

Strictly speaking, compile-time objects like MPI_COMM_WORLD impose less overhead than dynamically created ones. See our SC paper for more details :). Ken On 10/30/2017 05:51 PM, Jeff Hammond wrote: > This is going to cause horrible problems. I hate to say it, but the time > for MPI to have avoided hidden state was in the 1990s. > > Lots of MPI libraries create their own communicator from the > compile-time constant rather than a communicator argument. Breaking even > a few of these will ruin MPI’s exhalted reputation in the HPC world. > > The better option is to provide new headers and libraries for sessions > that break backwards compatibility. Or just have users opt-in to > sessions by not using MPI_COMM_WORLD at all. That way you’re only > breaking code that wants this feature rather than many that don’t. > > What’s your Fortran story? If you don’t have a trivial solution for > users of mpif.h, you’ve lost approximately half if MPI’s users. > > Jeff > > On Mon, Oct 30, 2017 at 11:33 AM Bland, Wesley <wesley.bland(a)intel.com > <mailto:[email protected]>> wrote: > > The sessions working group is working on a proposal that, among > other things, would change the way MPI_COMM_WORLD works. As much as > I don't want to take things out of context for those who aren't > familiar with the proposal, I'm not going to summarize the whole > thing here. If you need that, look here: > https://github.com/mpiwg-sessions/sessions-issues/wiki/sessions_cheat_sheet > > > On today's call, we were trying to decide the result of a backward > compatibility break for the MPI_COMM_WORLD symbol. We want to keep > the MPI_COMM_WORLD symbol to allow legacy codes to work, but we > don't want to make it a compiler symbol anymore. It would only exist > if you call MPI_INIT. To that end, MPI_INIT would look something > like this: > > MPI_Init(...) { > MPI_Comm *comm; > MPI_Session *session; > > MPI_Session_init(..., session); > MPI_Group_create_from_session_name(&session, "mpi://WOLRD", comm); > MPI_COMM_WORLD = *comm; > } > > The problem here is that MPI_COMM_WORLD is no longer the > compile-time constant that it was before. For example, if you're > using MPI_COMM_WORLD in a library, this would cause problems. > > The working group is trying to figure out the results of this to > decide whether this would cause horrible problems. It seems that as > long as applications are reasonably well behaved and check if the > library is initialized first, they should work correctly. > > What is this community's opinion of this? > > Thanks, > Wesley > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel > > -- > Jeff Hammond > jeff.science(a)gmail.com <mailto:[email protected]> > http://jeffhammond.github.io/ > > > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel >

1 0

Re: [mpich-devel] Sessions Considering Changing MPI_COMM_WORLD
by Jeff Hammond 30 Oct '17

30 Oct '17

This is going to cause horrible problems. I hate to say it, but the time for MPI to have avoided hidden state was in the 1990s. Lots of MPI libraries create their own communicator from the compile-time constant rather than a communicator argument. Breaking even a few of these will ruin MPI’s exhalted reputation in the HPC world. The better option is to provide new headers and libraries for sessions that break backwards compatibility. Or just have users opt-in to sessions by not using MPI_COMM_WORLD at all. That way you’re only breaking code that wants this feature rather than many that don’t. What’s your Fortran story? If you don’t have a trivial solution for users of mpif.h, you’ve lost approximately half if MPI’s users. Jeff On Mon, Oct 30, 2017 at 11:33 AM Bland, Wesley <wesley.bland(a)intel.com> wrote: > The sessions working group is working on a proposal that, among other > things, would change the way MPI_COMM_WORLD works. As much as I don't want > to take things out of context for those who aren't familiar with the > proposal, I'm not going to summarize the whole thing here. If you need > that, look here: > https://github.com/mpiwg-sessions/sessions-issues/wiki/sessions_cheat_sheet > > On today's call, we were trying to decide the result of a backward > compatibility break for the MPI_COMM_WORLD symbol. We want to keep the > MPI_COMM_WORLD symbol to allow legacy codes to work, but we don't want to > make it a compiler symbol anymore. It would only exist if you call > MPI_INIT. To that end, MPI_INIT would look something like this: > > MPI_Init(...) { > MPI_Comm *comm; > MPI_Session *session; > > MPI_Session_init(..., session); > MPI_Group_create_from_session_name(&session, "mpi://WOLRD", comm); > MPI_COMM_WORLD = *comm; > } > > The problem here is that MPI_COMM_WORLD is no longer the compile-time > constant that it was before. For example, if you're using MPI_COMM_WORLD in > a library, this would cause problems. > > The working group is trying to figure out the results of this to decide > whether this would cause horrible problems. It seems that as long as > applications are reasonably well behaved and check if the library is > initialized first, they should work correctly. > > What is this community's opinion of this? > > Thanks, > Wesley > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Sessions Considering Changing MPI_COMM_WORLD
by Bland, Wesley 30 Oct '17

30 Oct '17

The sessions working group is working on a proposal that, among other things, would change the way MPI_COMM_WORLD works. As much as I don't want to take things out of context for those who aren't familiar with the proposal, I'm not going to summarize the whole thing here. If you need that, look here: https://github.com/mpiwg-sessions/sessions-issues/wiki/sessions_cheat_sheet On today's call, we were trying to decide the result of a backward compatibility break for the MPI_COMM_WORLD symbol. We want to keep the MPI_COMM_WORLD symbol to allow legacy codes to work, but we don't want to make it a compiler symbol anymore. It would only exist if you call MPI_INIT. To that end, MPI_INIT would look something like this: MPI_Init(...) { MPI_Comm *comm; MPI_Session *session; MPI_Session_init(..., session); MPI_Group_create_from_session_name(&session, "mpi://WOLRD", comm); MPI_COMM_WORLD = *comm; } The problem here is that MPI_COMM_WORLD is no longer the compile-time constant that it was before. For example, if you're using MPI_COMM_WORLD in a library, this would cause problems. The working group is trying to figure out the results of this to decide whether this would cause horrible problems. It seems that as long as applications are reasonably well behaved and check if the library is initialized first, they should work correctly. What is this community's opinion of this? Thanks, Wesley

1 0