There are (compiled) libraries and object files containing the corresponding external references to MPI_SEND, mpi_send__, mpi_send_ or mpi_send. Therefore, you cannot simply change the interface of the MPI_Send routine without breaking these libraries. You can also not simply expect that they will be recompiled. In addition, the mpif.h include file doesn't have an interface block (and will still generate the external references above) and Fortran 90 module doesn't have an optional error argument in the interface block even if you expect that the Fortran 90 module/compiler supports some NO_ARG_CHECK attribute. Therefore, you cannot simply change the name of the Fortran MPI_Send routine to mpi_send_f. Hubert Ritzdorf NEC Germany
-----Original Message----- From: [email protected] [mailto:mpi3-fortran- [email protected]] On Behalf Of Jeff Squyres Sent: Friday, June 24, 2011 4:00 PM To: Martin Schulz Cc: MPI3 Tools; MPI-3 Fortran working group Subject: Re: [MPI3 Fortran] MPI function symbol naming convention for tools
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 [email protected] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
_______________________________________________ mpi3-fortran mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran
Click https://www.mailcontrol.com/sr/usm!Nh46RiHTndxI!oX7UqpixUKymCqxTDACcy67S9iI adHPAjIZPDMvmfJgurQ+nNutHdm6V!yDEGNPdlyNkQ== to report this email as spam.