[MPI3 Fortran] MPI function symbol naming convention for tools

[Martin Schulz]

Hi Jeff,

On Jun 23, 2011, at 4:07 AM, Jeff Squyres wrote:

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

Sure, there may be mixed mode programs.

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

Also that makes sense and is what I expected. What I meant
was more that existing tools work without modifications on 
programs that do not use mpi_f08 at all in any part. Is this
correct?

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

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?

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

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?

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

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

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

Sure, we'll have to work on this, but that was to be expected.

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