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 Bill Long 25 Mar '13

25 Mar '13

On 3/25/13 12:11 PM, Rolf Rabenseifner wrote: > We (Jeff, Bill L., Craig, Hubert, Martin, Tobias, and me (Rolf)) had > a telecon today and the outcome are following options: > > Option 1 > - #364 as it currently is, as a minimal solution for > the LOGICAL problem: > Pro: It is consistent between Fortran and MPI. > I.e., it is the minimal solution that we must do. > Con: It has a mix of BIND(C) and non-BIND(C) routine groups > which is ugly for the future. > Remark: non-BIND(C) will stay there because the callbacks > need non-BIND(C) in the moment and this cannot be > changed in the future by nice new concepts from > the Fortran language standardization. > > Option 2 > - #364 plus changing MPI-3.0 page 605 lines 24-30 and > page 605 line 47 - page 606 line 6 by also using non-BIND(C), > but other linker names: > MPI_Send_f08d (in mpi_f08 with TS29113 quality, i.e., > buffers are done with C-descriptors and > not with void* pointers.) > MPI_Send_fd (in the mpi module or mpif.h if > MPI_SUBARRAYS_SUPPORTED=.TRUE. is also done > there, i.e., with the descriptors.) > > Pro: It is consistent between Fortran and MPI > and it is consistent within MPI, i.e., all > functionality is done with non-BIND(C) routines. > BIND(C) can be still used internally to > call MPI_Send_cdesc and MPI_Isend_cdesc. > To be fair, implementatiosn will be based mainly > on this TS 29113 feature, but only internally. > Con: No BIND(C) on the official MPI interface. > We urged Fortran to put some features into TS 29113, > but we will not use these features, because they > are not needed on this internal interface. > > Option 3: > - Option 2 plus the following rule: > - The Fortran PMPI interface can be substituted by a > wrapper based sulution that internally calls the full > MPI C interface. > - In this case, the Fortran interface should be hidden > to the tools. > - For the buffer routines with the new cdesc descriptor, > new interfaces are added for the tools people, > e.g., MPI_Send_cdesc and MPI_Isend_cdesc. > > Pro: I'm not sure whether there is a real pro? > > Bill, can you add the pros, it is your option. I believe that Craig and I made comments on this in separate emails, but I can reproduce here: It is the only option that allows the possibility of underscore name mangling disappearing in the future. I think most (if not all) MPI Fortran implementations will eventually evolve to thin wrappers calling the C API. There are several advantages with this implementation: 1. The thin wrappers can be put in a module. 2. Compilers may be able to inline the wrappers for very efficient implementations. 3. Fortran implementations are much simpler because they won't have to directly support PMPI in Fortran. 4. Since the Fortran implementation is substantially less complex, the costs associated with testing, supporting, and maintaining a Fortran implementation will also be reduced. 5. If all MPI implementations eventually choose to call the C API, then the tools community eventually will not have to support underscore name mangling, thus reducing their costs as well. and 6. You can isolate the issues of Fortran types (compiled with -i8, meaning of LOGICAL, character arguments with len > 1) into the Fortran wrappers so that the C library writers do not have to know about these issues. Simplifies the maintenance and testing issues for the C library code. I would modify option 3 slightly. The implementer might want to write some routine ONLY in Fortran. The routines that convert the status formats between the Fortran and the C forms comes to mind. In that case, BIND(C) would be required, and it would specify the C binding name as the external linker name. This would be needed so that C codes could call the routine. and, due to the fact that the mpif.h method has to be supported as well, For that mode, the corresponding text from the mpi module (with INTEGER handles and ( void *) buffers) is extracted to a file without the module wrapping. Compiling that file will result in a routine with an external symbol of mpi_xxx_ (or something similar, depending on the conventions of the compiler). That version would be called only in the case that the user included mpif.h. A particularly aggressive compiler that defers inlining until the link step might even inline this case. If the mpif.h mode is deleted in the future, this file would just no longer be generated. Cheers, Bill > > Con: An additional new interface for the tools folk. > It is not backward compatible for users who really > intercept the Fortran MPI interface. > > My favorite in the moment, i.e. at the starting of > the pro-con-discussion: Option 2. > > Best regards > Rolf > > > > ----- Original Message ----- >> From: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> >> To: longb(a)cray.com >> Cc: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com>, "Craig E Rasmussen" <rasmus(a)cas.uoregon.edu>, "Hubert Ritzdorf" >> <Hubert.Ritzdorf(a)emea.nec.com>, "Martin Schulz" <schulzm(a)llnl.gov>, "Tobias Burnus" <burnus(a)net-b.de> >> Sent: Monday, March 25, 2013 12:21:39 PM >> Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind >> Yes, this freedom (1)-(4) in Bill's email is important. >> >> In our discussion, we forgot one additional reason why we defined >> it as it is written in MPI-3.0 Section 17.1.5, page 605: >> >> - It should be possible to implement the interfaces with >> these non-standard Fortran-void-* directives, >> and later on, >> to substitute this implementation by new ones >> that are based on TS 29113. >> - When doing this substitution, it should be save for >> applications when the application is not re-compiled. >> - More than that, it should be possible to combine older >> .o files with newly TS 29113 based .o files. >> - For this, we decided, that the implementation has to switch >> from non-BIND(C) to BIND(C) at least in the MPI_ISEND >> routine group when switching to MPI_SUBARRAYS_SUPPORTED==.TRUE. >> - The real trick is that the linker name must be changed. >> - This all is valid for both, the new mpi_f08 module, >> and the old mpi module. >> >> A second issue in our discussion is always, which changes >> we want to do to the mpi_f08 MPI-3.0 user interface. >> I want to remember that this user interface is defined >> according following rules. >> If a user modifies his source to use everywhere mpi_f08, >> he/she has to modify: >> - He/she has to substitute the "include 'mpif.h'" or "use mpi" >> statements by "use mpi_f08". >> - He/she has to modify all handle and status declarations. >> - In the executable statements, he/she has to substitute all >> status(MPI_TAG), status(MPI_SOURCE), status(MPI_ERROR) >> accesses into >> status%MPI_TAG, status%MPI_SOURCE, status%MPI_ERROR. >> - Callback routines need more effort due to the >> abstract interface definitions. >> This is touched by ticket #364, i.e., >> the MPI-3.0 BIND(C) of callbacks had to be removed. >> - Changes in the interfaces are only >> -- all handles use the new handle types >> and in >> -- MPI_User_function, >> -- MPI_Datarep_conversion_function, >> the buffers are done with TYPE(C_TR), VALUE. >> >> This should be all. >> All other user correct code should directly compile with the new >> mpi_f08 module. >> We should not change these things, except the necessary >> errata in #364. >> >> I see that we have some freedom only in the area, >> what we do internally (together with linker names) and with PMPI, >> but not in the user interface. >> If we add additional user interfaces (e.g. overloading the LOGICAL >> with INTEGER arguments) >> we would only make it more complicate. >> >> Best regards >> Rolf >> >> >> ----- Original Message ----- >>> From: "Bill Long" <longb(a)cray.com> >>> To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> >>> Cc: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com>, "Craig E >>> Rasmussen" <rasmus(a)cas.uoregon.edu>, "Hubert Ritzdorf" >>> <Hubert.Ritzdorf(a)emea.nec.com>, "Martin Schulz" <schulzm(a)llnl.gov>, >>> "Tobias Burnus" <burnus(a)net-b.de> >>> Sent: Sunday, March 24, 2013 5:59:38 PM >>> Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 >>> interface - issue with the LOGICAL kind >>> This time is OK for me. I'll look for the webex email. >>> >>> I would like to note that the various options discussed are not >>> necessarily "all or nothing" propositions. An implementation could >>> use >>> the thin wrappers in a module approach to eliminate the bad Fortran >>> types problems for most of the MPI routines, but also have some >>> routines >>> implemented in a different way, such as (1) all in Fortran that is >>> callable from C, (2) all in C that is called through an interface >>> directly from Fortran, (3) as a fat wrapper in Fortran, or (4) a >>> completely replicated routine for the Fortran implementation. There >>> is >>> no reason that all of the routines have to be the same method - in >>> fact >>> probably good arguments against that in some cases. We just need to >>> have >>> the rules such that the tools have some known name to intercept. >>> Along >>> the lines of "If implementation method X is chosen for routine >>> MPI_xxx, >>> then these are the linker name requirements:.....". >>> >>> Cheers, >>> Bill >>> >>> >>> >>> On 3/23/13 2:11 AM, Rolf Rabenseifner wrote: >>>> Dear Jeff, Craig, Bill, Hubert, Martin, and Tobias, >>>> >>>> I expect that this is the total group that discusses the >>>> Fortran LOGICAL etc. problem. >>>> We learnt that the solutions also touch the PMPI concept. >>>> There was a telecon between Craig, Jeff and Bill with the proposal >>>> at the end of this email. >>>> I like to understand this proposal and therefore I asked Jeff >>>> for explanations. I would like to open this for the whole group. >>>> >>>>> I have meetings at 9am and 1pm is eastern on Monday. I can talk >>>>> any >>>>> other time. >>>>> Craig prob can't attend because he's 3 hours earlier, but that's >>>>> prob ok. >>>> >>>> Monday March 25, >>>> - 4 PM Central European Time CET >>>> = 11 AM Eastern Daylight Time EST/EDT >>>> = 8 AM Pacific Time >>>> >>>> I hope these relations are correct. Would this work for you? >>>> >>>> At least for Jeff and me, because I want to understand >>>> what they discussed with their proposal. >>>> >>>> Jeff, can you set up a webex? >>>> >>>> Best regards >>>> Rolf >>>> >>>> ----- Original Message ----- >>>>> From: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> >>>>> To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> >>>>> Cc: "Craig E Rasmussen" <rasmus(a)cas.uoregon.edu> >>>>> Sent: Friday, March 22, 2013 8:01:23 PM >>>>> Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 >>>>> interface - issue with the LOGICAL kind >>>>> Btw, I'm not sure how this is not the least surprise. >>>>> >>>>> We can't change the params to not be logical, yes we must still >>>>> allow >>>>> for calling to c. So the overloaded solution is the only one. >>>>> >>>>> And the new Integer param signature must have a new bind name so >>>>> as >>>>> to >>>>> did ambiguity it from the one we published in MPI3. See my >>>>> previous >>>>> mail about this. >>>>> >>>>> I have meetings at 9am and 1pm is eastern on Monday. I can talk >>>>> any >>>>> other time. >>>>> >>>>> Craig prob can't attend because he's 3 hours earlier, but that's >>>>> prob >>>>> ok. >>>>> >>>>> Sent from my phone. No type good. >>>>> >>>>> On Mar 22, 2013, at 8:51 AM, "Rolf Rabenseifner" >>>>> <rabenseifner(a)hlrs.de> wrote: >>>>> >>>>>> Jeff, >>>>>> >>>>>> can I call you by phone? >>>>>> I would like to talk to you as the binding responsible and MPI >>>>>> chair. >>>>>> >>>>>>> 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 >>>>>> ... >>>>>> This is a hard step and far away from "last surprise". >>>>>> >>>>>> I would like to learn how it came out as a result of your >>>>>> telecon, >>>>>> before I try to go the next step (e.g. email answer). >>>>>> >>>>>> Best regards >>>>>> Rolf >>>>>> >>>>>> ----- Original Message ----- >>>>>>> From: "Craig Rasmussen" <rasmus(a)cas.uoregon.edu> >>>>>>> To: "MPI-3 Fortran working group" >>>>>>> <mpi3-fortran(a)lists.mpi-forum.org> >>>>>>> Cc: "Hubert Ritzdorf" <Hubert.Ritzdorf(a)emea.nec.com>, "Martin >>>>>>> Schulz" <schulzm(a)llnl.gov> >>>>>>> Sent: Friday, March 22, 2013 4:29:36 PM >>>>>>> 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 >>>> >>> >>> -- >>> 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 >> >> -- >> 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) > -- 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] Another (smaller) issue with MPI 3.0 and BIND(C)
by Bill Long 25 Mar '13

25 Mar '13

On 3/25/13 1:55 PM, Craig Rasmussen wrote: > I agree with Tobias. This also must be changed. Assuming we have BIND(C) on the Fortran interface, I agree as well. Without BIND(C), there is no problem. (Though the interface to the C function would need the fix noted by Tobias, but that appears to be outside the scope of the spec). Cheers, Bill > > I've tried a couple of compilers and they now get sequence association > correct so that changing the interfaces to arrays of CHARACTER(LEN=1) > dummy arguments should now work. A couple of years ago a few compilers > I tried failed to do this correctly. > > Craig Rasmussen > CAS Scientific Programmer > rasmus(a)cas.uoregon.edu <mailto:[email protected]> > > > > > On Mar 18, 2013, at 1:44 AM, Tobias Burnus wrote: > >> Dear all, >> >> there is possible one other problem with some BIND(C) interfaces in >> MPI 3.0: >> >> MPI_Comm_get_name(comm, comm_name, resultlen, ierror) BIND(C) >> TYPE(MPI_Comm), INTENT(IN) :: comm >> CHARACTER(LEN=MPI_MAX_OBJECT_NAME), INTENT(OUT) :: comm_nameI >> >> Namely, it uses a CHARACTER dummy argument which does not have LEN=1 >> in a procedure with C binding. >> >> >> From Fortran 2008's "15.3.2 Interoperability of intrinsic types" >> (p.429, paragraph 1): >> >> "If the type is character, the length type parameter is interoperable >> if and only if its value is one." >> >> >> Initially, I though that the following would allow it: >> >> "A named scalar Fortran variable is interoperable if and only if its >> type and type parameters are interoperable, [...] and if it is of type >> character >> its length is not assumed or declared by an expression that is not a >> constant expression." >> ("15.3.5 Interoperability of scalar variables", p. 432, paragraph 1.) >> >> I thought that the latter part allows it. However, as Bill pointed >> out: The "if and only if ... type parameters are interoperable" makes >> clear that it is only interoperable if the length is 1. (The second >> condition makes only sure that this it is compile-time checking by not >> allowing len=* or nonconst expressions). >> >> TS 29113 allows in addtion len=* and len=: for dummy arguments of >> BIND(C) procedures. However, that doesn't help for >> LEN=MPI_MAX_OBJECT_NAME, either. (For len=*/len=:, TS 29113 requires >> that an array descriptor is used; cf. "8.7 Interoperability of >> procedures and procedure interfaces", p.31, (6)(b) and the paragraph >> below (6)(d).). >> >> >> I think the simplest is to change: >> >> CHARACTER(LEN=MPI_MAX_OBJECT_NAME), INTENT(OUT) :: comm_nameI >> to >> CHARACTER, INTENT(OUT) :: comm_nameI(MPI_MAX_OBJECT_NAME) >> >> Namely, to change the character length to 1 and the array size to >> MPI_MAX_OBJECT_NAME. Using the storage association for characters, a >> character(len=MPI_MAX_OBJECT_NAME) variable can be passed to a >> character(len=1) character array of size MPI_MAX_OBJECT_NAME. >> >> To quote the standard: >> >> "The type parameter values of the actual argument shall agree with the >> corresponding ones of the dummy argument that are not assumed, except >> for the case of the character length parameter of a default character >> or character with the C character kind (15.2.2) actual argument >> associated with a dummy argument that is not assumed shape. >> If a scalar dummy argument is default character or of type character >> with the C character kind, the length len of the dummy argument shall >> be less than or equal to the length of the actual argument. The dummy >> argument becomes associated with the leftmost len characters of the >> actual argument. If an array dummy argument is default character or of >> type character with the C character kind and is not assumed shape, it >> becomes associated with the leftmost characters of the actual argument >> element sequence (12.5.2.11)." >> >> (F2008, "12.5.2.4 Ordinary dummy variables", p. 293, paragraphs 3 and 4.) >> >> Tobias >> _______________________________________________ >> mpi3-fortran mailing list >> mpi3-fortran(a)lists.mpi-forum.org <mailto:[email protected]> >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran > > > > _______________________________________________ > 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 Bill Long 25 Mar '13

25 Mar '13

On 3/25/13 3:28 PM, Hubert Ritzdorf wrote: > I vote for Option 2. > > Option 3 is not possible for an errata. This is a severe change in the standard. > Your modification of Option 3 makes the standard more difficult (we have again mixing of > BIND(C) and non BIND(C) functions) and I can't see a real application advantage. > > To your items: > Item 2: You have to perform also additional work in the wrappers > (for example memory allocation and transformation for sources > compiled with -i8; additional error checks) There is a trivial amount of work in the wrapper - this is intentional. Here is a simple example from the mpi_f08 module: subroutine MPI_Abort(comm, errorcode, ierror) use,intrinsic :: iso_c_binding, only: c_int use :: mpi_f08_types, only: MPI_Comm use :: mpi_C_interfaces_nobuf, only: C_Comm, MPI_Abort_C TYPE(MPI_Comm), INTENT(IN) :: comm INTEGER, INTENT(IN) :: errorcode INTEGER, OPTIONAL, INTENT(OUT) :: ierror integer(C_Comm) :: comm_c integer(c_int) :: errorcode_c integer(c_int) :: res comm_c = comm%MPI_VAL errorcode_c = errorcode res = MPI_Abort_C (comm_c, errorcode_c) if (present(ierror)) ierror = res end subroutine MPI_Abort The local xxx_c variables are the ones for the C routine; the ones without the _c are the Fortran dummy arguments. I have not encountered a case where memory allocation is needed, at least yet. To accommodate -i8, you only recompile the modules with -i8. There is no change to the module source. This is the intent of the design. The three assignment statements are, in effect, 'casts' between the Fortran and C types. If there is no difference, the compiler could simplify the executable code. In this particular case, the code following the MPI_Abort call to C might not be necessary, since I would expect the routine to not return. But the same pattern is used elsewhere to deal with the error return value. > Item 3: Support of PMPI version of Fortran is not really an issue. > Item 4b: The tools have to support routines compiled with mpi.h and old > objects. That is true. For that mode, the text corresponding text from the mpi module (with INTEGER handle for comm and the use of mpi_f08_types removed) is extracted to a file without the module wrapping. Compiling that file will result in a routine with an external symbol of mpi_abort_ (or something similar, depending on the conventions of the compiler). That version would be called only in the case that the user included mpif.h. A particularly aggressive compiler that defers inlining until the link step might even inline this case. Cheers, Bill > > Hubert > > ________________________________________ > From: Bill Long [longb(a)cray.com] > Sent: Monday, March 25, 2013 7:35 PM > To: Craig Rasmussen > Cc: Rolf Rabenseifner; MPI-3 Fortran working group; Jeff Squyres (jsquyres); Hubert Ritzdorf; Martin Schulz; Tobias Burnus > Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind > > On 3/25/13 12:50 PM, Craig Rasmussen wrote: >> My summary of the three options: >> >> 1. Absolute minimal change, remove BIND(C) only for routines with >> LOGICAL arguments. Tools will need to support underscore name mangling >> forever (even when TS29113 is implemented by compilers) but only on >> routines with LOGICAL arguments. >> >> 2. Remove BIND(C) from all routines. Tools will need to support >> underscore name mangling for all routines. >> >> 3. Remove BIND(C) from all routines. Plus allow Fortran implementations >> to substitute the C PMPI interface standard. >> >> Is this a fair summary? >> >> My vote: >> >> I'm strongly in favor of option 3. It is the only option that allows >> the possibility of underscore name mangling disappearing in the future. >> I think most (if not all) MPI Fortran implementations will eventually >> evolve to thin wrappers calling the C API. There are several advantages >> with this implementation: >> 1. The thin wrappers can be put in a module. >> 2. Compilers may be able to inline the wrappers for very efficient >> implementations. >> 3. Fortran implementations are much simpler because they won't have >> to directly support PMPI in Fortran. >> 4. Since the Fortran implementation is substantially less complex, >> the costs associated with testing, supporting, and maintaining a Fortran >> implementation will also be reduced. >> 4. If all MPI implementations eventually choose to call the C API, >> then the tools community eventually will not have to support underscore >> name mangling, thus reducing their costs as well. > > I like option 3 as well. It uses the C interoperability feature in > Fortran the way it was intended/designed. I would add to the above: > > 6. You can isolate the issues of Fortran types (compiled with -i8, > meaning of LOGICAL, character arguments with len > 1) into the Fortran > wrappers so that the C library writers do not have to know about these > issues. Simplifies the maintenance and testing issues for the C > library code. > > > I would modify option 3 slightly. The implementer might want to write > some routine ONLY in Fortran. The routines that convert the status > formats between the Fortran and the C forms comes to mind. In that > case, BIND(C) would be required, and it would specify the C binding name > as the external linker name. This would be needed so that C codes could > call the routine. > > > Cheers, > Bill > > >> >> Craig Rasmussen >> CAS Scientific Programmer >> rasmus(a)cas.uoregon.edu <mailto:[email protected]> >> >> >> >> >> On Mar 25, 2013, at 10:11 AM, Rolf Rabenseifner wrote: >> >>> We (Jeff, Bill L., Craig, Hubert, Martin, Tobias, and me (Rolf)) had >>> a telecon today and the outcome are following options: >>> >>> Option 1 >>> - #364 as it currently is, as a minimal solution for >>> the LOGICAL problem: >>> Pro: It is consistent between Fortran and MPI. >>> I.e., it is the minimal solution that we must do. >>> Con: It has a mix of BIND(C) and non-BIND(C) routine groups >>> which is ugly for the future. >>> Remark: non-BIND(C) will stay there because the callbacks >>> need non-BIND(C) in the moment and this cannot be >>> changed in the future by nice new concepts from >>> the Fortran language standardization. >>> >>> Option 2 >>> - #364 plus changing MPI-3.0 page 605 lines 24-30 and >>> page 605 line 47 - page 606 line 6 by also using non-BIND(C), >>> but other linker names: >>> MPI_Send_f08d (in mpi_f08 with TS29113 quality, i.e., >>> buffers are done with C-descriptors and >>> not with void* pointers.) >>> MPI_Send_fd (in the mpi module or mpif.h if >>> MPI_SUBARRAYS_SUPPORTED=.TRUE. is also done >>> there, i.e., with the descriptors.) >>> >>> Pro: It is consistent between Fortran and MPI >>> and it is consistent within MPI, i.e., all >>> functionality is done with non-BIND(C) routines. >>> BIND(C) can be still used internally to >>> call MPI_Send_cdesc and MPI_Isend_cdesc. >>> To be fair, implementatiosn will be based mainly >>> on this TS 29113 feature, but only internally. >>> Con: No BIND(C) on the official MPI interface. >>> We urged Fortran to put some features into TS 29113, >>> but we will not use these features, because they >>> are not needed on this internal interface. >>> >>> Option 3: >>> - Option 2 plus the following rule: >>> - The Fortran PMPI interface can be substituted by a >>> wrapper based sulution that internally calls the full >>> MPI C interface. >>> - In this case, the Fortran interface should be hidden >>> to the tools. >>> - For the buffer routines with the new cdesc descriptor, >>> new interfaces are added for the tools people, >>> e.g., MPI_Send_cdesc and MPI_Isend_cdesc. >>> >>> Pro: I'm not sure whether there is a real pro? >>> >>> Bill, can you add the pros, it is your option. >>> >>> Con: An additional new interface for the tools folk. >>> It is not backward compatible for users who really >>> intercept the Fortran MPI interface. >>> >>> My favorite in the moment, i.e. at the starting of >>> the pro-con-discussion: Option 2. >>> >>> Best regards >>> Rolf >>> >>> >>> >>> ----- Original Message ----- >>>> From: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de >>>> <mailto:[email protected]>> >>>> To: longb(a)cray.com <mailto:[email protected]> >>>> Cc: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com >>>> <mailto:[email protected]>>, "Craig E Rasmussen" >>>> <rasmus(a)cas.uoregon.edu <mailto:[email protected]>>, "Hubert >>>> Ritzdorf" >>>> <Hubert.Ritzdorf(a)emea.nec.com <mailto:[email protected]>>, >>>> "Martin Schulz" <schulzm(a)llnl.gov <mailto:[email protected]>>, "Tobias >>>> Burnus" <burnus(a)net-b.de <mailto:[email protected]>> >>>> Sent: Monday, March 25, 2013 12:21:39 PM >>>> Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 >>>> interface - issue with the LOGICAL kind >>>> Yes, this freedom (1)-(4) in Bill's email is important. >>>> >>>> In our discussion, we forgot one additional reason why we defined >>>> it as it is written in MPI-3.0 Section 17.1.5, page 605: >>>> >>>> - It should be possible to implement the interfaces with >>>> these non-standard Fortran-void-* directives, >>>> and later on, >>>> to substitute this implementation by new ones >>>> that are based on TS 29113. >>>> - When doing this substitution, it should be save for >>>> applications when the application is not re-compiled. >>>> - More than that, it should be possible to combine older >>>> .o files with newly TS 29113 based .o files. >>>> - For this, we decided, that the implementation has to switch >>>> from non-BIND(C) to BIND(C) at least in the MPI_ISEND >>>> routine group when switching to MPI_SUBARRAYS_SUPPORTED==.TRUE. >>>> - The real trick is that the linker name must be changed. >>>> - This all is valid for both, the new mpi_f08 module, >>>> and the old mpi module. >>>> >>>> A second issue in our discussion is always, which changes >>>> we want to do to the mpi_f08 MPI-3.0 user interface. >>>> I want to remember that this user interface is defined >>>> according following rules. >>>> If a user modifies his source to use everywhere mpi_f08, >>>> he/she has to modify: >>>> - He/she has to substitute the "include 'mpif.h'" or "use mpi" >>>> statements by "use mpi_f08". >>>> - He/she has to modify all handle and status declarations. >>>> - In the executable statements, he/she has to substitute all >>>> status(MPI_TAG), status(MPI_SOURCE), status(MPI_ERROR) >>>> accesses into >>>> status%MPI_TAG, status%MPI_SOURCE, status%MPI_ERROR. >>>> - Callback routines need more effort due to the >>>> abstract interface definitions. >>>> This is touched by ticket #364, i.e., >>>> the MPI-3.0 BIND(C) of callbacks had to be removed. >>>> - Changes in the interfaces are only >>>> -- all handles use the new handle types >>>> and in >>>> -- MPI_User_function, >>>> -- MPI_Datarep_conversion_function, >>>> the buffers are done with TYPE(C_TR), VALUE. >>>> >>>> This should be all. >>>> All other user correct code should directly compile with the new >>>> mpi_f08 module. >>>> We should not change these things, except the necessary >>>> errata in #364. >>>> >>>> I see that we have some freedom only in the area, >>>> what we do internally (together with linker names) and with PMPI, >>>> but not in the user interface. >>>> If we add additional user interfaces (e.g. overloading the LOGICAL >>>> with INTEGER arguments) >>>> we would only make it more complicate. >>>> >>>> Best regards >>>> Rolf >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "Bill Long" <longb(a)cray.com <mailto:[email protected]>> >>>>> To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de >>>>> <mailto:[email protected]>> >>>>> Cc: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com >>>>> <mailto:[email protected]>>, "Craig E >>>>> Rasmussen" <rasmus(a)cas.uoregon.edu <mailto:[email protected]>>, >>>>> "Hubert Ritzdorf" >>>>> <Hubert.Ritzdorf(a)emea.nec.com >>>>> <mailto:[email protected]>>, "Martin Schulz" >>>>> <schulzm(a)llnl.gov <mailto:[email protected]>>, >>>>> "Tobias Burnus" <burnus(a)net-b.de <mailto:[email protected]>> >>>>> Sent: Sunday, March 24, 2013 5:59:38 PM >>>>> Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 >>>>> interface - issue with the LOGICAL kind >>>>> This time is OK for me. I'll look for the webex email. >>>>> >>>>> I would like to note that the various options discussed are not >>>>> necessarily "all or nothing" propositions. An implementation could >>>>> use >>>>> the thin wrappers in a module approach to eliminate the bad Fortran >>>>> types problems for most of the MPI routines, but also have some >>>>> routines >>>>> implemented in a different way, such as (1) all in Fortran that is >>>>> callable from C, (2) all in C that is called through an interface >>>>> directly from Fortran, (3) as a fat wrapper in Fortran, or (4) a >>>>> completely replicated routine for the Fortran implementation. There >>>>> is >>>>> no reason that all of the routines have to be the same method - in >>>>> fact >>>>> probably good arguments against that in some cases. We just need to >>>>> have >>>>> the rules such that the tools have some known name to intercept. >>>>> Along >>>>> the lines of "If implementation method X is chosen for routine >>>>> MPI_xxx, >>>>> then these are the linker name requirements:.....". >>>>> >>>>> Cheers, >>>>> Bill >>>>> >>>>> >>>>> >>>>> On 3/23/13 2:11 AM, Rolf Rabenseifner wrote: >>>>>> Dear Jeff, Craig, Bill, Hubert, Martin, and Tobias, >>>>>> >>>>>> I expect that this is the total group that discusses the >>>>>> Fortran LOGICAL etc. problem. >>>>>> We learnt that the solutions also touch the PMPI concept. >>>>>> There was a telecon between Craig, Jeff and Bill with the proposal >>>>>> at the end of this email. >>>>>> I like to understand this proposal and therefore I asked Jeff >>>>>> for explanations. I would like to open this for the whole group. >>>>>> >>>>>>> I have meetings at 9am and 1pm is eastern on Monday. I can talk >>>>>>> any >>>>>>> other time. >>>>>>> Craig prob can't attend because he's 3 hours earlier, but that's >>>>>>> prob ok. >>>>>> >>>>>> Monday March 25, >>>>>> - 4 PM Central European Time CET >>>>>> = 11 AM Eastern Daylight Time EST/EDT >>>>>> = 8 AM Pacific Time >>>>>> >>>>>> I hope these relations are correct. Would this work for you? >>>>>> >>>>>> At least for Jeff and me, because I want to understand >>>>>> what they discussed with their proposal. >>>>>> >>>>>> Jeff, can you set up a webex? >>>>>> >>>>>> Best regards >>>>>> Rolf >>>>>> >>>>>> ----- Original Message ----- >>>>>>> From: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com >>>>>>> <mailto:[email protected]>> >>>>>>> To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de >>>>>>> <mailto:[email protected]>> >>>>>>> Cc: "Craig E Rasmussen" <rasmus(a)cas.uoregon.edu >>>>>>> <mailto:[email protected]>> >>>>>>> Sent: Friday, March 22, 2013 8:01:23 PM >>>>>>> Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 >>>>>>> interface - issue with the LOGICAL kind >>>>>>> Btw, I'm not sure how this is not the least surprise. >>>>>>> >>>>>>> We can't change the params to not be logical, yes we must still >>>>>>> allow >>>>>>> for calling to c. So the overloaded solution is the only one. >>>>>>> >>>>>>> And the new Integer param signature must have a new bind name so >>>>>>> as >>>>>>> to >>>>>>> did ambiguity it from the one we published in MPI3. See my >>>>>>> previous >>>>>>> mail about this. >>>>>>> >>>>>>> I have meetings at 9am and 1pm is eastern on Monday. I can talk >>>>>>> any >>>>>>> other time. >>>>>>> >>>>>>> Craig prob can't attend because he's 3 hours earlier, but that's >>>>>>> prob >>>>>>> ok. >>>>>>> >>>>>>> Sent from my phone. No type good. >>>>>>> >>>>>>> On Mar 22, 2013, at 8:51 AM, "Rolf Rabenseifner" >>>>>>> <rabenseifner(a)hlrs.de <mailto:[email protected]>> wrote: >>>>>>> >>>>>>>> Jeff, >>>>>>>> >>>>>>>> can I call you by phone? >>>>>>>> I would like to talk to you as the binding responsible and MPI >>>>>>>> chair. >>>>>>>> >>>>>>>>> 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 >>>>>>>> ... >>>>>>>> This is a hard step and far away from "last surprise". >>>>>>>> >>>>>>>> I would like to learn how it came out as a result of your >>>>>>>> telecon, >>>>>>>> before I try to go the next step (e.g. email answer). >>>>>>>> >>>>>>>> Best regards >>>>>>>> Rolf >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>>> From: "Craig Rasmussen" <rasmus(a)cas.uoregon.edu >>>>>>>>> <mailto:[email protected]>> >>>>>>>>> To: "MPI-3 Fortran working group" >>>>>>>>> <mpi3-fortran(a)lists.mpi-forum.org >>>>>>>>> <mailto:[email protected]>> >>>>>>>>> Cc: "Hubert Ritzdorf" <Hubert.Ritzdorf(a)emea.nec.com >>>>>>>>> <mailto:[email protected]>>, "Martin >>>>>>>>> Schulz" <schulzm(a)llnl.gov <mailto:[email protected]>> >>>>>>>>> Sent: Friday, March 22, 2013 4:29:36 PM >>>>>>>>> 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]> >>>>>> >>>>> >>>>> -- >>>>> Bill Long longb(a)cray.com <mailto:[email protected]> >>>>> 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 >>>> >>>> -- >>>> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de >>>> <mailto:[email protected]> >>>> 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 >>>> <http://www.hlrs.de/people/rabenseifner> >>>> Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) >>> >>> -- >>> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de >>> <mailto:[email protected]> >>> 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 >>> <http://www.hlrs.de/people/rabenseifner> >>> Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) >> > > -- > 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 > > > > > Click https://www.mailcontrol.com/sr/PSMHhYrWn2nGX2PQPOmvUmmLQnadxIEhPqNHPbHRv8fT… to report this email as spam. > -- 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 Schulz, Martin 25 Mar '13

25 Mar '13

I am torn between Option 2 and 3 - option 1 seems less clean, but doesn't add much help for tools. Once we have to implement Fortran name mangling for some routines, we can also do it for all. The addition of the optional use of the C interface makes sense, though, since this would long term allow a transition to that, but also gives MPI implementation the option to directly support C only tools. After this discussion and all our back and forth on the Fortran bindings I actually doubt that there is currently a single tool out there that managed to implement the correct Fortran bindings in MPI 2.2, let alone 3.0. This is a very practical argument and I am not sure if it's enough to justify supporting this for standardization, though. I also agree with Hubert - option 3 goes beyond an errata. A fourth option could be to allow BIND-C in the linker names, but leave it up to the MPI implementation to use it or not. This would basically keep the standard as is, but would remove the table on page 609 (plus surrounding text). In this case, tools would still check which version is implemented, but there wouldn't be a mandate of what is used when. If we wanted to combine this with option 3, then there could also be a set of constants that would state that a particular function group is only intercepted in C and all Fortran routines go through them. Martin On Mar 25, 2013, at 1:28 PM, Hubert Ritzdorf <Hubert.Ritzdorf(a)EMEA.NEC.COM> wrote: > I vote for Option 2. > > Option 3 is not possible for an errata. This is a severe change in the standard. > Your modification of Option 3 makes the standard more difficult (we have again mixing of > BIND(C) and non BIND(C) functions) and I can't see a real application advantage. > > To your items: > Item 2: You have to perform also additional work in the wrappers > (for example memory allocation and transformation for sources > compiled with -i8; additional error checks) > Item 3: Support of PMPI version of Fortran is not really an issue. > Item 4b: The tools have to support routines compiled with mpi.h and old > objects. > > Hubert > > ________________________________________ > From: Bill Long [longb(a)cray.com] > Sent: Monday, March 25, 2013 7:35 PM > To: Craig Rasmussen > Cc: Rolf Rabenseifner; MPI-3 Fortran working group; Jeff Squyres (jsquyres); Hubert Ritzdorf; Martin Schulz; Tobias Burnus > Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind > > On 3/25/13 12:50 PM, Craig Rasmussen wrote: >> My summary of the three options: >> >> 1. Absolute minimal change, remove BIND(C) only for routines with >> LOGICAL arguments. Tools will need to support underscore name mangling >> forever (even when TS29113 is implemented by compilers) but only on >> routines with LOGICAL arguments. >> >> 2. Remove BIND(C) from all routines. Tools will need to support >> underscore name mangling for all routines. >> >> 3. Remove BIND(C) from all routines. Plus allow Fortran implementations >> to substitute the C PMPI interface standard. >> >> Is this a fair summary? >> >> My vote: >> >> I'm strongly in favor of option 3. It is the only option that allows >> the possibility of underscore name mangling disappearing in the future. >> I think most (if not all) MPI Fortran implementations will eventually >> evolve to thin wrappers calling the C API. There are several advantages >> with this implementation: >> 1. The thin wrappers can be put in a module. >> 2. Compilers may be able to inline the wrappers for very efficient >> implementations. >> 3. Fortran implementations are much simpler because they won't have >> to directly support PMPI in Fortran. >> 4. Since the Fortran implementation is substantially less complex, >> the costs associated with testing, supporting, and maintaining a Fortran >> implementation will also be reduced. >> 4. If all MPI implementations eventually choose to call the C API, >> then the tools community eventually will not have to support underscore >> name mangling, thus reducing their costs as well. > > I like option 3 as well. It uses the C interoperability feature in > Fortran the way it was intended/designed. I would add to the above: > > 6. You can isolate the issues of Fortran types (compiled with -i8, > meaning of LOGICAL, character arguments with len > 1) into the Fortran > wrappers so that the C library writers do not have to know about these > issues. Simplifies the maintenance and testing issues for the C > library code. > > > I would modify option 3 slightly. The implementer might want to write > some routine ONLY in Fortran. The routines that convert the status > formats between the Fortran and the C forms comes to mind. In that > case, BIND(C) would be required, and it would specify the C binding name > as the external linker name. This would be needed so that C codes could > call the routine. > > > Cheers, > Bill > > >> >> Craig Rasmussen >> CAS Scientific Programmer >> rasmus(a)cas.uoregon.edu <mailto:[email protected]> >> >> >> >> >> On Mar 25, 2013, at 10:11 AM, Rolf Rabenseifner wrote: >> >>> We (Jeff, Bill L., Craig, Hubert, Martin, Tobias, and me (Rolf)) had >>> a telecon today and the outcome are following options: >>> >>> Option 1 >>> - #364 as it currently is, as a minimal solution for >>> the LOGICAL problem: >>> Pro: It is consistent between Fortran and MPI. >>> I.e., it is the minimal solution that we must do. >>> Con: It has a mix of BIND(C) and non-BIND(C) routine groups >>> which is ugly for the future. >>> Remark: non-BIND(C) will stay there because the callbacks >>> need non-BIND(C) in the moment and this cannot be >>> changed in the future by nice new concepts from >>> the Fortran language standardization. >>> >>> Option 2 >>> - #364 plus changing MPI-3.0 page 605 lines 24-30 and >>> page 605 line 47 - page 606 line 6 by also using non-BIND(C), >>> but other linker names: >>> MPI_Send_f08d (in mpi_f08 with TS29113 quality, i.e., >>> buffers are done with C-descriptors and >>> not with void* pointers.) >>> MPI_Send_fd (in the mpi module or mpif.h if >>> MPI_SUBARRAYS_SUPPORTED=.TRUE. is also done >>> there, i.e., with the descriptors.) >>> >>> Pro: It is consistent between Fortran and MPI >>> and it is consistent within MPI, i.e., all >>> functionality is done with non-BIND(C) routines. >>> BIND(C) can be still used internally to >>> call MPI_Send_cdesc and MPI_Isend_cdesc. >>> To be fair, implementatiosn will be based mainly >>> on this TS 29113 feature, but only internally. >>> Con: No BIND(C) on the official MPI interface. >>> We urged Fortran to put some features into TS 29113, >>> but we will not use these features, because they >>> are not needed on this internal interface. >>> >>> Option 3: >>> - Option 2 plus the following rule: >>> - The Fortran PMPI interface can be substituted by a >>> wrapper based sulution that internally calls the full >>> MPI C interface. >>> - In this case, the Fortran interface should be hidden >>> to the tools. >>> - For the buffer routines with the new cdesc descriptor, >>> new interfaces are added for the tools people, >>> e.g., MPI_Send_cdesc and MPI_Isend_cdesc. >>> >>> Pro: I'm not sure whether there is a real pro? >>> >>> Bill, can you add the pros, it is your option. >>> >>> Con: An additional new interface for the tools folk. >>> It is not backward compatible for users who really >>> intercept the Fortran MPI interface. >>> >>> My favorite in the moment, i.e. at the starting of >>> the pro-con-discussion: Option 2. >>> >>> Best regards >>> Rolf >>> >>> >>> >>> ----- Original Message ----- >>>> From: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de >>>> <mailto:[email protected]>> >>>> To: longb(a)cray.com <mailto:[email protected]> >>>> Cc: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com >>>> <mailto:[email protected]>>, "Craig E Rasmussen" >>>> <rasmus(a)cas.uoregon.edu <mailto:[email protected]>>, "Hubert >>>> Ritzdorf" >>>> <Hubert.Ritzdorf(a)emea.nec.com <mailto:[email protected]>>, >>>> "Martin Schulz" <schulzm(a)llnl.gov <mailto:[email protected]>>, "Tobias >>>> Burnus" <burnus(a)net-b.de <mailto:[email protected]>> >>>> Sent: Monday, March 25, 2013 12:21:39 PM >>>> Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 >>>> interface - issue with the LOGICAL kind >>>> Yes, this freedom (1)-(4) in Bill's email is important. >>>> >>>> In our discussion, we forgot one additional reason why we defined >>>> it as it is written in MPI-3.0 Section 17.1.5, page 605: >>>> >>>> - It should be possible to implement the interfaces with >>>> these non-standard Fortran-void-* directives, >>>> and later on, >>>> to substitute this implementation by new ones >>>> that are based on TS 29113. >>>> - When doing this substitution, it should be save for >>>> applications when the application is not re-compiled. >>>> - More than that, it should be possible to combine older >>>> .o files with newly TS 29113 based .o files. >>>> - For this, we decided, that the implementation has to switch >>>> from non-BIND(C) to BIND(C) at least in the MPI_ISEND >>>> routine group when switching to MPI_SUBARRAYS_SUPPORTED==.TRUE. >>>> - The real trick is that the linker name must be changed. >>>> - This all is valid for both, the new mpi_f08 module, >>>> and the old mpi module. >>>> >>>> A second issue in our discussion is always, which changes >>>> we want to do to the mpi_f08 MPI-3.0 user interface. >>>> I want to remember that this user interface is defined >>>> according following rules. >>>> If a user modifies his source to use everywhere mpi_f08, >>>> he/she has to modify: >>>> - He/she has to substitute the "include 'mpif.h'" or "use mpi" >>>> statements by "use mpi_f08". >>>> - He/she has to modify all handle and status declarations. >>>> - In the executable statements, he/she has to substitute all >>>> status(MPI_TAG), status(MPI_SOURCE), status(MPI_ERROR) >>>> accesses into >>>> status%MPI_TAG, status%MPI_SOURCE, status%MPI_ERROR. >>>> - Callback routines need more effort due to the >>>> abstract interface definitions. >>>> This is touched by ticket #364, i.e., >>>> the MPI-3.0 BIND(C) of callbacks had to be removed. >>>> - Changes in the interfaces are only >>>> -- all handles use the new handle types >>>> and in >>>> -- MPI_User_function, >>>> -- MPI_Datarep_conversion_function, >>>> the buffers are done with TYPE(C_TR), VALUE. >>>> >>>> This should be all. >>>> All other user correct code should directly compile with the new >>>> mpi_f08 module. >>>> We should not change these things, except the necessary >>>> errata in #364. >>>> >>>> I see that we have some freedom only in the area, >>>> what we do internally (together with linker names) and with PMPI, >>>> but not in the user interface. >>>> If we add additional user interfaces (e.g. overloading the LOGICAL >>>> with INTEGER arguments) >>>> we would only make it more complicate. >>>> >>>> Best regards >>>> Rolf >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "Bill Long" <longb(a)cray.com <mailto:[email protected]>> >>>>> To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de >>>>> <mailto:[email protected]>> >>>>> Cc: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com >>>>> <mailto:[email protected]>>, "Craig E >>>>> Rasmussen" <rasmus(a)cas.uoregon.edu <mailto:[email protected]>>, >>>>> "Hubert Ritzdorf" >>>>> <Hubert.Ritzdorf(a)emea.nec.com >>>>> <mailto:[email protected]>>, "Martin Schulz" >>>>> <schulzm(a)llnl.gov <mailto:[email protected]>>, >>>>> "Tobias Burnus" <burnus(a)net-b.de <mailto:[email protected]>> >>>>> Sent: Sunday, March 24, 2013 5:59:38 PM >>>>> Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 >>>>> interface - issue with the LOGICAL kind >>>>> This time is OK for me. I'll look for the webex email. >>>>> >>>>> I would like to note that the various options discussed are not >>>>> necessarily "all or nothing" propositions. An implementation could >>>>> use >>>>> the thin wrappers in a module approach to eliminate the bad Fortran >>>>> types problems for most of the MPI routines, but also have some >>>>> routines >>>>> implemented in a different way, such as (1) all in Fortran that is >>>>> callable from C, (2) all in C that is called through an interface >>>>> directly from Fortran, (3) as a fat wrapper in Fortran, or (4) a >>>>> completely replicated routine for the Fortran implementation. There >>>>> is >>>>> no reason that all of the routines have to be the same method - in >>>>> fact >>>>> probably good arguments against that in some cases. We just need to >>>>> have >>>>> the rules such that the tools have some known name to intercept. >>>>> Along >>>>> the lines of "If implementation method X is chosen for routine >>>>> MPI_xxx, >>>>> then these are the linker name requirements:.....". >>>>> >>>>> Cheers, >>>>> Bill >>>>> >>>>> >>>>> >>>>> On 3/23/13 2:11 AM, Rolf Rabenseifner wrote: >>>>>> Dear Jeff, Craig, Bill, Hubert, Martin, and Tobias, >>>>>> >>>>>> I expect that this is the total group that discusses the >>>>>> Fortran LOGICAL etc. problem. >>>>>> We learnt that the solutions also touch the PMPI concept. >>>>>> There was a telecon between Craig, Jeff and Bill with the proposal >>>>>> at the end of this email. >>>>>> I like to understand this proposal and therefore I asked Jeff >>>>>> for explanations. I would like to open this for the whole group. >>>>>> >>>>>>> I have meetings at 9am and 1pm is eastern on Monday. I can talk >>>>>>> any >>>>>>> other time. >>>>>>> Craig prob can't attend because he's 3 hours earlier, but that's >>>>>>> prob ok. >>>>>> >>>>>> Monday March 25, >>>>>> - 4 PM Central European Time CET >>>>>> = 11 AM Eastern Daylight Time EST/EDT >>>>>> = 8 AM Pacific Time >>>>>> >>>>>> I hope these relations are correct. Would this work for you? >>>>>> >>>>>> At least for Jeff and me, because I want to understand >>>>>> what they discussed with their proposal. >>>>>> >>>>>> Jeff, can you set up a webex? >>>>>> >>>>>> Best regards >>>>>> Rolf >>>>>> >>>>>> ----- Original Message ----- >>>>>>> From: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com >>>>>>> <mailto:[email protected]>> >>>>>>> To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de >>>>>>> <mailto:[email protected]>> >>>>>>> Cc: "Craig E Rasmussen" <rasmus(a)cas.uoregon.edu >>>>>>> <mailto:[email protected]>> >>>>>>> Sent: Friday, March 22, 2013 8:01:23 PM >>>>>>> Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 >>>>>>> interface - issue with the LOGICAL kind >>>>>>> Btw, I'm not sure how this is not the least surprise. >>>>>>> >>>>>>> We can't change the params to not be logical, yes we must still >>>>>>> allow >>>>>>> for calling to c. So the overloaded solution is the only one. >>>>>>> >>>>>>> And the new Integer param signature must have a new bind name so >>>>>>> as >>>>>>> to >>>>>>> did ambiguity it from the one we published in MPI3. See my >>>>>>> previous >>>>>>> mail about this. >>>>>>> >>>>>>> I have meetings at 9am and 1pm is eastern on Monday. I can talk >>>>>>> any >>>>>>> other time. >>>>>>> >>>>>>> Craig prob can't attend because he's 3 hours earlier, but that's >>>>>>> prob >>>>>>> ok. >>>>>>> >>>>>>> Sent from my phone. No type good. >>>>>>> >>>>>>> On Mar 22, 2013, at 8:51 AM, "Rolf Rabenseifner" >>>>>>> <rabenseifner(a)hlrs.de <mailto:[email protected]>> wrote: >>>>>>> >>>>>>>> Jeff, >>>>>>>> >>>>>>>> can I call you by phone? >>>>>>>> I would like to talk to you as the binding responsible and MPI >>>>>>>> chair. >>>>>>>> >>>>>>>>> 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 >>>>>>>> ... >>>>>>>> This is a hard step and far away from "last surprise". >>>>>>>> >>>>>>>> I would like to learn how it came out as a result of your >>>>>>>> telecon, >>>>>>>> before I try to go the next step (e.g. email answer). >>>>>>>> >>>>>>>> Best regards >>>>>>>> Rolf >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>>> From: "Craig Rasmussen" <rasmus(a)cas.uoregon.edu >>>>>>>>> <mailto:[email protected]>> >>>>>>>>> To: "MPI-3 Fortran working group" >>>>>>>>> <mpi3-fortran(a)lists.mpi-forum.org >>>>>>>>> <mailto:[email protected]>> >>>>>>>>> Cc: "Hubert Ritzdorf" <Hubert.Ritzdorf(a)emea.nec.com >>>>>>>>> <mailto:[email protected]>>, "Martin >>>>>>>>> Schulz" <schulzm(a)llnl.gov <mailto:[email protected]>> >>>>>>>>> Sent: Friday, March 22, 2013 4:29:36 PM >>>>>>>>> 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]> >>>>>> >>>>> >>>>> -- >>>>> Bill Long longb(a)cray.com <mailto:[email protected]> >>>>> 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 >>>> >>>> -- >>>> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de >>>> <mailto:[email protected]> >>>> 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 >>>> <http://www.hlrs.de/people/rabenseifner> >>>> Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) >>> >>> -- >>> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de >>> <mailto:[email protected]> >>> 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 >>> <http://www.hlrs.de/people/rabenseifner> >>> Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) >> > > -- > 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 > > > > > Click https://www.mailcontrol.com/sr/PSMHhYrWn2nGX2PQPOmvUmmLQnadxIEhPqNHPbHRv8fT… to report this email as spam. ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0

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

25 Mar '13

I vote for Option 2. Option 3 is not possible for an errata. This is a severe change in the standard. Your modification of Option 3 makes the standard more difficult (we have again mixing of BIND(C) and non BIND(C) functions) and I can't see a real application advantage. To your items: Item 2: You have to perform also additional work in the wrappers (for example memory allocation and transformation for sources compiled with -i8; additional error checks) Item 3: Support of PMPI version of Fortran is not really an issue. Item 4b: The tools have to support routines compiled with mpi.h and old objects. Hubert ________________________________________ From: Bill Long [longb(a)cray.com] Sent: Monday, March 25, 2013 7:35 PM To: Craig Rasmussen Cc: Rolf Rabenseifner; MPI-3 Fortran working group; Jeff Squyres (jsquyres); Hubert Ritzdorf; Martin Schulz; Tobias Burnus Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind On 3/25/13 12:50 PM, Craig Rasmussen wrote: > My summary of the three options: > > 1. Absolute minimal change, remove BIND(C) only for routines with > LOGICAL arguments. Tools will need to support underscore name mangling > forever (even when TS29113 is implemented by compilers) but only on > routines with LOGICAL arguments. > > 2. Remove BIND(C) from all routines. Tools will need to support > underscore name mangling for all routines. > > 3. Remove BIND(C) from all routines. Plus allow Fortran implementations > to substitute the C PMPI interface standard. > > Is this a fair summary? > > My vote: > > I'm strongly in favor of option 3. It is the only option that allows > the possibility of underscore name mangling disappearing in the future. > I think most (if not all) MPI Fortran implementations will eventually > evolve to thin wrappers calling the C API. There are several advantages > with this implementation: > 1. The thin wrappers can be put in a module. > 2. Compilers may be able to inline the wrappers for very efficient > implementations. > 3. Fortran implementations are much simpler because they won't have > to directly support PMPI in Fortran. > 4. Since the Fortran implementation is substantially less complex, > the costs associated with testing, supporting, and maintaining a Fortran > implementation will also be reduced. > 4. If all MPI implementations eventually choose to call the C API, > then the tools community eventually will not have to support underscore > name mangling, thus reducing their costs as well. I like option 3 as well. It uses the C interoperability feature in Fortran the way it was intended/designed. I would add to the above: 6. You can isolate the issues of Fortran types (compiled with -i8, meaning of LOGICAL, character arguments with len > 1) into the Fortran wrappers so that the C library writers do not have to know about these issues. Simplifies the maintenance and testing issues for the C library code. I would modify option 3 slightly. The implementer might want to write some routine ONLY in Fortran. The routines that convert the status formats between the Fortran and the C forms comes to mind. In that case, BIND(C) would be required, and it would specify the C binding name as the external linker name. This would be needed so that C codes could call the routine. Cheers, Bill > > Craig Rasmussen > CAS Scientific Programmer > rasmus(a)cas.uoregon.edu <mailto:[email protected]> > > > > > On Mar 25, 2013, at 10:11 AM, Rolf Rabenseifner wrote: > >> We (Jeff, Bill L., Craig, Hubert, Martin, Tobias, and me (Rolf)) had >> a telecon today and the outcome are following options: >> >> Option 1 >> - #364 as it currently is, as a minimal solution for >> the LOGICAL problem: >> Pro: It is consistent between Fortran and MPI. >> I.e., it is the minimal solution that we must do. >> Con: It has a mix of BIND(C) and non-BIND(C) routine groups >> which is ugly for the future. >> Remark: non-BIND(C) will stay there because the callbacks >> need non-BIND(C) in the moment and this cannot be >> changed in the future by nice new concepts from >> the Fortran language standardization. >> >> Option 2 >> - #364 plus changing MPI-3.0 page 605 lines 24-30 and >> page 605 line 47 - page 606 line 6 by also using non-BIND(C), >> but other linker names: >> MPI_Send_f08d (in mpi_f08 with TS29113 quality, i.e., >> buffers are done with C-descriptors and >> not with void* pointers.) >> MPI_Send_fd (in the mpi module or mpif.h if >> MPI_SUBARRAYS_SUPPORTED=.TRUE. is also done >> there, i.e., with the descriptors.) >> >> Pro: It is consistent between Fortran and MPI >> and it is consistent within MPI, i.e., all >> functionality is done with non-BIND(C) routines. >> BIND(C) can be still used internally to >> call MPI_Send_cdesc and MPI_Isend_cdesc. >> To be fair, implementatiosn will be based mainly >> on this TS 29113 feature, but only internally. >> Con: No BIND(C) on the official MPI interface. >> We urged Fortran to put some features into TS 29113, >> but we will not use these features, because they >> are not needed on this internal interface. >> >> Option 3: >> - Option 2 plus the following rule: >> - The Fortran PMPI interface can be substituted by a >> wrapper based sulution that internally calls the full >> MPI C interface. >> - In this case, the Fortran interface should be hidden >> to the tools. >> - For the buffer routines with the new cdesc descriptor, >> new interfaces are added for the tools people, >> e.g., MPI_Send_cdesc and MPI_Isend_cdesc. >> >> Pro: I'm not sure whether there is a real pro? >> >> Bill, can you add the pros, it is your option. >> >> Con: An additional new interface for the tools folk. >> It is not backward compatible for users who really >> intercept the Fortran MPI interface. >> >> My favorite in the moment, i.e. at the starting of >> the pro-con-discussion: Option 2. >> >> Best regards >> Rolf >> >> >> >> ----- Original Message ----- >>> From: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de >>> <mailto:[email protected]>> >>> To: longb(a)cray.com <mailto:[email protected]> >>> Cc: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com >>> <mailto:[email protected]>>, "Craig E Rasmussen" >>> <rasmus(a)cas.uoregon.edu <mailto:[email protected]>>, "Hubert >>> Ritzdorf" >>> <Hubert.Ritzdorf(a)emea.nec.com <mailto:[email protected]>>, >>> "Martin Schulz" <schulzm(a)llnl.gov <mailto:[email protected]>>, "Tobias >>> Burnus" <burnus(a)net-b.de <mailto:[email protected]>> >>> Sent: Monday, March 25, 2013 12:21:39 PM >>> Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 >>> interface - issue with the LOGICAL kind >>> Yes, this freedom (1)-(4) in Bill's email is important. >>> >>> In our discussion, we forgot one additional reason why we defined >>> it as it is written in MPI-3.0 Section 17.1.5, page 605: >>> >>> - It should be possible to implement the interfaces with >>> these non-standard Fortran-void-* directives, >>> and later on, >>> to substitute this implementation by new ones >>> that are based on TS 29113. >>> - When doing this substitution, it should be save for >>> applications when the application is not re-compiled. >>> - More than that, it should be possible to combine older >>> .o files with newly TS 29113 based .o files. >>> - For this, we decided, that the implementation has to switch >>> from non-BIND(C) to BIND(C) at least in the MPI_ISEND >>> routine group when switching to MPI_SUBARRAYS_SUPPORTED==.TRUE. >>> - The real trick is that the linker name must be changed. >>> - This all is valid for both, the new mpi_f08 module, >>> and the old mpi module. >>> >>> A second issue in our discussion is always, which changes >>> we want to do to the mpi_f08 MPI-3.0 user interface. >>> I want to remember that this user interface is defined >>> according following rules. >>> If a user modifies his source to use everywhere mpi_f08, >>> he/she has to modify: >>> - He/she has to substitute the "include 'mpif.h'" or "use mpi" >>> statements by "use mpi_f08". >>> - He/she has to modify all handle and status declarations. >>> - In the executable statements, he/she has to substitute all >>> status(MPI_TAG), status(MPI_SOURCE), status(MPI_ERROR) >>> accesses into >>> status%MPI_TAG, status%MPI_SOURCE, status%MPI_ERROR. >>> - Callback routines need more effort due to the >>> abstract interface definitions. >>> This is touched by ticket #364, i.e., >>> the MPI-3.0 BIND(C) of callbacks had to be removed. >>> - Changes in the interfaces are only >>> -- all handles use the new handle types >>> and in >>> -- MPI_User_function, >>> -- MPI_Datarep_conversion_function, >>> the buffers are done with TYPE(C_TR), VALUE. >>> >>> This should be all. >>> All other user correct code should directly compile with the new >>> mpi_f08 module. >>> We should not change these things, except the necessary >>> errata in #364. >>> >>> I see that we have some freedom only in the area, >>> what we do internally (together with linker names) and with PMPI, >>> but not in the user interface. >>> If we add additional user interfaces (e.g. overloading the LOGICAL >>> with INTEGER arguments) >>> we would only make it more complicate. >>> >>> Best regards >>> Rolf >>> >>> >>> ----- Original Message ----- >>>> From: "Bill Long" <longb(a)cray.com <mailto:[email protected]>> >>>> To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de >>>> <mailto:[email protected]>> >>>> Cc: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com >>>> <mailto:[email protected]>>, "Craig E >>>> Rasmussen" <rasmus(a)cas.uoregon.edu <mailto:[email protected]>>, >>>> "Hubert Ritzdorf" >>>> <Hubert.Ritzdorf(a)emea.nec.com >>>> <mailto:[email protected]>>, "Martin Schulz" >>>> <schulzm(a)llnl.gov <mailto:[email protected]>>, >>>> "Tobias Burnus" <burnus(a)net-b.de <mailto:[email protected]>> >>>> Sent: Sunday, March 24, 2013 5:59:38 PM >>>> Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 >>>> interface - issue with the LOGICAL kind >>>> This time is OK for me. I'll look for the webex email. >>>> >>>> I would like to note that the various options discussed are not >>>> necessarily "all or nothing" propositions. An implementation could >>>> use >>>> the thin wrappers in a module approach to eliminate the bad Fortran >>>> types problems for most of the MPI routines, but also have some >>>> routines >>>> implemented in a different way, such as (1) all in Fortran that is >>>> callable from C, (2) all in C that is called through an interface >>>> directly from Fortran, (3) as a fat wrapper in Fortran, or (4) a >>>> completely replicated routine for the Fortran implementation. There >>>> is >>>> no reason that all of the routines have to be the same method - in >>>> fact >>>> probably good arguments against that in some cases. We just need to >>>> have >>>> the rules such that the tools have some known name to intercept. >>>> Along >>>> the lines of "If implementation method X is chosen for routine >>>> MPI_xxx, >>>> then these are the linker name requirements:.....". >>>> >>>> Cheers, >>>> Bill >>>> >>>> >>>> >>>> On 3/23/13 2:11 AM, Rolf Rabenseifner wrote: >>>>> Dear Jeff, Craig, Bill, Hubert, Martin, and Tobias, >>>>> >>>>> I expect that this is the total group that discusses the >>>>> Fortran LOGICAL etc. problem. >>>>> We learnt that the solutions also touch the PMPI concept. >>>>> There was a telecon between Craig, Jeff and Bill with the proposal >>>>> at the end of this email. >>>>> I like to understand this proposal and therefore I asked Jeff >>>>> for explanations. I would like to open this for the whole group. >>>>> >>>>>> I have meetings at 9am and 1pm is eastern on Monday. I can talk >>>>>> any >>>>>> other time. >>>>>> Craig prob can't attend because he's 3 hours earlier, but that's >>>>>> prob ok. >>>>> >>>>> Monday March 25, >>>>> - 4 PM Central European Time CET >>>>> = 11 AM Eastern Daylight Time EST/EDT >>>>> = 8 AM Pacific Time >>>>> >>>>> I hope these relations are correct. Would this work for you? >>>>> >>>>> At least for Jeff and me, because I want to understand >>>>> what they discussed with their proposal. >>>>> >>>>> Jeff, can you set up a webex? >>>>> >>>>> Best regards >>>>> Rolf >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com >>>>>> <mailto:[email protected]>> >>>>>> To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de >>>>>> <mailto:[email protected]>> >>>>>> Cc: "Craig E Rasmussen" <rasmus(a)cas.uoregon.edu >>>>>> <mailto:[email protected]>> >>>>>> Sent: Friday, March 22, 2013 8:01:23 PM >>>>>> Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 >>>>>> interface - issue with the LOGICAL kind >>>>>> Btw, I'm not sure how this is not the least surprise. >>>>>> >>>>>> We can't change the params to not be logical, yes we must still >>>>>> allow >>>>>> for calling to c. So the overloaded solution is the only one. >>>>>> >>>>>> And the new Integer param signature must have a new bind name so >>>>>> as >>>>>> to >>>>>> did ambiguity it from the one we published in MPI3. See my >>>>>> previous >>>>>> mail about this. >>>>>> >>>>>> I have meetings at 9am and 1pm is eastern on Monday. I can talk >>>>>> any >>>>>> other time. >>>>>> >>>>>> Craig prob can't attend because he's 3 hours earlier, but that's >>>>>> prob >>>>>> ok. >>>>>> >>>>>> Sent from my phone. No type good. >>>>>> >>>>>> On Mar 22, 2013, at 8:51 AM, "Rolf Rabenseifner" >>>>>> <rabenseifner(a)hlrs.de <mailto:[email protected]>> wrote: >>>>>> >>>>>>> Jeff, >>>>>>> >>>>>>> can I call you by phone? >>>>>>> I would like to talk to you as the binding responsible and MPI >>>>>>> chair. >>>>>>> >>>>>>>> 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 >>>>>>> ... >>>>>>> This is a hard step and far away from "last surprise". >>>>>>> >>>>>>> I would like to learn how it came out as a result of your >>>>>>> telecon, >>>>>>> before I try to go the next step (e.g. email answer). >>>>>>> >>>>>>> Best regards >>>>>>> Rolf >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>>> From: "Craig Rasmussen" <rasmus(a)cas.uoregon.edu >>>>>>>> <mailto:[email protected]>> >>>>>>>> To: "MPI-3 Fortran working group" >>>>>>>> <mpi3-fortran(a)lists.mpi-forum.org >>>>>>>> <mailto:[email protected]>> >>>>>>>> Cc: "Hubert Ritzdorf" <Hubert.Ritzdorf(a)emea.nec.com >>>>>>>> <mailto:[email protected]>>, "Martin >>>>>>>> Schulz" <schulzm(a)llnl.gov <mailto:[email protected]>> >>>>>>>> Sent: Friday, March 22, 2013 4:29:36 PM >>>>>>>> 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]> >>>>> >>>> >>>> -- >>>> Bill Long longb(a)cray.com <mailto:[email protected]> >>>> 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 >>> >>> -- >>> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de >>> <mailto:[email protected]> >>> 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 >>> <http://www.hlrs.de/people/rabenseifner> >>> Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) >> >> -- >> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de >> <mailto:[email protected]> >> 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 >> <http://www.hlrs.de/people/rabenseifner> >> Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) > -- 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 Click https://www.mailcontrol.com/sr/PSMHhYrWn2nGX2PQPOmvUmmLQnadxIEhPqNHPbHRv8fT… to report this email as spam.

1 0

Re: [MPI3 Fortran] Another (smaller) issue with MPI 3.0 and BIND(C)
by Craig Rasmussen 25 Mar '13

25 Mar '13

I agree with Tobias. This also must be changed. I've tried a couple of compilers and they now get sequence association correct so that changing the interfaces to arrays of CHARACTER(LEN=1) dummy arguments should now work. A couple of years ago a few compilers I tried failed to do this correctly. Craig Rasmussen CAS Scientific Programmer rasmus(a)cas.uoregon.edu On Mar 18, 2013, at 1:44 AM, Tobias Burnus wrote: > Dear all, > > there is possible one other problem with some BIND(C) interfaces in MPI 3.0: > > MPI_Comm_get_name(comm, comm_name, resultlen, ierror) BIND(C) > TYPE(MPI_Comm), INTENT(IN) :: comm > CHARACTER(LEN=MPI_MAX_OBJECT_NAME), INTENT(OUT) :: comm_nameI > > Namely, it uses a CHARACTER dummy argument which does not have LEN=1 in a procedure with C binding. > > > From Fortran 2008's "15.3.2 Interoperability of intrinsic types" (p.429, paragraph 1): > > "If the type is character, the length type parameter is interoperable if and only if its value is one." > > > Initially, I though that the following would allow it: > > "A named scalar Fortran variable is interoperable if and only if its type and type parameters are interoperable, [...] and if it is of type character > its length is not assumed or declared by an expression that is not a constant expression." > ("15.3.5 Interoperability of scalar variables", p. 432, paragraph 1.) > > I thought that the latter part allows it. However, as Bill pointed out: The "if and only if ... type parameters are interoperable" makes clear that it is only interoperable if the length is 1. (The second condition makes only sure that this it is compile-time checking by not allowing len=* or nonconst expressions). > > TS 29113 allows in addtion len=* and len=: for dummy arguments of BIND(C) procedures. However, that doesn't help for LEN=MPI_MAX_OBJECT_NAME, either. (For len=*/len=:, TS 29113 requires that an array descriptor is used; cf. "8.7 Interoperability of procedures and procedure interfaces", p.31, (6)(b) and the paragraph below (6)(d).). > > > I think the simplest is to change: > > CHARACTER(LEN=MPI_MAX_OBJECT_NAME), INTENT(OUT) :: comm_nameI > to > CHARACTER, INTENT(OUT) :: comm_nameI(MPI_MAX_OBJECT_NAME) > > Namely, to change the character length to 1 and the array size to MPI_MAX_OBJECT_NAME. Using the storage association for characters, a character(len=MPI_MAX_OBJECT_NAME) variable can be passed to a character(len=1) character array of size MPI_MAX_OBJECT_NAME. > > To quote the standard: > > "The type parameter values of the actual argument shall agree with the corresponding ones of the dummy argument that are not assumed, except for the case of the character length parameter of a default character or character with the C character kind (15.2.2) actual argument associated with a dummy argument that is not assumed shape. > If a scalar dummy argument is default character or of type character with the C character kind, the length len of the dummy argument shall be less than or equal to the length of the actual argument. The dummy argument becomes associated with the leftmost len characters of the actual argument. If an array dummy argument is default character or of type character with the C character kind and is not assumed shape, it becomes associated with the leftmost characters of the actual argument element sequence (12.5.2.11)." > > (F2008, "12.5.2.4 Ordinary dummy variables", p. 293, paragraphs 3 and 4.) > > Tobias > _______________________________________________ > 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 25 Mar '13

25 Mar '13

On 3/25/13 12:50 PM, Craig Rasmussen wrote: > My summary of the three options: > > 1. Absolute minimal change, remove BIND(C) only for routines with > LOGICAL arguments. Tools will need to support underscore name mangling > forever (even when TS29113 is implemented by compilers) but only on > routines with LOGICAL arguments. > > 2. Remove BIND(C) from all routines. Tools will need to support > underscore name mangling for all routines. > > 3. Remove BIND(C) from all routines. Plus allow Fortran implementations > to substitute the C PMPI interface standard. > > Is this a fair summary? > > My vote: > > I'm strongly in favor of option 3. It is the only option that allows > the possibility of underscore name mangling disappearing in the future. > I think most (if not all) MPI Fortran implementations will eventually > evolve to thin wrappers calling the C API. There are several advantages > with this implementation: > 1. The thin wrappers can be put in a module. > 2. Compilers may be able to inline the wrappers for very efficient > implementations. > 3. Fortran implementations are much simpler because they won't have > to directly support PMPI in Fortran. > 4. Since the Fortran implementation is substantially less complex, > the costs associated with testing, supporting, and maintaining a Fortran > implementation will also be reduced. > 4. If all MPI implementations eventually choose to call the C API, > then the tools community eventually will not have to support underscore > name mangling, thus reducing their costs as well. I like option 3 as well. It uses the C interoperability feature in Fortran the way it was intended/designed. I would add to the above: 6. You can isolate the issues of Fortran types (compiled with -i8, meaning of LOGICAL, character arguments with len > 1) into the Fortran wrappers so that the C library writers do not have to know about these issues. Simplifies the maintenance and testing issues for the C library code. I would modify option 3 slightly. The implementer might want to write some routine ONLY in Fortran. The routines that convert the status formats between the Fortran and the C forms comes to mind. In that case, BIND(C) would be required, and it would specify the C binding name as the external linker name. This would be needed so that C codes could call the routine. Cheers, Bill > > Craig Rasmussen > CAS Scientific Programmer > rasmus(a)cas.uoregon.edu <mailto:[email protected]> > > > > > On Mar 25, 2013, at 10:11 AM, Rolf Rabenseifner wrote: > >> We (Jeff, Bill L., Craig, Hubert, Martin, Tobias, and me (Rolf)) had >> a telecon today and the outcome are following options: >> >> Option 1 >> - #364 as it currently is, as a minimal solution for >> the LOGICAL problem: >> Pro: It is consistent between Fortran and MPI. >> I.e., it is the minimal solution that we must do. >> Con: It has a mix of BIND(C) and non-BIND(C) routine groups >> which is ugly for the future. >> Remark: non-BIND(C) will stay there because the callbacks >> need non-BIND(C) in the moment and this cannot be >> changed in the future by nice new concepts from >> the Fortran language standardization. >> >> Option 2 >> - #364 plus changing MPI-3.0 page 605 lines 24-30 and >> page 605 line 47 - page 606 line 6 by also using non-BIND(C), >> but other linker names: >> MPI_Send_f08d (in mpi_f08 with TS29113 quality, i.e., >> buffers are done with C-descriptors and >> not with void* pointers.) >> MPI_Send_fd (in the mpi module or mpif.h if >> MPI_SUBARRAYS_SUPPORTED=.TRUE. is also done >> there, i.e., with the descriptors.) >> >> Pro: It is consistent between Fortran and MPI >> and it is consistent within MPI, i.e., all >> functionality is done with non-BIND(C) routines. >> BIND(C) can be still used internally to >> call MPI_Send_cdesc and MPI_Isend_cdesc. >> To be fair, implementatiosn will be based mainly >> on this TS 29113 feature, but only internally. >> Con: No BIND(C) on the official MPI interface. >> We urged Fortran to put some features into TS 29113, >> but we will not use these features, because they >> are not needed on this internal interface. >> >> Option 3: >> - Option 2 plus the following rule: >> - The Fortran PMPI interface can be substituted by a >> wrapper based sulution that internally calls the full >> MPI C interface. >> - In this case, the Fortran interface should be hidden >> to the tools. >> - For the buffer routines with the new cdesc descriptor, >> new interfaces are added for the tools people, >> e.g., MPI_Send_cdesc and MPI_Isend_cdesc. >> >> Pro: I'm not sure whether there is a real pro? >> >> Bill, can you add the pros, it is your option. >> >> Con: An additional new interface for the tools folk. >> It is not backward compatible for users who really >> intercept the Fortran MPI interface. >> >> My favorite in the moment, i.e. at the starting of >> the pro-con-discussion: Option 2. >> >> Best regards >> Rolf >> >> >> >> ----- Original Message ----- >>> From: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de >>> <mailto:[email protected]>> >>> To: longb(a)cray.com <mailto:[email protected]> >>> Cc: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com >>> <mailto:[email protected]>>, "Craig E Rasmussen" >>> <rasmus(a)cas.uoregon.edu <mailto:[email protected]>>, "Hubert >>> Ritzdorf" >>> <Hubert.Ritzdorf(a)emea.nec.com <mailto:[email protected]>>, >>> "Martin Schulz" <schulzm(a)llnl.gov <mailto:[email protected]>>, "Tobias >>> Burnus" <burnus(a)net-b.de <mailto:[email protected]>> >>> Sent: Monday, March 25, 2013 12:21:39 PM >>> Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 >>> interface - issue with the LOGICAL kind >>> Yes, this freedom (1)-(4) in Bill's email is important. >>> >>> In our discussion, we forgot one additional reason why we defined >>> it as it is written in MPI-3.0 Section 17.1.5, page 605: >>> >>> - It should be possible to implement the interfaces with >>> these non-standard Fortran-void-* directives, >>> and later on, >>> to substitute this implementation by new ones >>> that are based on TS 29113. >>> - When doing this substitution, it should be save for >>> applications when the application is not re-compiled. >>> - More than that, it should be possible to combine older >>> .o files with newly TS 29113 based .o files. >>> - For this, we decided, that the implementation has to switch >>> from non-BIND(C) to BIND(C) at least in the MPI_ISEND >>> routine group when switching to MPI_SUBARRAYS_SUPPORTED==.TRUE. >>> - The real trick is that the linker name must be changed. >>> - This all is valid for both, the new mpi_f08 module, >>> and the old mpi module. >>> >>> A second issue in our discussion is always, which changes >>> we want to do to the mpi_f08 MPI-3.0 user interface. >>> I want to remember that this user interface is defined >>> according following rules. >>> If a user modifies his source to use everywhere mpi_f08, >>> he/she has to modify: >>> - He/she has to substitute the "include 'mpif.h'" or "use mpi" >>> statements by "use mpi_f08". >>> - He/she has to modify all handle and status declarations. >>> - In the executable statements, he/she has to substitute all >>> status(MPI_TAG), status(MPI_SOURCE), status(MPI_ERROR) >>> accesses into >>> status%MPI_TAG, status%MPI_SOURCE, status%MPI_ERROR. >>> - Callback routines need more effort due to the >>> abstract interface definitions. >>> This is touched by ticket #364, i.e., >>> the MPI-3.0 BIND(C) of callbacks had to be removed. >>> - Changes in the interfaces are only >>> -- all handles use the new handle types >>> and in >>> -- MPI_User_function, >>> -- MPI_Datarep_conversion_function, >>> the buffers are done with TYPE(C_TR), VALUE. >>> >>> This should be all. >>> All other user correct code should directly compile with the new >>> mpi_f08 module. >>> We should not change these things, except the necessary >>> errata in #364. >>> >>> I see that we have some freedom only in the area, >>> what we do internally (together with linker names) and with PMPI, >>> but not in the user interface. >>> If we add additional user interfaces (e.g. overloading the LOGICAL >>> with INTEGER arguments) >>> we would only make it more complicate. >>> >>> Best regards >>> Rolf >>> >>> >>> ----- Original Message ----- >>>> From: "Bill Long" <longb(a)cray.com <mailto:[email protected]>> >>>> To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de >>>> <mailto:[email protected]>> >>>> Cc: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com >>>> <mailto:[email protected]>>, "Craig E >>>> Rasmussen" <rasmus(a)cas.uoregon.edu <mailto:[email protected]>>, >>>> "Hubert Ritzdorf" >>>> <Hubert.Ritzdorf(a)emea.nec.com >>>> <mailto:[email protected]>>, "Martin Schulz" >>>> <schulzm(a)llnl.gov <mailto:[email protected]>>, >>>> "Tobias Burnus" <burnus(a)net-b.de <mailto:[email protected]>> >>>> Sent: Sunday, March 24, 2013 5:59:38 PM >>>> Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 >>>> interface - issue with the LOGICAL kind >>>> This time is OK for me. I'll look for the webex email. >>>> >>>> I would like to note that the various options discussed are not >>>> necessarily "all or nothing" propositions. An implementation could >>>> use >>>> the thin wrappers in a module approach to eliminate the bad Fortran >>>> types problems for most of the MPI routines, but also have some >>>> routines >>>> implemented in a different way, such as (1) all in Fortran that is >>>> callable from C, (2) all in C that is called through an interface >>>> directly from Fortran, (3) as a fat wrapper in Fortran, or (4) a >>>> completely replicated routine for the Fortran implementation. There >>>> is >>>> no reason that all of the routines have to be the same method - in >>>> fact >>>> probably good arguments against that in some cases. We just need to >>>> have >>>> the rules such that the tools have some known name to intercept. >>>> Along >>>> the lines of "If implementation method X is chosen for routine >>>> MPI_xxx, >>>> then these are the linker name requirements:.....". >>>> >>>> Cheers, >>>> Bill >>>> >>>> >>>> >>>> On 3/23/13 2:11 AM, Rolf Rabenseifner wrote: >>>>> Dear Jeff, Craig, Bill, Hubert, Martin, and Tobias, >>>>> >>>>> I expect that this is the total group that discusses the >>>>> Fortran LOGICAL etc. problem. >>>>> We learnt that the solutions also touch the PMPI concept. >>>>> There was a telecon between Craig, Jeff and Bill with the proposal >>>>> at the end of this email. >>>>> I like to understand this proposal and therefore I asked Jeff >>>>> for explanations. I would like to open this for the whole group. >>>>> >>>>>> I have meetings at 9am and 1pm is eastern on Monday. I can talk >>>>>> any >>>>>> other time. >>>>>> Craig prob can't attend because he's 3 hours earlier, but that's >>>>>> prob ok. >>>>> >>>>> Monday March 25, >>>>> - 4 PM Central European Time CET >>>>> = 11 AM Eastern Daylight Time EST/EDT >>>>> = 8 AM Pacific Time >>>>> >>>>> I hope these relations are correct. Would this work for you? >>>>> >>>>> At least for Jeff and me, because I want to understand >>>>> what they discussed with their proposal. >>>>> >>>>> Jeff, can you set up a webex? >>>>> >>>>> Best regards >>>>> Rolf >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com >>>>>> <mailto:[email protected]>> >>>>>> To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de >>>>>> <mailto:[email protected]>> >>>>>> Cc: "Craig E Rasmussen" <rasmus(a)cas.uoregon.edu >>>>>> <mailto:[email protected]>> >>>>>> Sent: Friday, March 22, 2013 8:01:23 PM >>>>>> Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 >>>>>> interface - issue with the LOGICAL kind >>>>>> Btw, I'm not sure how this is not the least surprise. >>>>>> >>>>>> We can't change the params to not be logical, yes we must still >>>>>> allow >>>>>> for calling to c. So the overloaded solution is the only one. >>>>>> >>>>>> And the new Integer param signature must have a new bind name so >>>>>> as >>>>>> to >>>>>> did ambiguity it from the one we published in MPI3. See my >>>>>> previous >>>>>> mail about this. >>>>>> >>>>>> I have meetings at 9am and 1pm is eastern on Monday. I can talk >>>>>> any >>>>>> other time. >>>>>> >>>>>> Craig prob can't attend because he's 3 hours earlier, but that's >>>>>> prob >>>>>> ok. >>>>>> >>>>>> Sent from my phone. No type good. >>>>>> >>>>>> On Mar 22, 2013, at 8:51 AM, "Rolf Rabenseifner" >>>>>> <rabenseifner(a)hlrs.de <mailto:[email protected]>> wrote: >>>>>> >>>>>>> Jeff, >>>>>>> >>>>>>> can I call you by phone? >>>>>>> I would like to talk to you as the binding responsible and MPI >>>>>>> chair. >>>>>>> >>>>>>>> 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 >>>>>>> ... >>>>>>> This is a hard step and far away from "last surprise". >>>>>>> >>>>>>> I would like to learn how it came out as a result of your >>>>>>> telecon, >>>>>>> before I try to go the next step (e.g. email answer). >>>>>>> >>>>>>> Best regards >>>>>>> Rolf >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>>> From: "Craig Rasmussen" <rasmus(a)cas.uoregon.edu >>>>>>>> <mailto:[email protected]>> >>>>>>>> To: "MPI-3 Fortran working group" >>>>>>>> <mpi3-fortran(a)lists.mpi-forum.org >>>>>>>> <mailto:[email protected]>> >>>>>>>> Cc: "Hubert Ritzdorf" <Hubert.Ritzdorf(a)emea.nec.com >>>>>>>> <mailto:[email protected]>>, "Martin >>>>>>>> Schulz" <schulzm(a)llnl.gov <mailto:[email protected]>> >>>>>>>> Sent: Friday, March 22, 2013 4:29:36 PM >>>>>>>> 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]> >>>>> >>>> >>>> -- >>>> Bill Long longb(a)cray.com <mailto:[email protected]> >>>> 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 >>> >>> -- >>> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de >>> <mailto:[email protected]> >>> 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 >>> <http://www.hlrs.de/people/rabenseifner> >>> Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) >> >> -- >> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de >> <mailto:[email protected]> >> 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 >> <http://www.hlrs.de/people/rabenseifner> >> Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) > -- 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 25 Mar '13

25 Mar '13

My summary of the three options: 1. Absolute minimal change, remove BIND(C) only for routines with LOGICAL arguments. Tools will need to support underscore name mangling forever (even when TS29113 is implemented by compilers) but only on routines with LOGICAL arguments. 2. Remove BIND(C) from all routines. Tools will need to support underscore name mangling for all routines. 3. Remove BIND(C) from all routines. Plus allow Fortran implementations to substitute the C PMPI interface standard. Is this a fair summary? My vote: I'm strongly in favor of option 3. It is the only option that allows the possibility of underscore name mangling disappearing in the future. I think most (if not all) MPI Fortran implementations will eventually evolve to thin wrappers calling the C API. There are several advantages with this implementation: 1. The thin wrappers can be put in a module. 2. Compilers may be able to inline the wrappers for very efficient implementations. 3. Fortran implementations are much simpler because they won't have to directly support PMPI in Fortran. 4. Since the Fortran implementation is substantially less complex, the costs associated with testing, supporting, and maintaining a Fortran implementation will also be reduced. 4. If all MPI implementations eventually choose to call the C API, then the tools community eventually will not have to support underscore name mangling, thus reducing their costs as well. Craig Rasmussen CAS Scientific Programmer rasmus(a)cas.uoregon.edu On Mar 25, 2013, at 10:11 AM, Rolf Rabenseifner wrote: > We (Jeff, Bill L., Craig, Hubert, Martin, Tobias, and me (Rolf)) had > a telecon today and the outcome are following options: > > Option 1 > - #364 as it currently is, as a minimal solution for > the LOGICAL problem: > Pro: It is consistent between Fortran and MPI. > I.e., it is the minimal solution that we must do. > Con: It has a mix of BIND(C) and non-BIND(C) routine groups > which is ugly for the future. > Remark: non-BIND(C) will stay there because the callbacks > need non-BIND(C) in the moment and this cannot be > changed in the future by nice new concepts from > the Fortran language standardization. > > Option 2 > - #364 plus changing MPI-3.0 page 605 lines 24-30 and > page 605 line 47 - page 606 line 6 by also using non-BIND(C), > but other linker names: > MPI_Send_f08d (in mpi_f08 with TS29113 quality, i.e., > buffers are done with C-descriptors and > not with void* pointers.) > MPI_Send_fd (in the mpi module or mpif.h if > MPI_SUBARRAYS_SUPPORTED=.TRUE. is also done > there, i.e., with the descriptors.) > > Pro: It is consistent between Fortran and MPI > and it is consistent within MPI, i.e., all > functionality is done with non-BIND(C) routines. > BIND(C) can be still used internally to > call MPI_Send_cdesc and MPI_Isend_cdesc. > To be fair, implementatiosn will be based mainly > on this TS 29113 feature, but only internally. > Con: No BIND(C) on the official MPI interface. > We urged Fortran to put some features into TS 29113, > but we will not use these features, because they > are not needed on this internal interface. > > Option 3: > - Option 2 plus the following rule: > - The Fortran PMPI interface can be substituted by a > wrapper based sulution that internally calls the full > MPI C interface. > - In this case, the Fortran interface should be hidden > to the tools. > - For the buffer routines with the new cdesc descriptor, > new interfaces are added for the tools people, > e.g., MPI_Send_cdesc and MPI_Isend_cdesc. > > Pro: I'm not sure whether there is a real pro? > > Bill, can you add the pros, it is your option. > > Con: An additional new interface for the tools folk. > It is not backward compatible for users who really > intercept the Fortran MPI interface. > > My favorite in the moment, i.e. at the starting of > the pro-con-discussion: Option 2. > > Best regards > Rolf > > > > ----- Original Message ----- >> From: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> >> To: longb(a)cray.com >> Cc: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com>, "Craig E Rasmussen" <rasmus(a)cas.uoregon.edu>, "Hubert Ritzdorf" >> <Hubert.Ritzdorf(a)emea.nec.com>, "Martin Schulz" <schulzm(a)llnl.gov>, "Tobias Burnus" <burnus(a)net-b.de> >> Sent: Monday, March 25, 2013 12:21:39 PM >> Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind >> Yes, this freedom (1)-(4) in Bill's email is important. >> >> In our discussion, we forgot one additional reason why we defined >> it as it is written in MPI-3.0 Section 17.1.5, page 605: >> >> - It should be possible to implement the interfaces with >> these non-standard Fortran-void-* directives, >> and later on, >> to substitute this implementation by new ones >> that are based on TS 29113. >> - When doing this substitution, it should be save for >> applications when the application is not re-compiled. >> - More than that, it should be possible to combine older >> .o files with newly TS 29113 based .o files. >> - For this, we decided, that the implementation has to switch >> from non-BIND(C) to BIND(C) at least in the MPI_ISEND >> routine group when switching to MPI_SUBARRAYS_SUPPORTED==.TRUE. >> - The real trick is that the linker name must be changed. >> - This all is valid for both, the new mpi_f08 module, >> and the old mpi module. >> >> A second issue in our discussion is always, which changes >> we want to do to the mpi_f08 MPI-3.0 user interface. >> I want to remember that this user interface is defined >> according following rules. >> If a user modifies his source to use everywhere mpi_f08, >> he/she has to modify: >> - He/she has to substitute the "include 'mpif.h'" or "use mpi" >> statements by "use mpi_f08". >> - He/she has to modify all handle and status declarations. >> - In the executable statements, he/she has to substitute all >> status(MPI_TAG), status(MPI_SOURCE), status(MPI_ERROR) >> accesses into >> status%MPI_TAG, status%MPI_SOURCE, status%MPI_ERROR. >> - Callback routines need more effort due to the >> abstract interface definitions. >> This is touched by ticket #364, i.e., >> the MPI-3.0 BIND(C) of callbacks had to be removed. >> - Changes in the interfaces are only >> -- all handles use the new handle types >> and in >> -- MPI_User_function, >> -- MPI_Datarep_conversion_function, >> the buffers are done with TYPE(C_TR), VALUE. >> >> This should be all. >> All other user correct code should directly compile with the new >> mpi_f08 module. >> We should not change these things, except the necessary >> errata in #364. >> >> I see that we have some freedom only in the area, >> what we do internally (together with linker names) and with PMPI, >> but not in the user interface. >> If we add additional user interfaces (e.g. overloading the LOGICAL >> with INTEGER arguments) >> we would only make it more complicate. >> >> Best regards >> Rolf >> >> >> ----- Original Message ----- >>> From: "Bill Long" <longb(a)cray.com> >>> To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> >>> Cc: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com>, "Craig E >>> Rasmussen" <rasmus(a)cas.uoregon.edu>, "Hubert Ritzdorf" >>> <Hubert.Ritzdorf(a)emea.nec.com>, "Martin Schulz" <schulzm(a)llnl.gov>, >>> "Tobias Burnus" <burnus(a)net-b.de> >>> Sent: Sunday, March 24, 2013 5:59:38 PM >>> Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 >>> interface - issue with the LOGICAL kind >>> This time is OK for me. I'll look for the webex email. >>> >>> I would like to note that the various options discussed are not >>> necessarily "all or nothing" propositions. An implementation could >>> use >>> the thin wrappers in a module approach to eliminate the bad Fortran >>> types problems for most of the MPI routines, but also have some >>> routines >>> implemented in a different way, such as (1) all in Fortran that is >>> callable from C, (2) all in C that is called through an interface >>> directly from Fortran, (3) as a fat wrapper in Fortran, or (4) a >>> completely replicated routine for the Fortran implementation. There >>> is >>> no reason that all of the routines have to be the same method - in >>> fact >>> probably good arguments against that in some cases. We just need to >>> have >>> the rules such that the tools have some known name to intercept. >>> Along >>> the lines of "If implementation method X is chosen for routine >>> MPI_xxx, >>> then these are the linker name requirements:.....". >>> >>> Cheers, >>> Bill >>> >>> >>> >>> On 3/23/13 2:11 AM, Rolf Rabenseifner wrote: >>>> Dear Jeff, Craig, Bill, Hubert, Martin, and Tobias, >>>> >>>> I expect that this is the total group that discusses the >>>> Fortran LOGICAL etc. problem. >>>> We learnt that the solutions also touch the PMPI concept. >>>> There was a telecon between Craig, Jeff and Bill with the proposal >>>> at the end of this email. >>>> I like to understand this proposal and therefore I asked Jeff >>>> for explanations. I would like to open this for the whole group. >>>> >>>>> I have meetings at 9am and 1pm is eastern on Monday. I can talk >>>>> any >>>>> other time. >>>>> Craig prob can't attend because he's 3 hours earlier, but that's >>>>> prob ok. >>>> >>>> Monday March 25, >>>> - 4 PM Central European Time CET >>>> = 11 AM Eastern Daylight Time EST/EDT >>>> = 8 AM Pacific Time >>>> >>>> I hope these relations are correct. Would this work for you? >>>> >>>> At least for Jeff and me, because I want to understand >>>> what they discussed with their proposal. >>>> >>>> Jeff, can you set up a webex? >>>> >>>> Best regards >>>> Rolf >>>> >>>> ----- Original Message ----- >>>>> From: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> >>>>> To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> >>>>> Cc: "Craig E Rasmussen" <rasmus(a)cas.uoregon.edu> >>>>> Sent: Friday, March 22, 2013 8:01:23 PM >>>>> Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 >>>>> interface - issue with the LOGICAL kind >>>>> Btw, I'm not sure how this is not the least surprise. >>>>> >>>>> We can't change the params to not be logical, yes we must still >>>>> allow >>>>> for calling to c. So the overloaded solution is the only one. >>>>> >>>>> And the new Integer param signature must have a new bind name so >>>>> as >>>>> to >>>>> did ambiguity it from the one we published in MPI3. See my >>>>> previous >>>>> mail about this. >>>>> >>>>> I have meetings at 9am and 1pm is eastern on Monday. I can talk >>>>> any >>>>> other time. >>>>> >>>>> Craig prob can't attend because he's 3 hours earlier, but that's >>>>> prob >>>>> ok. >>>>> >>>>> Sent from my phone. No type good. >>>>> >>>>> On Mar 22, 2013, at 8:51 AM, "Rolf Rabenseifner" >>>>> <rabenseifner(a)hlrs.de> wrote: >>>>> >>>>>> Jeff, >>>>>> >>>>>> can I call you by phone? >>>>>> I would like to talk to you as the binding responsible and MPI >>>>>> chair. >>>>>> >>>>>>> 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 >>>>>> ... >>>>>> This is a hard step and far away from "last surprise". >>>>>> >>>>>> I would like to learn how it came out as a result of your >>>>>> telecon, >>>>>> before I try to go the next step (e.g. email answer). >>>>>> >>>>>> Best regards >>>>>> Rolf >>>>>> >>>>>> ----- Original Message ----- >>>>>>> From: "Craig Rasmussen" <rasmus(a)cas.uoregon.edu> >>>>>>> To: "MPI-3 Fortran working group" >>>>>>> <mpi3-fortran(a)lists.mpi-forum.org> >>>>>>> Cc: "Hubert Ritzdorf" <Hubert.Ritzdorf(a)emea.nec.com>, "Martin >>>>>>> Schulz" <schulzm(a)llnl.gov> >>>>>>> Sent: Friday, March 22, 2013 4:29:36 PM >>>>>>> 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 >>>> >>> >>> -- >>> 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 >> >> -- >> 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) > > -- > 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)

1 0

Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
by Rolf Rabenseifner 25 Mar '13

25 Mar '13

We (Jeff, Bill L., Craig, Hubert, Martin, Tobias, and me (Rolf)) had a telecon today and the outcome are following options: Option 1 - #364 as it currently is, as a minimal solution for the LOGICAL problem: Pro: It is consistent between Fortran and MPI. I.e., it is the minimal solution that we must do. Con: It has a mix of BIND(C) and non-BIND(C) routine groups which is ugly for the future. Remark: non-BIND(C) will stay there because the callbacks need non-BIND(C) in the moment and this cannot be changed in the future by nice new concepts from the Fortran language standardization. Option 2 - #364 plus changing MPI-3.0 page 605 lines 24-30 and page 605 line 47 - page 606 line 6 by also using non-BIND(C), but other linker names: MPI_Send_f08d (in mpi_f08 with TS29113 quality, i.e., buffers are done with C-descriptors and not with void* pointers.) MPI_Send_fd (in the mpi module or mpif.h if MPI_SUBARRAYS_SUPPORTED=.TRUE. is also done there, i.e., with the descriptors.) Pro: It is consistent between Fortran and MPI and it is consistent within MPI, i.e., all functionality is done with non-BIND(C) routines. BIND(C) can be still used internally to call MPI_Send_cdesc and MPI_Isend_cdesc. To be fair, implementatiosn will be based mainly on this TS 29113 feature, but only internally. Con: No BIND(C) on the official MPI interface. We urged Fortran to put some features into TS 29113, but we will not use these features, because they are not needed on this internal interface. Option 3: - Option 2 plus the following rule: - The Fortran PMPI interface can be substituted by a wrapper based sulution that internally calls the full MPI C interface. - In this case, the Fortran interface should be hidden to the tools. - For the buffer routines with the new cdesc descriptor, new interfaces are added for the tools people, e.g., MPI_Send_cdesc and MPI_Isend_cdesc. Pro: I'm not sure whether there is a real pro? Bill, can you add the pros, it is your option. Con: An additional new interface for the tools folk. It is not backward compatible for users who really intercept the Fortran MPI interface. My favorite in the moment, i.e. at the starting of the pro-con-discussion: Option 2. Best regards Rolf ----- Original Message ----- > From: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> > To: longb(a)cray.com > Cc: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com>, "Craig E Rasmussen" <rasmus(a)cas.uoregon.edu>, "Hubert Ritzdorf" > <Hubert.Ritzdorf(a)emea.nec.com>, "Martin Schulz" <schulzm(a)llnl.gov>, "Tobias Burnus" <burnus(a)net-b.de> > Sent: Monday, March 25, 2013 12:21:39 PM > Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind > Yes, this freedom (1)-(4) in Bill's email is important. > > In our discussion, we forgot one additional reason why we defined > it as it is written in MPI-3.0 Section 17.1.5, page 605: > > - It should be possible to implement the interfaces with > these non-standard Fortran-void-* directives, > and later on, > to substitute this implementation by new ones > that are based on TS 29113. > - When doing this substitution, it should be save for > applications when the application is not re-compiled. > - More than that, it should be possible to combine older > .o files with newly TS 29113 based .o files. > - For this, we decided, that the implementation has to switch > from non-BIND(C) to BIND(C) at least in the MPI_ISEND > routine group when switching to MPI_SUBARRAYS_SUPPORTED==.TRUE. > - The real trick is that the linker name must be changed. > - This all is valid for both, the new mpi_f08 module, > and the old mpi module. > > A second issue in our discussion is always, which changes > we want to do to the mpi_f08 MPI-3.0 user interface. > I want to remember that this user interface is defined > according following rules. > If a user modifies his source to use everywhere mpi_f08, > he/she has to modify: > - He/she has to substitute the "include 'mpif.h'" or "use mpi" > statements by "use mpi_f08". > - He/she has to modify all handle and status declarations. > - In the executable statements, he/she has to substitute all > status(MPI_TAG), status(MPI_SOURCE), status(MPI_ERROR) > accesses into > status%MPI_TAG, status%MPI_SOURCE, status%MPI_ERROR. > - Callback routines need more effort due to the > abstract interface definitions. > This is touched by ticket #364, i.e., > the MPI-3.0 BIND(C) of callbacks had to be removed. > - Changes in the interfaces are only > -- all handles use the new handle types > and in > -- MPI_User_function, > -- MPI_Datarep_conversion_function, > the buffers are done with TYPE(C_TR), VALUE. > > This should be all. > All other user correct code should directly compile with the new > mpi_f08 module. > We should not change these things, except the necessary > errata in #364. > > I see that we have some freedom only in the area, > what we do internally (together with linker names) and with PMPI, > but not in the user interface. > If we add additional user interfaces (e.g. overloading the LOGICAL > with INTEGER arguments) > we would only make it more complicate. > > Best regards > Rolf > > > ----- Original Message ----- > > From: "Bill Long" <longb(a)cray.com> > > To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> > > Cc: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com>, "Craig E > > Rasmussen" <rasmus(a)cas.uoregon.edu>, "Hubert Ritzdorf" > > <Hubert.Ritzdorf(a)emea.nec.com>, "Martin Schulz" <schulzm(a)llnl.gov>, > > "Tobias Burnus" <burnus(a)net-b.de> > > Sent: Sunday, March 24, 2013 5:59:38 PM > > Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 > > interface - issue with the LOGICAL kind > > This time is OK for me. I'll look for the webex email. > > > > I would like to note that the various options discussed are not > > necessarily "all or nothing" propositions. An implementation could > > use > > the thin wrappers in a module approach to eliminate the bad Fortran > > types problems for most of the MPI routines, but also have some > > routines > > implemented in a different way, such as (1) all in Fortran that is > > callable from C, (2) all in C that is called through an interface > > directly from Fortran, (3) as a fat wrapper in Fortran, or (4) a > > completely replicated routine for the Fortran implementation. There > > is > > no reason that all of the routines have to be the same method - in > > fact > > probably good arguments against that in some cases. We just need to > > have > > the rules such that the tools have some known name to intercept. > > Along > > the lines of "If implementation method X is chosen for routine > > MPI_xxx, > > then these are the linker name requirements:.....". > > > > Cheers, > > Bill > > > > > > > > On 3/23/13 2:11 AM, Rolf Rabenseifner wrote: > > > Dear Jeff, Craig, Bill, Hubert, Martin, and Tobias, > > > > > > I expect that this is the total group that discusses the > > > Fortran LOGICAL etc. problem. > > > We learnt that the solutions also touch the PMPI concept. > > > There was a telecon between Craig, Jeff and Bill with the proposal > > > at the end of this email. > > > I like to understand this proposal and therefore I asked Jeff > > > for explanations. I would like to open this for the whole group. > > > > > >> I have meetings at 9am and 1pm is eastern on Monday. I can talk > > >> any > > >> other time. > > >> Craig prob can't attend because he's 3 hours earlier, but that's > > >> prob ok. > > > > > > Monday March 25, > > > - 4 PM Central European Time CET > > > = 11 AM Eastern Daylight Time EST/EDT > > > = 8 AM Pacific Time > > > > > > I hope these relations are correct. Would this work for you? > > > > > > At least for Jeff and me, because I want to understand > > > what they discussed with their proposal. > > > > > > Jeff, can you set up a webex? > > > > > > Best regards > > > Rolf > > > > > > ----- Original Message ----- > > >> From: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> > > >> To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> > > >> Cc: "Craig E Rasmussen" <rasmus(a)cas.uoregon.edu> > > >> Sent: Friday, March 22, 2013 8:01:23 PM > > >> Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 > > >> interface - issue with the LOGICAL kind > > >> Btw, I'm not sure how this is not the least surprise. > > >> > > >> We can't change the params to not be logical, yes we must still > > >> allow > > >> for calling to c. So the overloaded solution is the only one. > > >> > > >> And the new Integer param signature must have a new bind name so > > >> as > > >> to > > >> did ambiguity it from the one we published in MPI3. See my > > >> previous > > >> mail about this. > > >> > > >> I have meetings at 9am and 1pm is eastern on Monday. I can talk > > >> any > > >> other time. > > >> > > >> Craig prob can't attend because he's 3 hours earlier, but that's > > >> prob > > >> ok. > > >> > > >> Sent from my phone. No type good. > > >> > > >> On Mar 22, 2013, at 8:51 AM, "Rolf Rabenseifner" > > >> <rabenseifner(a)hlrs.de> wrote: > > >> > > >>> Jeff, > > >>> > > >>> can I call you by phone? > > >>> I would like to talk to you as the binding responsible and MPI > > >>> chair. > > >>> > > >>>> 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 > > >>> ... > > >>> This is a hard step and far away from "last surprise". > > >>> > > >>> I would like to learn how it came out as a result of your > > >>> telecon, > > >>> before I try to go the next step (e.g. email answer). > > >>> > > >>> Best regards > > >>> Rolf > > >>> > > >>> ----- Original Message ----- > > >>>> From: "Craig Rasmussen" <rasmus(a)cas.uoregon.edu> > > >>>> To: "MPI-3 Fortran working group" > > >>>> <mpi3-fortran(a)lists.mpi-forum.org> > > >>>> Cc: "Hubert Ritzdorf" <Hubert.Ritzdorf(a)emea.nec.com>, "Martin > > >>>> Schulz" <schulzm(a)llnl.gov> > > >>>> Sent: Friday, March 22, 2013 4:29:36 PM > > >>>> 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 > > > > > > > -- > > 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 > > -- > 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) -- 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)

1 0

Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
by Jeff Squyres (jsquyres) 22 Mar '13

22 Mar '13

See below. Sent from my phone. No type good. On Mar 22, 2013, at 11:08 AM, "Hubert Ritzdorf" <Hubert.Ritzdorf(a)emea.nec.com<mailto:[email protected]>> wrote: 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. We did something illegal in MPI 3, so the bw Compat requirements with interfaces containing logical params are greatly weakened. How is goal 4 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. I think Craig was spelling out the intent, not what we'll actually say on the text. I.E., implementations like yours and mine will just provide a separate PMPI interface for mpi_f08 and then not be bound by the "must call the c symbol" restriction. The "must call c symbol" restriction is only for implementations like bills that will have fortran only wrappers that call c (e.g., and may be inlined and therefore not interceptable). Hubert ________________________________ From: Craig Rasmussen [rasmus(a)cas.uoregon.edu<mailto:[email protected]>] 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. _______________________________________________ mpi3-fortran mailing list mpi3-fortran(a)lists.mpi-forum.org<mailto:[email protected]> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran

1 0