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

[Martin Schulz]

Hi Jeff,

Thanks for the clarifications - that's definitely more clear
now. A few additional questions/comments inline below:

On Jun 24, 2011, at 7:00 AM, Jeff Squyres wrote:

> On Jun 23, 2011, at 10:51 PM, Martin Schulz wrote:
> 
>>>> I read Craig's email as if the existing interface (without using mpi_f08)
>>>> would get the new symbol as well. If I read you right, this is not the case.
>>> 
>>> That *is* the case.  That's why I started my sentence with "So in one sense..."  :-)
>> 
>> Now, I am confused - this seems to contradict the above.
>> If I compile a F77 only program that uses mpif.h and has a 
>> call to MPI_Recv, which symbol(s) do I get?
> 
> 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, even if no
choice buffer is used and a single pointer is sufficient?
I.e., a MPI_Send(buf,1,MPI_INT, ...) as well?

>      }
>  } else {
>      // implementation has NOT implemented Craig's proposal
>      // call this "Case B"
>      if (app uses mpif.h interface) {
>         tool will find MPI_SEND, mpi_send, mpi_send_, or mpi_send__

Yes, that's the common case covered by today's tools.

>      }
>      if (app uses "use mpi" interface) {
>         I doubt tools know how to find the symbols for functions
>         with choice buffers, because nothing is standardized
>         and there's (potentially) lots of function overloading

I agree - I don't know of any tool supporting this.

>      }
>  }
> } else {
>    // same as "Case B"
> }
> 

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

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

> 
> My point: I'm not too worried about tools needing to update to get the new symbol conventions because a) implementations have to update, too, and b) I think standardized symbol conventions put the MPI spec in a better place for the future -- *future* tools will have an easier time than current tools.
> 
>> Sure, the addition is not hard - the more complicated
>> part will be the routines for the optional parameters.
>> We can no longer deduce them automatically from
>> any header file and will always have to special code
>> them. Do we really need them? Why not pass a
>> STATUS_IGNORE argument?
> 
> I think that's under debate at the moment.
> 
> 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. 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).

> 
>>> And, more importantly, I believe there's plenty of time for existing tools to adapt (e.g., to add intercepting the 5th symbol) -- maybe a year or more.  OMPI will have a first prototype implementation soon; I imagine the others will follow over time (assuming that this proposal, or something like it, is passed into the MPI-3 spec over the course of the next 6 months).
>> 
>> In the meantime, they will be labeled as MPI 2.2 tools and will
>> work with any MPI 2.2 compliant code. As long as that still
>> works (and I see no reason why not) then I think things are fine.
> 
> This is what I'm saying.

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

> 
>>> Also note that there is no standardized nomenclature for intercepting "use mpi" symbols, so I'll bet you a high-quality beer that there are no portable tools that properly instrument "use mpi" interfaces.  OMPI's "use mpi" implementation, for example, *sometimes* calls the corresponding mpif.h symbol, but not always.  Heck, I'll even bet you another HQ beer that there's *no* MPI implementation that supports explicit Fortran interfaces for all MPI functions in its "use mpi" interfaces that has a corresponding interception / tracing tool -- specifically because of the lack of standardization of how to do it.
>>> 
>>> Craig's proposal gives you a way to reliably intercept the "use mpi" symbols.
>> 
>> Well, not quite - we still have to play the tricks for older MPIs
>> and for the parts of the codes that don't use the module. Those
>> will use the old naming convention, right?
> 
> I'm not sure I can parse your statement -- it doesn't seem to be a logical result of my text...?
> 
> The portion of my text that you were replying to was only speaking about the "use mpi" interface -- not mpif.h.  See above for discussions about mpif.h.
> 
> As for "use mpi": there is no naming convention for "use mpi" symbols right now.  Therefore, there's no commonality between MPI implementations.  Are there any tools that reliably, portably intercept all "use mpi" symbols right now?  I was under the impression that there were none, but perhaps I'm wrong...?

I think this is true.

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