March 2013 - mpiwg-fortran - mailman3.cels.anl.gov

Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
by Hubert Ritzdorf 22 Mar '13

22 Mar '13

Hi, MPI 3.0 Page 555, Lines 28-40 clearly requests a Fortran PMPI interface. "This requires, in C and Fortran, an alternate entry point name, with the prefi?x PMPI_ for each MPI function in each provided language binding and language support method." Thus goal 1 and 4 is violated. Items 2 and 3 of the strawman proposal define implementation details. The MPI standard doesn't define implementation details. For example, NEC MPI is never calling the C MPI_Test function in the Fortran MPI_Test function (which is implemented in C). Both items would hurt goal 2 for me. Hubert ________________________________ From: Craig Rasmussen [rasmus(a)cas.uoregon.edu] Sent: Friday, March 22, 2013 4:29 PM To: MPI-3 Fortran working group Cc: Martin Schulz; Bill Long; Hubert Ritzdorf Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind Bill Long, Jeff Squyres, and I had a phone conversation yesterday and came up with a straw man proposal. We believe it fixes the LOGICAL argument problem while satisfying three major goals: 1. Backwards compatibility. 2. Flexibility so that efficient implementations can be produced on a variety of hardware. 3. Not dramatically increase the complexity for the tools community. 4. Ensure that the changes won't be seen by ordinary Fortran MPI users. The straw man proposal is: 1. Remove the current binding names for MPI functions with LOGICAL dummy arguments (. This must be done because these interfaces break the Fortran standard. 2. Replace the current binding names for MPI functions with LOGICAL dummy arguments with a different name and replacing LOGICAL type with default INTEGER arguments. The name must be changed so as to not conflict with the current name with LOGICAL arguments. For example, the binding name "MPI_Test_f08" will be replaced by "MPI_Test_int_f08" (exact replacement name open for discussion). The Fortran implementation of the function MPI_Test must call MPI_Test_int_f08 as soon as possible for the tools implementers. 3. Implementation of the Fortran PMPI calling convention will be made optional (we think it already it). If an MPI implementer doesn't provide the MPI_F08 binding names, then it must call the C MPI implementation in a thin Fortran wrapper so that the tools implementers can intercept the call in C. An MPI implementation shall not provide/call both the MPI_F08 binding name and the C name. Option 2 allows some MPI vendors to implement MPI functions entirely within Fortran (using the MPI_f08 binding names), if this is more efficient. Option 3 allows some MPI implementations to place Fortran wrappers inside modules where they may be inlined by the compiler for efficiency. Craig Rasmussen CAS Scientific Programmer rasmus(a)cas.uoregon.edu<mailto:[email protected]> Click here<https://www.mailcontrol.com/sr/ScYsd3zUlOTGX2PQPOmvUlvAwUAcTfZnJtM7jRgdQaMz…> to report this email as spam.

1 0

Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
by Craig Rasmussen 22 Mar '13

22 Mar '13

Bill Long, Jeff Squyres, and I had a phone conversation yesterday and came up with a straw man proposal. We believe it fixes the LOGICAL argument problem while satisfying three major goals: 1. Backwards compatibility. 2. Flexibility so that efficient implementations can be produced on a variety of hardware. 3. Not dramatically increase the complexity for the tools community. 4. Ensure that the changes won't be seen by ordinary Fortran MPI users. The straw man proposal is: 1. Remove the current binding names for MPI functions with LOGICAL dummy arguments (. This must be done because these interfaces break the Fortran standard. 2. Replace the current binding names for MPI functions with LOGICAL dummy arguments with a different name and replacing LOGICAL type with default INTEGER arguments. The name must be changed so as to not conflict with the current name with LOGICAL arguments. For example, the binding name "MPI_Test_f08" will be replaced by "MPI_Test_int_f08" (exact replacement name open for discussion). The Fortran implementation of the function MPI_Test must call MPI_Test_int_f08 as soon as possible for the tools implementers. 3. Implementation of the Fortran PMPI calling convention will be made optional (we think it already it). If an MPI implementer doesn't provide the MPI_F08 binding names, then it must call the C MPI implementation in a thin Fortran wrapper so that the tools implementers can intercept the call in C. An MPI implementation shall not provide/call both the MPI_F08 binding name and the C name. Option 2 allows some MPI vendors to implement MPI functions entirely within Fortran (using the MPI_f08 binding names), if this is more efficient. Option 3 allows some MPI implementations to place Fortran wrappers inside modules where they may be inlined by the compiler for efficiency. Craig Rasmussen CAS Scientific Programmer rasmus(a)cas.uoregon.edu

1 0

Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
by Hubert Ritzdorf 22 Mar '13

22 Mar '13

Yes, this was also my intention. The Fortran compiler doesn't check any interoperability issues since it can assume that a Fortran interoperability is guaranteed by the underlying subroutine/function. The Fortran compiler uses the specified name to reference the subroutine/function. All. other interoperability are solved by the function/subroutine such as in the non BIND(C) case and such as currently solved by the MPI libraries. Hubert ________________________________________ From: mpi3-fortran-bounces(a)lists.mpi-forum.org [mpi3-fortran-bounces(a)lists.mpi-forum.org] on behalf of Bill Long [longb(a)cray.com] Sent: Thursday, March 21, 2013 8:47 PM To: mpi3-fortran(a)lists.mpi-forum.org Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind My perspective was that the only functionality here is to specify an alternate external name for the Fortran procedure. I assume that the caller and callee are compiled with the same compiler, so that the issues around vendor-specific calling conventions are not a problem. (This is why I preferred the NAME( .. ) form, since it omits any concept of a binding different from the normal conventions for the processor, except the name.) Cheers, Bill On 3/21/13 2:13 PM, Tobias Burnus wrote: > Craig Rasmussen wrote: >> BIND(FORTRAN, name="MPI_Test_f08") seems like a great idea. >> Unfortunately I can't find it in the Fortran standard :-( > > I have to admit that I do not really see the advantage of having such a > binding name. Surely, it voids issues to find out about the name > mangling of a compiler. But besides the mangling, different compilers > also handle other things differently: > * Function results: By return value or as by-reference argument. > Especially for COMPLEX > * Handling of string lengths - especially for character arrays > * Array descriptors - might be different from the TS29113 array descriptor > * etc. > > In case of BIND(C), most of the ABI issues is defined by the platform > ABI together with the C standard, which mostly solves the interop issues > between different C compiler and different Fortran compilers for BIND(C) > procedures. But NAME()/Bind(Fortran) doesn't. > > With all those issues, I do not really see how NAME(...) or > BIND(Fortran,name=...) would help - except in very special cases. > > Tobisa > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran -- Bill Long longb(a)cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101 _______________________________________________ mpi3-fortran mailing list mpi3-fortran(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran Click https://www.mailcontrol.com/sr/qAqGokvOpYnGX2PQPOmvUsPk3Ki21lNCN8bSIIHOpu6s… to report this email as spam.

1 0

Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
by Bill Long 21 Mar '13

21 Mar '13

My perspective was that the only functionality here is to specify an alternate external name for the Fortran procedure. I assume that the caller and callee are compiled with the same compiler, so that the issues around vendor-specific calling conventions are not a problem. (This is why I preferred the NAME( .. ) form, since it omits any concept of a binding different from the normal conventions for the processor, except the name.) Cheers, Bill On 3/21/13 2:13 PM, Tobias Burnus wrote: > Craig Rasmussen wrote: >> BIND(FORTRAN, name="MPI_Test_f08") seems like a great idea. >> Unfortunately I can't find it in the Fortran standard :-( > > I have to admit that I do not really see the advantage of having such a > binding name. Surely, it voids issues to find out about the name > mangling of a compiler. But besides the mangling, different compilers > also handle other things differently: > * Function results: By return value or as by-reference argument. > Especially for COMPLEX > * Handling of string lengths - especially for character arrays > * Array descriptors - might be different from the TS29113 array descriptor > * etc. > > In case of BIND(C), most of the ABI issues is defined by the platform > ABI together with the C standard, which mostly solves the interop issues > between different C compiler and different Fortran compilers for BIND(C) > procedures. But NAME()/Bind(Fortran) doesn't. > > With all those issues, I do not really see how NAME(...) or > BIND(Fortran,name=...) would help - except in very special cases. > > Tobisa > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran -- Bill Long longb(a)cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101

1 0

Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
by Tobias Burnus 21 Mar '13

21 Mar '13

Craig Rasmussen wrote: > BIND(FORTRAN, name="MPI_Test_f08") seems like a great idea. > Unfortunately I can't find it in the Fortran standard :-( I have to admit that I do not really see the advantage of having such a binding name. Surely, it voids issues to find out about the name mangling of a compiler. But besides the mangling, different compilers also handle other things differently: * Function results: By return value or as by-reference argument. Especially for COMPLEX * Handling of string lengths - especially for character arrays * Array descriptors - might be different from the TS29113 array descriptor * etc. In case of BIND(C), most of the ABI issues is defined by the platform ABI together with the C standard, which mostly solves the interop issues between different C compiler and different Fortran compilers for BIND(C) procedures. But NAME()/Bind(Fortran) doesn't. With all those issues, I do not really see how NAME(...) or BIND(Fortran,name=...) would help - except in very special cases. Tobisa

1 0

Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
by Bill Long 21 Mar '13

21 Mar '13

On 3/21/13 1:22 PM, Craig Rasmussen wrote: > BIND(FORTRAN, name="MPI_Test_f08") seems like a great idea. > Unfortunately I can't find it in the Fortran standard :-( And it would be a while before it was there. We could argue that one of the uses of ENTRY was simply to give a procedure an alternate name. With Entry declared obsolete, we could add a NAME("MPI_Test_f08") optional suffix to provide that capability. There is one minor question with that; the name mangling rules for BIND(C,name="xxx") are technically not that the external name is xxx, but rather the external name is the external name that a C function with the C name of xxx would have. We could keep this same rule for a NAME( ) suffix, since I think that is what we really want here. > > Perhaps J3 would be amenable to adding FORTRAN to language-binding-spec. That would seem a lot less likely. It would be convenient to also allow more than one NAME= spec in a BIND(C,...) clause. That might pass. Cheers, Bill > > Craig Rasmussen > CAS Scientific Programmer > rasmus(a)cas.uoregon.edu <mailto:[email protected]> > > > On Mar 21, 2013, at 10:11 AM, Hubert Ritzdorf wrote: > >>> I believe the NEC Fortran MPI API may do similar things. >> >> This is right. >> The tool guys are mainly looking for a well-defined name. >> I think that it is a bad idea to kill backward compatibility, Fortran >> profiling interface >> and optimization possibilities of MPI implementers in order to get >> this well-defined name. >> >> It would be possibly simpler to add a specific BIND(Fortran, >> name="MPI_Test_f08") to Fortran >> which sets the linker name instead of using BIND(C, >> name="MPI_Test_f08") and we could >> avoid all the interoperability problems which were found till now (and >> in future). >> >> MPI_Test is a relatively simple function. We have much more complex >> functions which >> might increase scalability problems (for example additional memory >> allocation for MPI_Alltoallw in order to transform datatypes, possibly >> counts, displacements) >> for this requested approach. >> >> The upper routines/functions might become complex or >> cpu-time relevant (example: implementation of MPI_SUBARRAYS_SUPPORTED). >> In this case, the usage of performance (or debugging) tools which >> ignore the work in >> this upper functions (since these tools see only the C MPI functions) >> might >> become problematic. >> >> Hubert >> ________________________________________ >> From: mpi3-fortran-bounces(a)lists.mpi-forum.org >> <mailto:[email protected]> >> [mpi3-fortran-bounces(a)lists.mpi-forum.org >> <mailto:[email protected]>] on behalf of Jeff >> Squyres (jsquyres) [jsquyres(a)cisco.com <mailto:[email protected]>] >> Sent: Thursday, March 21, 2013 4:38 PM >> To: MPI-3 Fortran working group >> Cc: Martin Schulz >> Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 >> interface - issue with the LOGICAL kind >> >> On Mar 21, 2013, at 8:26 AM, Craig Rasmussen <rasmus(a)cas.uoregon.edu >> <mailto:[email protected]>> wrote: >> >>> I talked with Martin yesterday and he would be happy to have the >>> requirement in the standard that the Fortran wrappers MUST call the >>> MPI C interface. This would much simplify things for the tools >>> community. (I had earlier thought he would object to this solution.) >> >> No! This is NOT a good idea to mandate. >> >> Open MPI currently has a bunch of Fortran functions that do NOT call >> the corresponding MPI_<foo> C function. Instead, they call some other >> back-end, internal function. >> >> I believe the NEC Fortran MPI API may do similar things. >> >> -- >> Jeff Squyres >> jsquyres(a)cisco.com <mailto:[email protected]> >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> >> _______________________________________________ >> mpi3-fortran mailing list >> mpi3-fortran(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran >> >> >> Click >> https://www.mailcontrol.com/sr/Geaaq1rkMOPGX2PQPOmvUpJBCTqJzJUeYtFmk42MgAlO… >> to report this email as spam. >> >> _______________________________________________ >> mpi3-fortran mailing list >> mpi3-fortran(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran > -- Bill Long longb(a)cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101

1 0

Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
by Craig Rasmussen 21 Mar '13

21 Mar '13

BIND(FORTRAN, name="MPI_Test_f08") seems like a great idea. Unfortunately I can't find it in the Fortran standard :-( Perhaps J3 would be amenable to adding FORTRAN to language-binding-spec. Craig Rasmussen CAS Scientific Programmer rasmus(a)cas.uoregon.edu On Mar 21, 2013, at 10:11 AM, Hubert Ritzdorf wrote: >> I believe the NEC Fortran MPI API may do similar things. > > This is right. > The tool guys are mainly looking for a well-defined name. > I think that it is a bad idea to kill backward compatibility, Fortran profiling interface > and optimization possibilities of MPI implementers in order to get this well-defined name. > > It would be possibly simpler to add a specific BIND(Fortran, name="MPI_Test_f08") to Fortran > which sets the linker name instead of using BIND(C, name="MPI_Test_f08") and we could > avoid all the interoperability problems which were found till now (and in future). > > MPI_Test is a relatively simple function. We have much more complex functions which > might increase scalability problems (for example additional memory > allocation for MPI_Alltoallw in order to transform datatypes, possibly counts, displacements) > for this requested approach. > > The upper routines/functions might become complex or > cpu-time relevant (example: implementation of MPI_SUBARRAYS_SUPPORTED). > In this case, the usage of performance (or debugging) tools which ignore the work in > this upper functions (since these tools see only the C MPI functions) might > become problematic. > > Hubert > ________________________________________ > From: mpi3-fortran-bounces(a)lists.mpi-forum.org [mpi3-fortran-bounces(a)lists.mpi-forum.org] on behalf of Jeff Squyres (jsquyres) [jsquyres(a)cisco.com] > Sent: Thursday, March 21, 2013 4:38 PM > To: MPI-3 Fortran working group > Cc: Martin Schulz > Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind > > On Mar 21, 2013, at 8:26 AM, Craig Rasmussen <rasmus(a)cas.uoregon.edu> wrote: > >> I talked with Martin yesterday and he would be happy to have the requirement in the standard that the Fortran wrappers MUST call the MPI C interface. This would much simplify things for the tools community. (I had earlier thought he would object to this solution.) > > No! This is NOT a good idea to mandate. > > Open MPI currently has a bunch of Fortran functions that do NOT call the corresponding MPI_<foo> C function. Instead, they call some other back-end, internal function. > > I believe the NEC Fortran MPI API may do similar things. > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > > > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran > > > Click https://www.mailcontrol.com/sr/Geaaq1rkMOPGX2PQPOmvUpJBCTqJzJUeYtFmk42MgAlO… to report this email as spam. > > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran

1 0

Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
by Hubert Ritzdorf 21 Mar '13

21 Mar '13

> I believe the NEC Fortran MPI API may do similar things. This is right. The tool guys are mainly looking for a well-defined name. I think that it is a bad idea to kill backward compatibility, Fortran profiling interface and optimization possibilities of MPI implementers in order to get this well-defined name. It would be possibly simpler to add a specific BIND(Fortran, name="MPI_Test_f08") to Fortran which sets the linker name instead of using BIND(C, name="MPI_Test_f08") and we could avoid all the interoperability problems which were found till now (and in future). MPI_Test is a relatively simple function. We have much more complex functions which might increase scalability problems (for example additional memory allocation for MPI_Alltoallw in order to transform datatypes, possibly counts, displacements) for this requested approach. The upper routines/functions might become complex or cpu-time relevant (example: implementation of MPI_SUBARRAYS_SUPPORTED). In this case, the usage of performance (or debugging) tools which ignore the work in this upper functions (since these tools see only the C MPI functions) might become problematic. Hubert ________________________________________ From: mpi3-fortran-bounces(a)lists.mpi-forum.org [mpi3-fortran-bounces(a)lists.mpi-forum.org] on behalf of Jeff Squyres (jsquyres) [jsquyres(a)cisco.com] Sent: Thursday, March 21, 2013 4:38 PM To: MPI-3 Fortran working group Cc: Martin Schulz Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind On Mar 21, 2013, at 8:26 AM, Craig Rasmussen <rasmus(a)cas.uoregon.edu> wrote: > I talked with Martin yesterday and he would be happy to have the requirement in the standard that the Fortran wrappers MUST call the MPI C interface. This would much simplify things for the tools community. (I had earlier thought he would object to this solution.) No! This is NOT a good idea to mandate. Open MPI currently has a bunch of Fortran functions that do NOT call the corresponding MPI_<foo> C function. Instead, they call some other back-end, internal function. I believe the NEC Fortran MPI API may do similar things. -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ _______________________________________________ mpi3-fortran mailing list mpi3-fortran(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran Click https://www.mailcontrol.com/sr/Geaaq1rkMOPGX2PQPOmvUpJBCTqJzJUeYtFmk42MgAlO… to report this email as spam.

1 0

Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
by Craig Rasmussen 21 Mar '13

21 Mar '13

So what is the state of things regarding LOGICALs? Is the following summary valid? Can we take a straw vote on solution paths? 1. We have to do something about Logical. Alternative solutions to vote: 1a. Kill BIND(C) for interfaces with Logical variables. Fortran implementations must call C routines from thin wrapper. Fortran implementers may use modules with thin Fortran wrappers. 1b. Replace existing BIND(C) interfaces with Logical variables and use Integer instead of Logical for the dummy arguments. Overload with a purely Fortran interface using Logical arguments for normal Fortran users. Implementations must call the BIND(C) interface with Integer arguments for tools usage. This new interface would have to be renamed so not to clash with existing *_f08 names. 2. We don't HAVE to do anything else (I assume). But should we. Alternatives to vote: 2a. Leave everything else alone. Use current BIND(C) interfaces for functions not using LOGICAL. 2b. Get rid of BIND(C) altogether. Require Fortran implementations to call C implementation from thin Fortran wrapper. Implementers are free to place Fortran wrappers in a module. This choice allows significant reduction in implementation complexity for MPI library vendors and for tools. 2c. Get rid of most of BIND(C) Fortran interfaces but keep a few that make sense. Perhaps the routines with callbacks fit in this category. 3. When to stage the changes? MPI 3.1 or 4.0? Alternatives to vote: 3a. Make changes as soon as possible. 3b. Change LOGICAL now, wait to do additional changes (if any) until MPI 3.1. 3b. Change LOGICAL now, wait to do additional changes (if any) until MPI 4.0. 4. Other votes? Craig Rasmussen CAS Scientific Programmer rasmus(a)cas.uoregon.edu On Mar 21, 2013, at 8:47 AM, Jeff Squyres (jsquyres) wrote: > On Mar 21, 2013, at 8:44 AM, "Schulz, Martin" <schulzm(a)llnl.gov> wrote: > >> I feared that this would be the reaction and that were also my original reservations. From a tools perspective this would indeed be the easiest and cleanest solution, but I can see the downside. Implementation effort for rewriting aside (which I realize is important), do you expect a large performance impact, though? > > > I can't speak for NEC. > > The reason we did it this was in OMPI was not for performance -- it was for implementation-specific reasons. That is, there are some cases where we want to do something different for the Fortran implementation vs. the C implementation. One obvious example of this is for just about any function involving callbacks. > > MPICH may not have this issue because their handles are always integers, but for OMPI, C handles=pointers/F handles=integers, so we have to do some swizzling/de-swizzling for the conversion. > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > > > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran

1 0

Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
by Bill Long 21 Mar '13

21 Mar '13

On 3/21/13 2:44 AM, Rolf Rabenseifner wrote: > Thank you for the answers. Four comments: > > 1. About the linker names and intenal call sequence: > >>> I think that Bill's proposal kills the Fortran Profiling Interface. >>> If the user defines a >>> subroutine MPI_Test (....) >>> do something >>> call PMPI _Test() >>> do something >>> end subroutine MPI_Test > > Yes, this is true. Having these two implementation options > A. Internal real MPI C calls with > A1. standardized Fortran linker names, or with > A2. non-standardized Fortran names, i.e. within a Fortran module. > B. Standardized Fortran linker names. > would kill the upper Fortran example as soon as an implementation > chooses A2. > > Bill, do you have an idea how to solve the A2 problem. > Is it still possible to provide the standardized names > when you somehow inline the wrappers? Yes, this is possible. In fact, I think it will be required because of the requirement to still support mpif.h. Users who use only mpif.h would not have access to the module routines. Therefore, it would be necessary for the implementation to take a copy of the wrappers in the mpi module (the new descriptor versions are not available with mpif.h if I understand the rules) and make a standalone file that is compiled separately. This would be done mechanically to avoid maintaining this file separately. The stand-alone file would result in external linker names like mpi_send_ for the generic Linux case. The compiler would likely not inline these, though a particularly aggressive one might, unless told otherwise. As far as the PMPI versions, one option would be to just replicate the wrapper routines in the standalone file made for the mpif.h users, but with the routine name changed to add a P at the beginning. Again, this would be a mechanical change. Another option would be to insert an ENTRY statement in the files as a way to give the routine a second name (saves space in the library, but ENTRY is considered obsolete). So I'd suggest the duplicate wrappers with the P-changed name. These routines are all short, so library size seems like a minor issue. Since you cannot have two routines with external name pmpi_send_, I assume that the pmpi_xxx Fortran versions do not exist for the new descriptor argument variants. > Then, we would have only A1 which allows that a pure PMPI > Fortran user can freely choose to intercept the Fortran > or the C interface. > > 2. About MPI_Send_desc: > > Yes, Bill, you are absolutely right. > I thought that the MPI_Isend_desc internally calls MPI_Isend, > but this would be an implementation that internally > copies the non-contiguous Fortran application buffer > into a contiguous scratch buffer and then calls MPI_Isend > (the scratch buffer is released latest in MPI_Wait or MPI_Test). > Optimized solutions would do flattening on the fly > of the combination of the description of the Fortran buffer > combined with the description in the datatype handle, > and this double-flattening within the MPI_Isend_desc. Right. I had assumed that the MPI_Send_cdesc would do something like if (buf is contiguous) then extract the buf address from the descriptor and use it to call MPI_Send. The other arguments are identical and just pass through. else work through the descriptor, calling low level transport routines on sub-blocks of the buffer. We should at least write the rules such that an implementation like this is allowed. Making a copy of the whole buffer is potentially dangerous of you are low on available memory and the buffer is large. Cheers, Bill > > Therefore special naming for option A must be defined. > > This is only for the MPI routine groups MPI_SEND > and MPI_ISEND (see MPI-3.0, page 607 and ticket #364) > > > 3. Routine groups: > > All what we do should be done per routine group, > i.e., mpi.h tells by macros how it is done within > the specific routine groups. > > > 4. My apologies to Hubert. > > The list should have been >>>> I need at least answers for >>>> - mpich (Bill Long), >>>> - OpenMPI (Jeff or Craig), > - NEC MPI (Hubert), > - other, if there are other independent > mpi_f08 implementations, >>>> - some tools people. > > Best regards > Rolf > > ----- Original Message ----- >> From: "Bill Long" <longb(a)cray.com> >> To: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> >> Cc: "Martin Schulz" <schulzm(a)llnl.gov>, "MPI-3 Fortran working group" <mpi3-fortran(a)lists.mpi-forum.org> >> Sent: Wednesday, March 20, 2013 9:40:08 PM >> Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind >> My impression is that Rolf's proposal was to offer two options: >> >> a) no bind(c) on the Fortran wrappers, no requirements on the Fortran >> external names, but the wrappers are REQUIRED to call the C library >> routines. >> >> b) specific external names are required for the Fortran-called >> routines, >> but they do not have to be wrappers. (Still a bit unclear to me in >> this case where bind(c) might be required). >> >> On 3/20/13 2:58 PM, Jeff Squyres (jsquyres) wrote: >>> Not only that, I think that there are some cases where tools *need* >>> to intercept the Fortran call, not the C call. In OMPI, for example, >>> we have a few corner cases where the Fortran MPI subroutine does >>> *not* call the corresponding C MPI API function. Instead, it calls a >>> back-end OMPI routine. >>> >> >> True for implementations using option (b), but not for the (a) case. >> >>> One obvious case that jumps to mind is anything involving a >>> callback. >> >> Looking at the callback examples on page 268, I have some questions: >> >> 1) The BIND(C) and an argument of type LOGICAL are likely >> incompatible, >> so either the BIND(C) or the LOGICAL needs to go. >> >> 2) The external names for the C and Fortran versions are different. I >> assume this does not matter assuming that the function that is calling >> these has only an address, and not a name, to call. But how does the >> function know the calling signature for the callback routine with only >> a >> procedure pointer to work with? >> >> If I were writing a code with a callback like this, I would want to >> assume the C prototype even of the code was in Fortran. I assume the >> existence of the separate (and apparently flawed) Fortran interface is >> for legacy code. But there should not be legacy mpi_f08 code. A bit >> confusing. >> >>> >>> If you have integer handles in C, they might be able to get away >>> with not swizzling/de-swizzling the arguments to the callback to the >>> proper language. But this is not always the case. >>> >>> >>> >>> On Mar 20, 2013, at 12:29 PM, Hubert Ritzdorf >>> <Hubert.Ritzdorf(a)emea.nec.com> wrote: >>> >>>> Hi, >>>> >>>> I think that Bill's proposal kills the Fortran Profiling Interface. >>>> >>>> If the user defines a >>>> >>>> subroutine MPI_Test (....) >>>> >>>> do something >>>> >>>> call PMPI _Test() >>>> >>>> do something >>>> >>>> end subroutine MPI_Test >> >> I was under the impression that users would not directly call PMPI >> routines. Those were for the tools people. Why would a normal user >> want to do something like the above? >> >>>> >>>> then this function will never be executed because the Fortrran >>>> compiler may have already >>>> inlined the MPI_Test subroutine in the original code or the module >>>> version of MPI_Test is used. >> >> In the scope where this routine is called, the Fortran wrapper would >> have to be inaccessible. That would be done by NOT having a USE of the >> module in this scope. The external name of the module procedure would >> be >> mangled to include the name of the module, whereas a stand-alone >> routine like this would have an external name like mpi_test_ . The >> linker would see these as different routines. >> >> >> Cheers, >> Bill >> >> >>>> >>>> Hubert >>>> ________________________________________ >>>> From: mpi3-fortran-bounces(a)lists.mpi-forum.org >>>> [mpi3-fortran-bounces(a)lists.mpi-forum.org] on behalf of Rolf >>>> Rabenseifner [rabenseifner(a)hlrs.de] >>>> Sent: Wednesday, March 20, 2013 6:09 PM >>>> To: longb(a)cray.com; MPI-3 Fortran working group >>>> Cc: Martin Schulz >>>> Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 >>>> interface - issue with the LOGICAL kind >>>> >>>> This mail contains a proposal how we can solve the current >>>> Fortran problems and possibly making the tools people also happy. >>>> >>>> I need at least answers for >>>> - mpich (Bill Long), >>>> - OpenMPI (Jeff or Craig), >>>> - some tools people. >>>> >>>> Let me summarize what I've learnt so far for mpi_f08: >>>> >>>> - #364 about LOGICAL correction is a must. >>>> - MPI-3.0 allows BIND(C) and non-BIND(C), with the >>>> new restrictions in #364 >>>> - BIND(C) needs TR29113, therefore any implementation now >>>> should use non-BIND(C) for all non-TR29113 compilers. >>>> - Most (or all) try to use the non-BIND(C) interface. >>>> - Best way to do this are thin wrappers in Fortran that >>>> internally call >>>> - the oficial MPI-3.0 C binding >>>> (here, the tools people have a problem because they >>>> expect to wrap the Fortran interface and may therefore >>>> double-wrap), or >>>> - or an internal MPI-3.0 C routine >>>> (which is half-perfect for the tools folk, because >>>> they have to handle the implementation-dependant >>>> Fortran names with underscores). >>>> - And at least Bill wants to include the Fortran MPI >>>> library routines itselves in the mpi_f08 module. >>>> This is in conflict with the current MPI-3.0 >>>> linker naming rules. >>>> >>>> Implications and proposal: >>>> - We should rewrite the linker names section MPI-3.0 17.1.5 >>>> with following goals: >>>> - Allow additionally to define that the PMPI is provided >>>> only on the MPI C interface and the Fortran MPI routines >>>> internally call the C interface; >>>> again, a macro definition in mpi.h tells whether this >>>> is chosen. >>>> Question: Would this cause a problem when linking a >>>> C or Fortran user application with some own >>>> MPI_Test etc. profiling routines that internally call >>>> PMPI_Test? >>>> - If Fortran profiling is done through the MPI C binding >>>> then there are no rules about the Fortran linker names >>>> needed, and therefore, one may put the thin Fortran >>>> wrappers into a Fortran module. >>>> - We can define BIND(C) for MPI routine groups as a >>>> future option that is currently not used. >>>> This would reduce the current effort for the tools people. >>>> Is there anybody who wants to implement one of the Fortran >>>> routine groups with BIND(C)? >>>> >>>> I would expect, that this is the best to solve the problem >>>> that #364 prohibits BIND(C) for some routines and implementors >>>> want to do the same method for all routines. >>>> >>>> Don't forget that BIND(C) and TR29113 is still important >>>> for implementing these thin wrappers internally. >>>> >>>> Without using BIND(C) on the official mpi_f08 and mpi module >>>> interface, some features of TR29113 are not used: >>>> - the extension for interoperabple CHARACTER(LEN=*), >>>> - the extension for OPTIONAL dummy arguments. >>>> >>>> Other TR29113 features are heavily used: >>>> - The DIMENSION(..), TYPE(*) is needed for some internal >>>> C-written MPI_Isend_desc. >>>> - The ASYNCHRONOUS usage for communication buffers. >>>> >>>> Should we go in this direction? >>>> >>>> Best regards >>>> Rolf >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "Bill Long" <longb(a)cray.com> >>>>> To: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> >>>>> Cc: "Martin Schulz" <schulzm(a)llnl.gov>, "MPI-3 Fortran working >>>>> group" <mpi3-fortran(a)lists.mpi-forum.org> >>>>> Sent: Wednesday, March 20, 2013 4:01:52 PM >>>>> Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 >>>>> interface - issue with the LOGICAL kind >>>>> On 3/20/13 8:26 AM, Jeff Squyres (jsquyres) wrote: >>>>>> On Mar 20, 2013, at 6:25 AM, Bill Long <longb(a)cray.com> wrote: >>>>>> >>>>>>> interface !--> MPI_Test >>>>>>> >>>>>>> ! int MPI_Test(MPI_Request *request, int *flag, MPI_Status >>>>>>> *status); >>>>>>> >>>>>>> Function MPI_Test_C( request, flag, status) & >>>>>>> BIND(C, name="MPI_Test") RESULT (res) >>>>>>> import :: C_request, c_int, MPI_Status_C >>>>>>> integer(C_request) :: request >>>>>> >>>>>> This is not correct. You cannot assume that MPI handles are >>>>>> integers >>>>>> (they're pointers in Open MPI). >>>>> >>>>> >>>>> This is correct for mpich. OpenMPI would evidently have a >>>>> different >>>>> version. But the concept is still the same - make a correct >>>>> interface >>>>> to the C library routine, however it is defined by the >>>>> implementation, >>>>> and then call that from a thin Fortran wrapper that takes care of >>>>> the >>>>> issues related to LOGICAL, the use of default INTEGER, and >>>>> OPTIONAL >>>>> arguments. >>>>> >>>>> Cheers, >>>>> Bill >>>>> >>>>> >>>>>> >>>>> >>>>> -- >>>>> Bill Long longb(a)cray.com >>>>> Fortran Technical Support & voice: 651-605-9024 >>>>> Bioinformatics Software Development fax: 651-605-9142 >>>>> Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101 >>>>> >>>>> >>>>> _______________________________________________ >>>>> mpi3-fortran mailing list >>>>> mpi3-fortran(a)lists.mpi-forum.org >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran >>>> >>>> -- >>>> Dr. Rolf Rabenseifner . . . . . . . . . .. email >>>> rabenseifner(a)hlrs.de >>>> High Performance Computing Center (HLRS) . phone >>>> ++49(0)711/685-65530 >>>> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / >>>> 685-65832 >>>> Head of Dpmt Parallel Computing . . . >>>> www.hlrs.de/people/rabenseifner >>>> Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room >>>> 1.307) >>>> _______________________________________________ >>>> mpi3-fortran mailing list >>>> mpi3-fortran(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran >>>> >>>> >>>> Click >>>> https://www.mailcontrol.com/sr/oUBxarVXlArGX2PQPOmvUrwgXREt4LZXdolWasoQmWDb… >>>> to report this email as spam. >>>> >>>> _______________________________________________ >>>> mpi3-fortran mailing list >>>> mpi3-fortran(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran >>> >>> >> >> -- >> Bill Long longb(a)cray.com >> Fortran Technical Support & voice: 651-605-9024 >> Bioinformatics Software Development fax: 651-605-9142 >> Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101 >> >> >> _______________________________________________ >> mpi3-fortran mailing list >> mpi3-fortran(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran > -- Bill Long longb(a)cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101

1 0