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

[Jeff Squyres]

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
      }
  } 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__
      }
      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
      }
  }
} else {
    // same as "Case B"
}

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

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?

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

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

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