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

[Jeff Squyres]

On Jun 23, 2011, at 3:39 AM, Martin Schulz wrote:

> That makes more sense now - just to clarify: the new names only
> apply if an application uses "use mpi_f08", otherwise the old
> interface applies. Is this correct?

It's almost that simple, but not quite.

An MPI application can use any of all of the interfaces.  In one .f90 file, for example, there could be a subroutine that uses mpif.h, another subroutine that uses "use mpi", and another that uses "use mpi_f08".

So tools will need to be expanded to cover all of the MPI Fortran interfaces; if you only catch the old names, you might miss some run-time information.

>>> So in one sense, we're not breaking tools because the use mpi_f08 interface is new.
> 
> 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..."  :-)

>>> In another sense, if we mandate specific symbols for mpif.h/use mpi, we might break some tools, but put ourselves in a better place for the future.  Since a tool already has to sense which back-end symbol to use mpif.h/use mpi (lower case, caps, 1 underscore, 2 underscores -- none of which are mandated by the Fortran spec, by the way; it's just common convention), is it really a hardship to add another symbol name to check during the tools configuration/building mechanism?
> 
> I am more worrying about existing tools - those would all
> have to be changed.

They're all going to have to be changed anyway.

However, it's not as bad as it sounds.  Tools today must intercept the mpif.h symbols by finding the right symbol to intercept:

  MPI_SEND
  mpi_send
  mpi_send_
  mpi_send__

In Craig's proposal, you now have to look for one more form of the symbol:

  mpi_send_f

Hence, if you add supporting the one new symbol, you'll cover all old MPI implementations and all new ones.  

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

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.

The "use mpi_f08" stuff is new, so tools obviously have to be expanded to instrument those symbols (and new types).  But I don't think that's the main point of your question.

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