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" <[email protected]> To: [email protected] Cc: "Jeff Squyres (jsquyres)" <[email protected]>, "Craig E Rasmussen" <[email protected]>, "Hubert Ritzdorf" <[email protected]>, "Martin Schulz" <[email protected]>, "Tobias Burnus" <[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" <[email protected]> To: "Rolf Rabenseifner" <[email protected]> Cc: "Jeff Squyres (jsquyres)" <[email protected]>, "Craig E Rasmussen" <[email protected]>, "Hubert Ritzdorf" <[email protected]>, "Martin Schulz" <[email protected]>, "Tobias Burnus" <[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)" <[email protected]> To: "Rolf Rabenseifner" <[email protected]> Cc: "Craig E Rasmussen" <[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" <[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" <[email protected]> To: "MPI-3 Fortran working group" <[email protected]> Cc: "Hubert Ritzdorf" <[email protected]>, "Martin Schulz" <[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 [email protected]
-- Bill Long [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 [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 Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307)
-- Dr. Rolf Rabenseifner . . . . . . . . . .. email [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 Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307)