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 at 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 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
>>
> _______________________________________________
> To manage subscription options or unsubscribe:
> https://lists.mpich.org/mailman/listinfo/devel