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

Re: [MPI3 Fortran] New Fortran proposal w.r.t. BIND(C)/logical/etc.
by Jeff Squyres (jsquyres) 24 Apr '13

24 Apr '13

On Apr 23, 2013, at 2:31 PM, Bill Long <longb(a)cray.com> wrote: >> There would be a huge backlash if Fortran symbols were not interceptable. > > That is exactly the opposite of what I've heard from the tools people. My impression is that they would be happy to have to only look for the C names. Why would there be backlash in this case? Here's a backlash from an implementor :-). I don't (and can't) always call the back-end public C symbols from Fortran. You're imposing a specific implementation scheme. We can't allow that in the MPI spec. One of the reasons I really, really dislike Rolf's proposal text is that it mandates one of three implementation choices. Not only does the MPI standard specifically stay away from all implementation issues in normative text, none of the 3 implementation choices that Rolf outlined are how Open MPI is implemented. -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [MPI3 Fortran] New Fortran proposal w.r.t. BIND(C)/logical/etc.
by Craig Rasmussen 23 Apr '13

23 Apr '13

On Apr 23, 2013, at 11:31 AM, Bill Long wrote: > > > On 4/23/13 12:05 PM, Craig Rasmussen wrote: >> On Apr 23, 2013, at 5:17 AM, Bill Long wrote: >> >>> >>> >>> On 4/22/13 3:03 PM, Jeff Squyres (jsquyres) wrote: >>>> Craig and I would like to propose a different MPI-3 errata solution for the current MPI Fortran existential crisis (keep in mind: there may be a different solution for MPI-4). >>>> >>>> If the group likes these idea, we will draw up an actual proposal. Here are the main points: >>>> >>>> 1. Remove BIND(C) from all prototypes in the spec. Have a short Advice to Implementers saying that using BIND(C) is not prohibited. If used, the effects of BIND(C) must *not* be visible to either the MPI application or PMPI-based tools (e.g., the linker symbol must be the same as if BIND(C) was not specified). >>>> >>> >>> I agree with not having BIND(C) in the prototypes in the spec. However, the second sentence effectively prohibits implementation of any of the worker routines in Fortran, which is quite unacceptable. >> >> I'm not sure what you mean by worker routines (do you mean wrapper routines)? Because as I see the proposal, it effectively requires that the WRAPPER routines be in Fortran. The worker/implementation routines can be in either Fortran or C, just as in pre MPI-3 days. >> > > For example, the routines that convert between the C and Fortran formats of the STATUS type. I makes no sense whatever to write these in C since C does not know about Fortran default types. Instead, you write one version, in Fortran, with BIND(C) that specifies the correct C name so that C functions could call it if they wanted. Are you talking about MPI_Status_f2c (or others like MPI_Comm_c2f)? I don't know if these functions have the same requirements regarding PMPI. Someone else should comment. > > >> The requirement that the effects of BIND(C) must not be visible is meant to require that argument passing and linker symbols must be as if BIND(C) was not used. >> > > Well, obviously not for the example above. You WANT the C calling conventions. > >>> >>>> 2. MPI-3 says that all mpi_f08 subroutines must use INTERFACE with the official MPI API name suffixed with _f08 when MPI_SUBARRAYS_SUPPORTED equals .FALSE.. Our proposal changes this such that the Fortran subroutine name *always* has the _f08 suffix (this is a direct consequence of #1). For example: >>>> >>>> INTERFACE MPI_SEND >>>> SUBROUTINE MPI_Send_f08(...args...) >>>> END INTERFACE MPI_SEND >>>> >>> >>> For implementations that put the Fortran wrappers in the module (where they logically belong), this requirement is pointless. It just adds three unnecessary lines to the module. It is missing the point of trying to modernize the interface to take advantage of the C interoperability features in Fortran. >> >> Again, the above example is an example. If an implementation can make it appear as if this interface body is in effect, then the vendor is free to implement the standard any way it wants. For example, >> >> ---------------------- >> module mpi_f08 >> >> interface MPI_Recv >> module procedure MPI_Recv_f08 >> end interface MPI_Recv >> >> contains >> >> subroutine MPI_Recv_f08(args...) bind(C, name="mpi_recv_f08_") > > No, you do not want this BIND(C). You get the problems with LOGICAL back again. (Not for this particular routine, but for others.) Just name the subroutine MPI_Recv in the module and get rid of the interface block. This is a thin wrapper and the Fortran name (mangled or otherwise) will likely not even show up in the executable. The actual call will to the C library routine, and that one is the only one the tools people see. But the Fortran name mangling and the potential lack of the symbol appearing altogether is the crux of the problem we are trying to solve. I have no problem with what you want to do, I just think we have to wait until MPI-4 to try and do it. > > >> end subroutine >> >> end module >> ---------------------- >> >> With gfortran, this will produce the same symbol name, e.g. "_mpi_recv_f08_" for tools (but would fail for argument passing reasons when DIMENSION(..) is used). Otherwise when the implementation is included with the module the symbol name is mangled, e.g. "___mpi_f08_MOD_mpi_recv_f08". Once you remove BIND(C) from the prototypes in the spec, you can't place the implementation within a module because we can't require tools to support mangled symbols even more heinous that they must do at the moment. >> >>> >>>> PROS >>>> >>>> 1. Removing BIND(C) solves LOGICAL/BIND(C) issues and string/BIND(C) issues. >>>> 2. This is a small enough change to be an MPI-3 errata. >>>> 3. Mandating the _f08 suffix for all cases removes corner cases and simplifies the standard. >>>> >>>> NEUTRAL >>>> >>>> 1. Tools will use the same name mangling schemes they have been using for years. We have not made the issue *better* (though we have removed the need to support the BIND(C, name=) symbol from the MPI symbol namespace), but we have also not made it *worse* (e.g., a proliferation of symbol names introduced into the MPI standard). >>>> >>>> CONS >>>> >>>> 1. There may be advantages in adding new functionality related to linker symbols / PMPI. However, this lies outside the scope of an errata; re-exmaining the whole solution/architecture can take place in the scope of MPI-4. >>>> >>>> Sidenotes / implications: >>>> >>>> 1. Chapter 14 explicitly states that Fortran symbols must be interceptable (MPI-3 p555). This means the MPI-3 "use mpi_f08" implementation cannot be in the CONTAIN section of the mpi_f08 module. >>>> >>> >>> If that's the case, then this needs to be fixed. It prevents the use of interoperability the way it was intended. >> >> An implementation is free to use interoperability with the implementation. For example, the Fortran wrapper can turn around and immediately call the regular PMPI C implementation through a BIND(C) interface and a little argument marshaling to match the C interface. Dropping BIND(C) from the interface specification means that a normal Fortran user can implement MPI_Send (for example) in a Fortran file which calls PMPI_Send, then links his application with the existing MPI library and have her implementation of MPI_Send be called. This cannot happen unless the linker symbols are the same. >> >> There would be a huge backlash if Fortran symbols were not interceptable. >> > > That is exactly the opposite of what I've heard from the tools people. My impression is that they would be happy to have to only look for the C names. Why would there be backlash in this case? Yea, the "C tools" people would love the Fortran interfaces to go away and just have to support the C bindings. However, the original MPI standard was written so that ordinary Fortran users could intercept their own calls in Fortran. It is this (perhaps) not very sophisticated user that we can't suddenly drop from the standard in an errata. > > >>> >>>> 2. We donï¿½t think that mandating extra MPI_<foo>_cdesc() symbols are a good idea; they impose a specific implementation model that is not universal. >>>> >>> >>> These names are only relevant for a modern implementation, and give the tools people standardized names to intercept. If you opt for a last-century scheme, then these new names are not relevant to your implementation. These names are for the tools people (which in the end are the only point of the whole discussion from the beginning.) >> >> We agree here. The MPI standard should be changed to allow a vendor to implement the standard in the way you suggest. I just don't see how this can be done in an errata. Especially considering the interceptability argument made above (which absolutely can't be removed in an errata). Thus to do this we have to wait until MPI-4. >> >> One further point which I think has been missing from the argument: This proposal (and earlier MPI standards) allows PMPI tools to be implemented in Fortran in a portable way. For example, suppose I implement MPI_Send in a Fortran file. Then this file can be compiled and linked with any MPI version and it will still work. >> > > If you implement MPI_Send (or any other MPI worker routine, such as the status conversions) in Fortran, this is easy since you specify the interface with BIND(C) so that C functions can have equal access. This seems straightforward - the C interop feature was specifically designed to allow C functions to call Fortran-written library routines. > > >> I just don't see how user portability can be maintained with Rolf's A, B, C combinatorial proposal (because every vendor may have a different combination). I could be wrong. >> > > All that should be required for portability of source code is that the user writes calls according to the interface rules . I don't see how any of the implementation methods violate that requirement. Because unfortunately, the current MPI standard not only has a requirement on the interface, but also on the linker symbols produced so that linker magic can be used to redirect/intercept MPI function calls. -craig

1 0

Re: [MPI3 Fortran] New Fortran proposal w.r.t. BIND(C)/logical/etc.
by Bill Long 23 Apr '13

23 Apr '13

On 4/23/13 12:05 PM, Craig Rasmussen wrote: > On Apr 23, 2013, at 5:17 AM, Bill Long wrote: > >> >> >> On 4/22/13 3:03 PM, Jeff Squyres (jsquyres) wrote: >>> Craig and I would like to propose a different MPI-3 errata solution for the current MPI Fortran existential crisis (keep in mind: there may be a different solution for MPI-4). >>> >>> If the group likes these idea, we will draw up an actual proposal. Here are the main points: >>> >>> 1. Remove BIND(C) from all prototypes in the spec. Have a short Advice to Implementers saying that using BIND(C) is not prohibited. If used, the effects of BIND(C) must *not* be visible to either the MPI application or PMPI-based tools (e.g., the linker symbol must be the same as if BIND(C) was not specified). >>> >> >> I agree with not having BIND(C) in the prototypes in the spec. However, the second sentence effectively prohibits implementation of any of the worker routines in Fortran, which is quite unacceptable. > > I'm not sure what you mean by worker routines (do you mean wrapper routines)? Because as I see the proposal, it effectively requires that the WRAPPER routines be in Fortran. The worker/implementation routines can be in either Fortran or C, just as in pre MPI-3 days. > For example, the routines that convert between the C and Fortran formats of the STATUS type. I makes no sense whatever to write these in C since C does not know about Fortran default types. Instead, you write one version, in Fortran, with BIND(C) that specifies the correct C name so that C functions could call it if they wanted. > The requirement that the effects of BIND(C) must not be visible is meant to require that argument passing and linker symbols must be as if BIND(C) was not used. > Well, obviously not for the example above. You WANT the C calling conventions. >> >>> 2. MPI-3 says that all mpi_f08 subroutines must use INTERFACE with the official MPI API name suffixed with _f08 when MPI_SUBARRAYS_SUPPORTED equals .FALSE.. Our proposal changes this such that the Fortran subroutine name *always* has the _f08 suffix (this is a direct consequence of #1). For example: >>> >>> INTERFACE MPI_SEND >>> SUBROUTINE MPI_Send_f08(...args...) >>> END INTERFACE MPI_SEND >>> >> >> For implementations that put the Fortran wrappers in the module (where they logically belong), this requirement is pointless. It just adds three unnecessary lines to the module. It is missing the point of trying to modernize the interface to take advantage of the C interoperability features in Fortran. > > Again, the above example is an example. If an implementation can make it appear as if this interface body is in effect, then the vendor is free to implement the standard any way it wants. For example, > > ---------------------- > module mpi_f08 > > interface MPI_Recv > module procedure MPI_Recv_f08 > end interface MPI_Recv > > contains > > subroutine MPI_Recv_f08(args...) bind(C, name="mpi_recv_f08_") No, you do not want this BIND(C). You get the problems with LOGICAL back again. (Not for this particular routine, but for others.) Just name the subroutine MPI_Recv in the module and get rid of the interface block. This is a thin wrapper and the Fortran name (mangled or otherwise) will likely not even show up in the executable. The actual call will to the C library routine, and that one is the only one the tools people see. > end subroutine > > end module > ---------------------- > > With gfortran, this will produce the same symbol name, e.g. "_mpi_recv_f08_" for tools (but would fail for argument passing reasons when DIMENSION(..) is used). Otherwise when the implementation is included with the module the symbol name is mangled, e.g. "___mpi_f08_MOD_mpi_recv_f08". Once you remove BIND(C) from the prototypes in the spec, you can't place the implementation within a module because we can't require tools to support mangled symbols even more heinous that they must do at the moment. > >> >>> PROS >>> >>> 1. Removing BIND(C) solves LOGICAL/BIND(C) issues and string/BIND(C) issues. >>> 2. This is a small enough change to be an MPI-3 errata. >>> 3. Mandating the _f08 suffix for all cases removes corner cases and simplifies the standard. >>> >>> NEUTRAL >>> >>> 1. Tools will use the same name mangling schemes they have been using for years. We have not made the issue *better* (though we have removed the need to support the BIND(C, name=) symbol from the MPI symbol namespace), but we have also not made it *worse* (e.g., a proliferation of symbol names introduced into the MPI standard). >>> >>> CONS >>> >>> 1. There may be advantages in adding new functionality related to linker symbols / PMPI. However, this lies outside the scope of an errata; re-exmaining the whole solution/architecture can take place in the scope of MPI-4. >>> >>> Sidenotes / implications: >>> >>> 1. Chapter 14 explicitly states that Fortran symbols must be interceptable (MPI-3 p555). This means the MPI-3 "use mpi_f08" implementation cannot be in the CONTAIN section of the mpi_f08 module. >>> >> >> If that's the case, then this needs to be fixed. It prevents the use of interoperability the way it was intended. > > An implementation is free to use interoperability with the implementation. For example, the Fortran wrapper can turn around and immediately call the regular PMPI C implementation through a BIND(C) interface and a little argument marshaling to match the C interface. Dropping BIND(C) from the interface specification means that a normal Fortran user can implement MPI_Send (for example) in a Fortran file which calls PMPI_Send, then links his application with the existing MPI library and have her implementation of MPI_Send be called. This cannot happen unless the linker symbols are the same. > > There would be a huge backlash if Fortran symbols were not interceptable. > That is exactly the opposite of what I've heard from the tools people. My impression is that they would be happy to have to only look for the C names. Why would there be backlash in this case? >> >>> 2. We donï¿½t think that mandating extra MPI_<foo>_cdesc() symbols are a good idea; they impose a specific implementation model that is not universal. >>> >> >> These names are only relevant for a modern implementation, and give the tools people standardized names to intercept. If you opt for a last-century scheme, then these new names are not relevant to your implementation. These names are for the tools people (which in the end are the only point of the whole discussion from the beginning.) > > We agree here. The MPI standard should be changed to allow a vendor to implement the standard in the way you suggest. I just don't see how this can be done in an errata. Especially considering the interceptability argument made above (which absolutely can't be removed in an errata). Thus to do this we have to wait until MPI-4. > > One further point which I think has been missing from the argument: This proposal (and earlier MPI standards) allows PMPI tools to be implemented in Fortran in a portable way. For example, suppose I implement MPI_Send in a Fortran file. Then this file can be compiled and linked with any MPI version and it will still work. > If you implement MPI_Send (or any other MPI worker routine, such as the status conversions) in Fortran, this is easy since you specify the interface with BIND(C) so that C functions can have equal access. This seems straightforward - the C interop feature was specifically designed to allow C functions to call Fortran-written library routines. > I just don't see how user portability can be maintained with Rolf's A, B, C combinatorial proposal (because every vendor may have a different combination). I could be wrong. > All that should be required for portability of source code is that the user writes calls according to the interface rules . I don't see how any of the implementation methods violate that requirement. Cheers, Bill > -craig > > -- 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] New Fortran proposal w.r.t. BIND(C)/logical/etc.
by Craig Rasmussen 23 Apr '13

23 Apr '13

On Apr 23, 2013, at 5:17 AM, Bill Long wrote: > > > On 4/22/13 3:03 PM, Jeff Squyres (jsquyres) wrote: >> Craig and I would like to propose a different MPI-3 errata solution for the current MPI Fortran existential crisis (keep in mind: there may be a different solution for MPI-4). >> >> If the group likes these idea, we will draw up an actual proposal. Here are the main points: >> >> 1. Remove BIND(C) from all prototypes in the spec. Have a short Advice to Implementers saying that using BIND(C) is not prohibited. If used, the effects of BIND(C) must *not* be visible to either the MPI application or PMPI-based tools (e.g., the linker symbol must be the same as if BIND(C) was not specified). >> > > I agree with not having BIND(C) in the prototypes in the spec. However, the second sentence effectively prohibits implementation of any of the worker routines in Fortran, which is quite unacceptable. I'm not sure what you mean by worker routines (do you mean wrapper routines)? Because as I see the proposal, it effectively requires that the WRAPPER routines be in Fortran. The worker/implementation routines can be in either Fortran or C, just as in pre MPI-3 days. The requirement that the effects of BIND(C) must not be visible is meant to require that argument passing and linker symbols must be as if BIND(C) was not used. > >> 2. MPI-3 says that all mpi_f08 subroutines must use INTERFACE with the official MPI API name suffixed with _f08 when MPI_SUBARRAYS_SUPPORTED equals .FALSE.. Our proposal changes this such that the Fortran subroutine name *always* has the _f08 suffix (this is a direct consequence of #1). For example: >> >> INTERFACE MPI_SEND >> SUBROUTINE MPI_Send_f08(...args...) >> END INTERFACE MPI_SEND >> > > For implementations that put the Fortran wrappers in the module (where they logically belong), this requirement is pointless. It just adds three unnecessary lines to the module. It is missing the point of trying to modernize the interface to take advantage of the C interoperability features in Fortran. Again, the above example is an example. If an implementation can make it appear as if this interface body is in effect, then the vendor is free to implement the standard any way it wants. For example, ---------------------- module mpi_f08 interface MPI_Recv module procedure MPI_Recv_f08 end interface MPI_Recv contains subroutine MPI_Recv_f08(args...) bind(C, name="mpi_recv_f08_") end subroutine end module ---------------------- With gfortran, this will produce the same symbol name, e.g. "_mpi_recv_f08_" for tools (but would fail for argument passing reasons when DIMENSION(..) is used). Otherwise when the implementation is included with the module the symbol name is mangled, e.g. "___mpi_f08_MOD_mpi_recv_f08". Once you remove BIND(C) from the prototypes in the spec, you can't place the implementation within a module because we can't require tools to support mangled symbols even more heinous that they must do at the moment. > >> PROS >> >> 1. Removing BIND(C) solves LOGICAL/BIND(C) issues and string/BIND(C) issues. >> 2. This is a small enough change to be an MPI-3 errata. >> 3. Mandating the _f08 suffix for all cases removes corner cases and simplifies the standard. >> >> NEUTRAL >> >> 1. Tools will use the same name mangling schemes they have been using for years. We have not made the issue *better* (though we have removed the need to support the BIND(C, name=) symbol from the MPI symbol namespace), but we have also not made it *worse* (e.g., a proliferation of symbol names introduced into the MPI standard). >> >> CONS >> >> 1. There may be advantages in adding new functionality related to linker symbols / PMPI. However, this lies outside the scope of an errata; re-exmaining the whole solution/architecture can take place in the scope of MPI-4. >> >> Sidenotes / implications: >> >> 1. Chapter 14 explicitly states that Fortran symbols must be interceptable (MPI-3 p555). This means the MPI-3 "use mpi_f08" implementation cannot be in the CONTAIN section of the mpi_f08 module. >> > > If that's the case, then this needs to be fixed. It prevents the use of interoperability the way it was intended. An implementation is free to use interoperability with the implementation. For example, the Fortran wrapper can turn around and immediately call the regular PMPI C implementation through a BIND(C) interface and a little argument marshaling to match the C interface. Dropping BIND(C) from the interface specification means that a normal Fortran user can implement MPI_Send (for example) in a Fortran file which calls PMPI_Send, then links his application with the existing MPI library and have her implementation of MPI_Send be called. This cannot happen unless the linker symbols are the same. There would be a huge backlash if Fortran symbols were not interceptable. > >> 2. We donï¿½t think that mandating extra MPI_<foo>_cdesc() symbols are a good idea; they impose a specific implementation model that is not universal. >> > > These names are only relevant for a modern implementation, and give the tools people standardized names to intercept. If you opt for a last-century scheme, then these new names are not relevant to your implementation. These names are for the tools people (which in the end are the only point of the whole discussion from the beginning.) We agree here. The MPI standard should be changed to allow a vendor to implement the standard in the way you suggest. I just don't see how this can be done in an errata. Especially considering the interceptability argument made above (which absolutely can't be removed in an errata). Thus to do this we have to wait until MPI-4. One further point which I think has been missing from the argument: This proposal (and earlier MPI standards) allows PMPI tools to be implemented in Fortran in a portable way. For example, suppose I implement MPI_Send in a Fortran file. Then this file can be compiled and linked with any MPI version and it will still work. I just don't see how user portability can be maintained with Rolf's A, B, C combinatorial proposal (because every vendor may have a different combination). I could be wrong. -craig

1 0

Re: [MPI3 Fortran] New Fortran proposal w.r.t. BIND(C)/logical/etc.
by Jeff Squyres (jsquyres) 23 Apr '13

23 Apr '13

On Apr 22, 2013, at 4:03 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > Craig and I would like to propose a different MPI-3 errata solution for the current MPI Fortran existential crisis (keep in mind: there may be a different solution for MPI-4). > > If the group likes these idea, we will draw up an actual proposal. Here are the main points: > > 1. Remove BIND(C) from all prototypes in the spec. Have a short Advice to Implementers saying that using BIND(C) is not prohibited. If used, the effects of BIND(C) must *not* be visible to either the MPI application or PMPI-based tools (e.g., the linker symbol must be the same as if BIND(C) was not specified). I talked to Rolf on the phone for a long time this morning. Among the many topics we discussed, he convinced me that the last 2 sentences from point #1 of our proposal aree incorrect -- it is not possible to make the effects of BIND(C) invisible. Hence, we drop this from our proposal, and make point #1 be: 1. Remove BIND(C) from all prototypes in the spec. -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [MPI3 Fortran] New Fortran proposal w.r.t. BIND(C)/logical/etc.
by Rolf Rabenseifner 23 Apr '13

23 Apr '13

We cannot do such changes for mpif.h and the mpi module. We never said anything in MPI1 or MPI-2 about the new mpi_f08 in the old versions of MPI. My last proposal was based on these facts. Rolf ----- Original Message ----- > From: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> > To: "<longb(a)cray.com>" <longb(a)cray.com>, "MPI-3 Fortran working group" <mpi3-fortran(a)lists.mpi-forum.org> > Sent: Tuesday, April 23, 2013 2:40:08 PM > Subject: Re: [MPI3 Fortran] New Fortran proposal w.r.t. BIND(C)/logical/etc. > On Apr 23, 2013, at 8:17 AM, Bill Long <longb(a)cray.com> wrote: > > > Overall, I see this proposal as a big step backwards, and am not in > > favor. Sorry. > > > That was to be expected, sorry. > > The lynchpin is that ever since MPI-1, MPI has explicitly stated that > the Fortran symbols must be interceptable (that is the driving force > behind much of the logic in this proposal). We cannot change that in > an errata. > > We can (and should) change this in MPI-4, so that advances like > CONTAIN blocks are possible. > > *** But we absolutely cannot make such major changes in an errata. > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran -- 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] New Fortran proposal w.r.t. BIND(C)/logical/etc.
by Jeff Squyres (jsquyres) 23 Apr '13

23 Apr '13

On Apr 23, 2013, at 8:17 AM, Bill Long <longb(a)cray.com> wrote: > Overall, I see this proposal as a big step backwards, and am not in favor. Sorry. That was to be expected, sorry. The lynchpin is that ever since MPI-1, MPI has explicitly stated that the Fortran symbols must be interceptable (that is the driving force behind much of the logic in this proposal). We cannot change that in an errata. We can (and should) change this in MPI-4, so that advances like CONTAIN blocks are possible. *** But we absolutely cannot make such major changes in an errata. -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [MPI3 Fortran] New Fortran proposal w.r.t. BIND(C)/logical/etc.
by Bill Long 23 Apr '13

23 Apr '13

On 4/22/13 3:03 PM, Jeff Squyres (jsquyres) wrote: > Craig and I would like to propose a different MPI-3 errata solution for the current MPI Fortran existential crisis (keep in mind: there may be a different solution for MPI-4). > > If the group likes these idea, we will draw up an actual proposal. Here are the main points: > > 1. Remove BIND(C) from all prototypes in the spec. Have a short Advice to Implementers saying that using BIND(C) is not prohibited. If used, the effects of BIND(C) must *not* be visible to either the MPI application or PMPI-based tools (e.g., the linker symbol must be the same as if BIND(C) was not specified). > I agree with not having BIND(C) in the prototypes in the spec. However, the second sentence effectively prohibits implementation of any of the worker routines in Fortran, which is quite unacceptable. > 2. MPI-3 says that all mpi_f08 subroutines must use INTERFACE with the official MPI API name suffixed with _f08 when MPI_SUBARRAYS_SUPPORTED equals .FALSE.. Our proposal changes this such that the Fortran subroutine name *always* has the _f08 suffix (this is a direct consequence of #1). For example: > > INTERFACE MPI_SEND > SUBROUTINE MPI_Send_f08(...args...) > END INTERFACE MPI_SEND > For implementations that put the Fortran wrappers in the module (where they logically belong), this requirement is pointless. It just adds three unnecessary lines to the module. It is missing the point of trying to modernize the interface to take advantage of the C interoperability features in Fortran. > PROS > > 1. Removing BIND(C) solves LOGICAL/BIND(C) issues and string/BIND(C) issues. > 2. This is a small enough change to be an MPI-3 errata. > 3. Mandating the _f08 suffix for all cases removes corner cases and simplifies the standard. > > NEUTRAL > > 1. Tools will use the same name mangling schemes they have been using for years. We have not made the issue *better* (though we have removed the need to support the BIND(C, name=) symbol from the MPI symbol namespace), but we have also not made it *worse* (e.g., a proliferation of symbol names introduced into the MPI standard). > > CONS > > 1. There may be advantages in adding new functionality related to linker symbols / PMPI. However, this lies outside the scope of an errata; re-exmaining the whole solution/architecture can take place in the scope of MPI-4. > > Sidenotes / implications: > > 1. Chapter 14 explicitly states that Fortran symbols must be interceptable (MPI-3 p555). This means the MPI-3 "use mpi_f08" implementation cannot be in the CONTAIN section of the mpi_f08 module. > If that's the case, then this needs to be fixed. It prevents the use of interoperability the way it was intended. > 2. We donï¿½t think that mandating extra MPI_<foo>_cdesc() symbols are a good idea; they impose a specific implementation model that is not universal. > These names are only relevant for a modern implementation, and give the tools people standardized names to intercept. If you opt for a last-century scheme, then these new names are not relevant to your implementation. These names are for the tools people (which in the end are the only point of the whole discussion from the beginning.) Overall, I see this proposal as a big step backwards, and am not in favor. Sorry. Cheers, Bill > - Jeff and Craig > -- 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

[MPI3 Fortran] New Fortran proposal w.r.t. BIND(C)/logical/etc.
by Jeff Squyres (jsquyres) 22 Apr '13

22 Apr '13

Craig and I would like to propose a different MPI-3 errata solution for the current MPI Fortran existential crisis (keep in mind: there may be a different solution for MPI-4). If the group likes these idea, we will draw up an actual proposal. Here are the main points: 1. Remove BIND(C) from all prototypes in the spec. Have a short Advice to Implementers saying that using BIND(C) is not prohibited. If used, the effects of BIND(C) must *not* be visible to either the MPI application or PMPI-based tools (e.g., the linker symbol must be the same as if BIND(C) was not specified). 2. MPI-3 says that all mpi_f08 subroutines must use INTERFACE with the official MPI API name suffixed with _f08 when MPI_SUBARRAYS_SUPPORTED equals .FALSE.. Our proposal changes this such that the Fortran subroutine name *always* has the _f08 suffix (this is a direct consequence of #1). For example: INTERFACE MPI_SEND SUBROUTINE MPI_Send_f08(...args...) END INTERFACE MPI_SEND PROS 1. Removing BIND(C) solves LOGICAL/BIND(C) issues and string/BIND(C) issues. 2. This is a small enough change to be an MPI-3 errata. 3. Mandating the _f08 suffix for all cases removes corner cases and simplifies the standard. NEUTRAL 1. Tools will use the same name mangling schemes they have been using for years. We have not made the issue *better* (though we have removed the need to support the BIND(C, name=) symbol from the MPI symbol namespace), but we have also not made it *worse* (e.g., a proliferation of symbol names introduced into the MPI standard). CONS 1. There may be advantages in adding new functionality related to linker symbols / PMPI. However, this lies outside the scope of an errata; re-exmaining the whole solution/architecture can take place in the scope of MPI-4. Sidenotes / implications: 1. Chapter 14 explicitly states that Fortran symbols must be interceptable (MPI-3 p555). This means the MPI-3 "use mpi_f08" implementation cannot be in the CONTAIN section of the mpi_f08 module. 2. We donï¿½t think that mandating extra MPI_<foo>_cdesc() symbols are a good idea; they impose a specific implementation model that is not universal. - Jeff and Craig -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [MPI3 Fortran] [Mpi3-tools] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
by Bill Long 22 Apr '13

22 Apr '13

On 4/22/13 3:09 AM, Tobias Burnus wrote: > Bill Long wrote: >>> 2) The Fortran implementation will take the performance penalty of using >>> a wrapper routine to perform the operation (discounting sophisticated >>> IPA/WPA (interprocedural analysis/whole program analysis)). Taking this >>> performance penalty is common but not universal. >>> >> >> I agree there will be call overhead for the user who accesses MPI >> through the include file mechanism, unless, as you say, there is a >> sophisticated IPA/WPA mode in the compiler. However, the compiler >> does not have to be all that sophisticated to inline a module >> routine. The compiler has to know how to find the module information >> at compile time, and could have access to all the information needed >> to inline the wrapper. > > My possibly wrong impression is that only the Cray Fortran compiler does > so. I think most (all?) other compiler have a .mod file which contains > the interface of the procedures but not the procedure code itself. > Hence, they do not do any inlining at this stage. Those compilers will > presumably only do this kind of optimization with multi-file > interprocedural optimization (IPO)/link-time optimization (LTO). > > That crayftn does this inlining earlier is probably also a consequence > of (by default) storing the module-interface information in the .o file > instead of using a separate .mod file. If one already has the .o file, > considering IPO is more obvious than if assembler code and module > information are separated into .mod and .o files. The Cray compiler has a switch (-em) that causes module information to be put into .mod files instead of the .o file. This was added mainly to accommodate dependency rules in exiting Make files. Inlining of module procedures by CCE is unaffected by which method (.mod or .o) the user chooses. I'm aware that some compilers are more aggressive about inlining than others, which is why is wrote "could have access" instead of "will have access" or "has access". On the other hand, most compilers routinely inline intrinsics and procedures defined in intrinsic modules, so the technology is available to inline "known" routines. There is nothing to prevent them from treating the mpi and mpi_f08 modules that are accessed from known locations the same way they treat intrinsic modules. The key difference with module procedures (or internal procedures or procedures defined in the same source file) is that there is no ambiguity as to what procedure is being referenced, so it is theoretically possible to inline on the spot. Any particular compiler may or may not take advantage of this. For a non-module or submodule procedure or that is defined in a different file, you don't know until the link step what actual procedure is being referenced (unless there are specific compiler options to point to the desired procedure). Waiting until the link step requires a more "heroic" effort. Cheers, Bill > > * * * > > Regarding the latest PDF, I also have two nits: > > * [p.13,ll. 5-17] The example lists several directives to disable TKR > checks. It should add the following* to the list: > !GCC$ ATTRIBUTES NO_ARG_CHECK > which GCC/gfortran now supports.* > > * [p.17] The TS29113 reference should be updated now that it is an > approved ISO Technical Specification. Additionally, the name has now an > "of Fortran" in the name: "Further Interoperability of Fortran with C" > and latest draft (FDTS) is N1942, which contains some minor changes. See > http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnu… > and ftp://ftp.nag.co.uk/sc22wg5/N1901-N1950/N1942.pdf > > > Tobias > > * Cf. http://gcc.gnu.org/gcc-4.9/changes.html -- 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