[mpich-devel] Sessions Considering Changing MPI_COMM_WORLD

[Kenneth Raffenetti]

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 at intel.com 
> <mailto:wesley.bland at 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 at gmail.com <mailto:jeff.science at gmail.com>
> http://jeffhammond.github.io/
> 
> 
> _______________________________________________
> To manage subscription options or unsubscribe:
> https://lists.mpich.org/mailman/listinfo/devel
>