[MPI3 Fortran] MPI function symbol naming convention for tools

[Jeff Squyres]

These emails are taking a lot of time -- perhaps you, Craig, and I should get on the phone in the immediate future and just hash this out.  A 30-min phone call can save a week's worth of excurciatiatingly-long, detailed emails...


On Jun 24, 2011, at 1:40 PM, Martin Schulz wrote:

> Btw. what will be the naming conventions for the "pmpi"
> counterparts? Will there also be a pmpi_send_f and a
> pmpi_send_f08?

Yes.

> I assume those will be Fortran calls,
> i.e., take Fortran handles?

They will accept Fortran handle parameters (including potentially descriptors), but they can be implemented in Fortran or C (or Cobol, if you really want to ;-) ).

> Is there a way to call a C
> equivalent for the f08 call (i.e., using descriptors, but
> not having to map handles back)?

I'm not sure what this means.

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

If you intercept MPI_SEND from Fortran today with a C function (before any of MPI's proposed f08 stuff), you have to convert handles back and forth from INTEGER with MPI_<foo>_c2f and MPI_<foo>_f2c.  This will be no different.

> I was thinking about buffers that are represented by descriptors
> rather than pointers. Choice buffer was the wrong word.

Ah; perhaps my definition is wrong -- I was still calling those "choice buffers," regardless of how the buffer appeared to the back-end implementation function (i.e., whether it was passed as a single pointer or a descriptor).

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

That's the goal, yes.

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

Craig proposed it this way to avoid redundant / unnecessary symbols.  Why have mpi_finalize_f and mpi_finalize_f08 when they'd be exactly the same?

If it could be done via weak symbols, maybe, then you're right that it would be less confusing for both the MPI implementor and the tool author to have the full sets of mpi_<foo>_f and mpi_<foo>_f08...?

Craig -- what say you to this idea?

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

It doesn't matter what the application calls -- weak symbols are provided so that the application can call any one of the weak symbols and they all resolve to 1 real symbol.

Hence, if the app/tool only uses symbol A, but the implementation exports A, B, C, and D, then there's no harm.

Specifically: if a tool calls the "old" form (e.g., MPI_SEND) but an implementation now provides the "new" form (mpi_send_f), if the implementation also provides a weak symbol for MPI_SEND, then the tool will still work.

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

Open MPI provides downloads for all old versions, and our SVN is fully open (including the tags for all prior releases).

We do stop supporting versions at some point, however.  E.g., Open MPI v1.2.x (and prior) is no longer supported. 

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