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

[Martin Schulz]

Hi Jeff,

Thanks for the clarifications again - I think I am starting
to understand the nuances. A few more comments and
questions below. I'll try to write this up and will send this
to a few MPI tool developers who are not on our lists, so
we can get more feedback.

On Jun 24, 2011, at 10:16 AM, Jeff Squyres wrote:

> 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.

Sure, I meant - once Craig's proposal gets implemented, every
call will go through the new symbols (either _f or _f08).

Btw. what will be the naming conventions for the "pmpi"
counterparts? Will there also be a pmpi_send_f and a
pmpi_send_f08? I assume those will be Fortran calls,
i.e., take Fortran handles? Is there a way to call a C
equivalent for the f08 call (i.e., using descriptors, but
not having to map handles back)? The latter would 
be good, otherwise we'll have to translate F-handles
to C-handles, run the tools, convert them back to
F-handles, before the implementation takes them and
converts them back to C-handles.


> 
>> 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?

I was thinking about buffers that are represented by descriptors
rather than pointers. Choice buffer was the wrong word. So, when
you call an MPI_Send(buf,1,MPI_INT, ...) through the F08
interface, then we will intercept a call to mpi_send_f08 where
the first argument is a descriptor with a single entry pointing
to a single integer, correct?

> 
> 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.

Oh, wait - that's even more complicated - you are saying that
there will be no mpi_finalize_f08 call since it doesn't have
choice buffers or handles (do you mean status objects?)?
I though the complete API would be available as _f08.

> 
>> 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.

OK, good.

> 
> 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.

Sure, that's fine and good.

> 
>>> 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.

No, weak symbols won't be sufficient - either the routine
calls mpi_send_ or mpi_send_f - it can't call both. I don't
think supporting the old symbols is possible. Whether
that's a deal breaker or not will be up to the forum, though
(it may well not be).

> 
>>> 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.

Sure.

> 
>> 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?

I didn't say prevent - I just want to know all the implications
that this will have.

> 
> 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.  ;-)

But if its unnecessarily hard and we can get the same functionality
easier, then why not? :) The idea of having different interface names
depending on the routine and its functionality makes me a bit
worried. Since we won't have a full MPI 3.0 implementation anytime
(soon) - as with MPI 2.2 - tools often scan the header file and create
a custom version of the tool for the MPI implementation. Having
too many special cases and having to deduce the names with
that, could be a problem.

> 
>> 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).
> 

Sure - and I am personally probably fine with that.

> 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.

Recompiling is fine, but won't solve the issue here - things
still won't work anymore. 

I understand that this may be necessary here and we may have
to live with it (I'll try to get more feedback from the tools community
on the implications), but we need to make this part very clear
to tool writers and users.

> 
>> 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.

Sure :)

> 
> 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.

Will those still be around - are you planning to have a maintained
Open MPI 2.2 branch around?

Martin


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

________________________________________________________________________
Martin Schulz, schulzm at llnl.gov, http://people.llnl.gov/schulzm
CASC @ Lawrence Livermore National Laboratory, Livermore, USA