[mpich-devel] [mpich-intel] Sessions Considering Changing MPI_COMM_WORLD

[Dinan, James]

IIUC, this would break code that uses MPI_COMM_WORLD as a static initializer, e.g., to initialize a global variable like "MPI_Comm mycomm = MPI_COMM_WORLD".

Why can't the handles themselves be compile-time constants corresponding to objects that are not created until the library is initialized (how it works now)?  Note that such handles are defined to be compile-time constants.  I don't know that they necessarily correspond to symbols that you can take an address of.

 ~Jim.

From: intel <intel-bounces at lists.mpich.org<mailto:intel-bounces at lists.mpich.org>> on behalf of "Bland, Wesley" <wesley.bland at intel.com<mailto:wesley.bland at intel.com>>
Date: Tuesday, October 31, 2017 at 10:16 AM
To: "devel at mpich.org<mailto:devel at mpich.org>" <devel at mpich.org<mailto:devel at mpich.org>>
Cc: "intel at mpich.org<mailto:intel at mpich.org>" <intel at mpich.org<mailto:intel at mpich.org>>
Subject: Re: [mpich-intel] [mpich-devel] Sessions Considering Changing MPI_COMM_WORLD

I misrepresented what I was trying to say here I think. I don't believe it's necessary to remove the symbol MPI_COMM_WORLD. What it does change (at least for MPICH-derived implementations) is that before MPI_INIT(), MPI_COMM_WORLD might be MPI_COMM_NULL (or something else with no meaning), and after MPI_INIT(), the handle would be changed to something more useful. The fact that the handle would change midstream is what's different.

On Oct 30, 2017, at 5:51 PM, Jeff Hammond <jeff.science at gmail.com<mailto:jeff.science at gmail.com>> wrote:

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.

This doesn't prevent the global variable from existing. In fact, if you were blindly using MPI_COMM_WORLD before without checking whether or not MPI was initialized, bad things were going to happen anyway. What this does do is say that if you haven't called MPI_INIT(), MPI_COMM_WORLD will probably point to MPI_COMM_NULL or something.

Perhaps saying that MPI_COMM_WORLD won't be a compile time constant isn't correct. The better way of saying it is probably that MPI_COMM_WORLD won't evaluate to anything useful until it's filled in during MPI_INIT(). If you end up using the sessions interface instead, the MPI library never has to create MPI_COMM_WORLD and incur all of the associated startup cost.

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.

Completely breaking backward compatibility is one option that was considered, but the working group thought that if we did things this way, it would still be possible for legacy codes to work without moving to the new Sessions interface.

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.

I think it's similar to what it is now. MPI_COMM_WORLD is a global variable that has no meaning until MPI_INIT() is called.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpich.org/pipermail/devel/attachments/20171031/a7bd2ca6/attachment.html>