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 <[email protected]> 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 <[email protected] <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 [email protected] <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