[Mpi3-tools] [MPI3 Fortran] MPI function symbol naming convention for tools

[Jeff Squyres]

On Jun 24, 2011, at 12:54 PM, Martin Schulz wrote:

>> if (Craig's proposal is accepted) {
>> if (implementation has implemented Craig's proposal) {
>>     // call this "Case A"
>>     if (app uses mpif.h or "use mpi" interface) {
>>        tool will find mpi_send_f
>>        // ...and others listed in Craig's proposal
>>     }
>>     if (app uses "use mpi_f08" interface) {
>>        tool will find mpi_send_f08
>>        // ...and others listed in Craig's proposal
> 
> So, every send will go through this symbol,

Every call to MPI_Send in the "use mpi_f08" interface will go through this symbol.

> even if no
> choice buffer is used and a single pointer is sufficient?
> I.e., a MPI_Send(buf,1,MPI_INT, ...) as well?

I'm not quite sure how you would have a send without a choice buffer...?

In my mind, "choice buffer" means that anything can go in that position: a scalar, an array, a derived type instance, ...etc.  "Choice" means that the type is variable, even if it's scalar.

Do our definitions differ?

As Craig noted in his proposal, some MPI symbols in the "use mpi_f08" interface will be the same as those in the mpif.h/"use mpi" interface -- i.e., those without choice buffers and those without MPI handles.  E.g., MPI_WTICK, MPI_FINALIZE, etc.

> This is probably my lack of knowledge in Fortran compilers, but
> is this all even possible with regular compilers: I would assume
> that you can use an MPI 3.0 implementation with Craig's proposal
> (case A) with an older F77 or F90 compiler, right?

There is no such thing as an F77 compiler any more (i.e., a compiler that only supports up to the Fortran 77 specification).  There hasn't been for (at least) 10-15+ years.  Also, note that MPI has *NEVER* supported Fortran 77.  It is a popular misconception that it did (easiest point to mention: Fortran 77 limited symbol names to 6 characters (!), which MPI has never obeyed).

I suspect there aren't any F90 compilers left (i.e., compilers that only support up to the Fortran 90 specification), either (maybe g77, because that hasn't changed in years...?).

Example: pgif90 is NOT a Fortran-90-only compiler.  It supports lots of things beyond what was specified in Fortran 90.  That's many Fortran compilers have stopped using "f90" and "f77" in their executable names and started moving towards "pgifortran" and "ifort" and the like.

> If so, one would
> use "use mpi" or "mpif.h", i.e., case A.1. Can you do the name
> mapping from mpi_send to mpi_send_f - I thought this was a new
> feature from F08?

Yes, the mpif.h and "use mpi" interfaces can support the behind-the-scenes name remapping.

Remember -- this is not stuff that users will see.  Their old (correct) codes that compiled with mpif.h will still continue to compile and run with Craig's proposal.

>> Keep in mind:
>> 
>> - even if Craig's proposal is accepted, it'll take at least 6 months for this to become part of MPI-3
>> - even if Craig's proposal becomes part of MPI-3, implementations will likely take a long time before they support this new stuff
>> - implementations *could* support the old symbols for a while if they wanted to (e.g., MPI_SEND, mpi_send, mpi_send_, mpi_send__)
> 
> How? Each routine can only be mapped to a single
> symbol. Hence, either the mpi_send calls mpi_send_
> or mpi_send_f.

Weak symbols.

>> But that being said, what's the problem with testing for the optional arguments?  You're in a tool already, meaning that performance overhead is already assumed to be somewhere between (nonzero <--> high), so what's 1 or 2 more "if" statements?
> 
> Perhaps I didn't understand the proposal: as I understand Craig's
> proposal, any routine that would have an optional status argument
> would now have two corresponding C routines.

It would have 2 corresponding symbols; they don't have to be implemented in C.

> Supporting that
> in the tools is not a big deal, but having such naming exceptions
> and identifying which routines fall into this category can be hard
> for wrapper code generators (most tools generate the Fortran
> interface through a series of scripts).

Is that really a criteria to prevent moving the Fortran MPI interface forward?

Indeed, implementing array subsections (dope vectors) is likely to be a royal PITA for MPI implementors.  But it's clearly something that users want/need.

My point: implementors saying "it's haaarrdd!" is not (always) a good excuse to prevent doing something.  ;-)

> Not if the above decision tree is true - if I use MPI 2.2 compliant
> code (no MPI-3 features) and I use MPI 2.2 tools, but compile it
> against an MPI-3 implementation with Craig's proposal, I won't 
> be able to intercept any Fortran calls anymore, since the 
> implementation now calls the _f routines.

The Forum has clearly said many times that MPI-3 is free to break ABI backwards compatibility (and possibly even source code compatibility, although I would not say that everyone on the Forum agrees with that -- in fact, it's a pretty unpopular view).

So using an MPI-2.2 tool or application with an MPI-3 implementation without recompiling that tool/application (and updating/adapting tools who are looking for specific implementation features like symbols) -- yes, I can see how that would be problematic.

> This basically breaks
> backwards compatibility. I realize that we said that this may be
> the case for MPI, but its certainly an issue we need to be aware
> off. Also, we do have applications, as far as I know, that use the
> PMPI interface for themselves - hence, you would not only
> break tools, but also some applications.

The Forum will need to decide if this is important.  

My (current) feeling is that given the time lapse before this still will be necessary, there's plenty of time for tools and applications to adapt.  Put differently (and more harshly): application and tool writer laziness is not a good reason to inhibit progress.

Also, there is always the point that if your application / tool uses some MPI-2.2-but-not-MPI-3.0 feature, you can always use an older MPI(-2.x) implementation.

-- 
Jeff Squyres
jsquyres at cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/