May 2014 - mpiwg-fortran - mailman3.cels.anl.gov

Re: [MPIWG Fortran] Proposal: MPI_SIZEOF not profiled
by Rolf Rabenseifner 16 May '14

16 May '14

We need a correct expression telling that it is allowed to be not interceptable. MPI-3.0 wording: "as macro in C." [does not tell anything about Fortran] Existing (probably incorrect) proposal: "as macro in C or inlined in Fortran." Maybe better proposal: An implementation is allowed to implement MPI_WTIME, MPI_WTICK, PMPI_WTIME, PMPI_WTICK, the handle- and status-conversion functions (MPI_Group_f2c, etc.) in Sections 17.2.4 and 17.2.5, ***and MPI_SIZEOF*** and no others, ***such that they may not be interceptable (e.g., as macros in C, inlined, or contained in a Fortran module)***. Advice to implementors. Implementors should document which routines are implemented ***such that they are not interceptable***. (End of advice to implementors.) Advice to users. If these routines are implemented ***such that they are not interceptable***, they will not work with the MPI profiling interface. (End of advice to users.) And > > 1. provide a mechanism through which all of the MPI defined > > functions, except those allowed as ***non-interceptable*** > > (See Section 2.6.4), may > > be accessed with a name shift. This requires, in C and Fortran, an > > alternate entry point name, with the prefix PMPI_ for each MPI > > function in each provided language binding and language support > > method. For routines implemented as ***non-interceptable***, > > it is still required > > that the PMPI_ version be supplied and work as expected, but it is > > not possible to replace at link time the MPI_ version with a > > user-defined version. Best regards Rolf ----- Original Message ----- > From: "Hubert Ritzdorf" <Hubert.Ritzdorf(a)EMEA.NEC.COM> > To: "MPI-WG Fortran working group" <mpiwg-fortran(a)lists.mpi-forum.org> > Cc: "MPI Tool WG" <mpiwg-tools(a)lists.mpi-forum.org> > Sent: Friday, May 16, 2014 4:53:22 PM > Subject: Re: [MPIWG Fortran] Proposal: MPI_SIZEOF not profiled > > What does "inlined in Fortran" mean ? > Fortran is not case sensitive; I think 512 macros for MPI_Sizeof in > the command > line of Fortran compiler are not the solution. > Do we really want to run a sed (or perl, ...) script on each source > file before compilation ? > Or do you think on a new include file ? > > Inlining of PMPI_SIZEOF is missing in the proposal (it's mentioned in > the text before, > but not in the proposal) > > Hubert > ________________________________________ > From: mpiwg-fortran [mpiwg-fortran-bounces(a)lists.mpi-forum.org] on > behalf of Rolf Rabenseifner [rabenseifner(a)hlrs.de] > Sent: Friday, May 16, 2014 3:59 PM > To: MPI-WG Fortran working group > Cc: MPI Tool WG > Subject: Re: [MPIWG Fortran] Proposal: MPI_SIZEOF not profiled > > Samll updates, see below. > > I corrected the page number and I added > - "or inlined in Fortran", and > - the status-conversion routines in 17.2.5 > (They were new in MPI-3.0 and we oversaw that they > have similar quality as handle-conversion routines. > Major difference, they have an out-argument > within the argument list.) > > Do we also consensus in adding the status-conversions > to the macro+inline-allowence? > Or do we need to spilt these two things? > > Rolf > > ----- Original Message ----- > > From: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> > > To: "MPI Fortran WG" <mpiwg-fortran(a)lists.mpi-forum.org>, "MPI Tool > > WG" <mpiwg-tools(a)lists.mpi-forum.org> > > Sent: Friday, May 16, 2014 2:44:10 PM > > Subject: [MPIWG Fortran] Proposal: MPI_SIZEOF not profiled > > > > Fortran and Tools WGs: > > > > (=== this is a bit urgent if we want to get this read at the > > Chicago > > meeting; the T-2 deadline is this upcoming Monday morning ===) > > > > We seem to have some measure of consensus on the other thread that > > MPI_SIZEOF should not be profiled. > > > > Note, however, that the Tools chapter currently mandates that PMPI_ > > versions of all MPI routines must be available (including, for > > example, MPI_WTICK), but the MPI_ versions do not have to be > > replaceable at link time. I propose adopting this convention for > > MPI_SIZEOF, too (i.e. we have to provide PMPI_SIZEOF). > > > > Does this wording work as a proposal? > > > MPI-3.0 p19:45 through p20:5 (T&C chapter) currently reads: > (Jeff, you may used a wrong pdf with ther page numbers) > > > > ----- > > An implementation is allowed to implement MPI_WTIME, MPI_WTICK, > > PMPI_WTIME, PMPI_WTICK, and the handle-conversion functions > > (MPI_Group_f2c, etc.) in Section 17.2.4, and no others, as macros > > in > > C. > > > > Advice to implementors. Implementors should document which routines > > are implemented as macros. (End of advice to implementors.) > > > > Advice to users. If these routines are implemented as macros, they > > will not work with the MPI profiling interface. (End of advice to > > users.) > > ----- > > > > but should read (new text in ***): > > > > ----- > > An implementation is allowed to implement MPI_WTIME, MPI_WTICK, > > PMPI_WTIME, PMPI_WTICK, and the handle- > ***and status-*** > > conversion functions > > (MPI_Group_f2c, etc.) in Section***s*** 17.2.4 ***and 17.2.5***, > > and no others, as macros in C > ***or inlined in Fortran***. > > ***MPI_SIZEOF may also be inlined.*** > > > > Advice to implementors. Implementors should document which routines > > are implemented as macros ***or otherwise inlined***. (End of > > advice > > to implementors.) > > > > Advice to users. If these routines are implemented as macros ***or > > otherwise inlined***, they will not work with the MPI profiling > > interface. (End of advice to users.) > > ----- > > > > p555:31-37 (first page of the Tools chapter) currently says: > > > > ----- > > 1. provide a mechanism through which all of the MPI defined > > functions, except those allowed as macros (See Section 2.6.4), may > > be accessed with a name shift. This requires, in C and Fortran, an > > alternate entry point name, with the prefix PMPI_ for each MPI > > function in each provided language binding and language support > > method. For routines implemented as macros, it is still required > > that the PMPI_ version be supplied and work as expected, but it is > > not possible to replace at link time the MPI_ version with a > > user-defined version. > > ----- > > > > but should say > > > > ----- > > 1. provide a mechanism through which all of the MPI defined > > functions, except those allowed as macros ***or otherwise > > inlined*** > > (See Section 2.6.4), may be accessed with a name shift. This > > requires, in C and Fortran, an alternate entry point name, with the > > prefix PMPI_ for each MPI function in each provided language > > binding > > and language support method. For routines implemented as macros > > ***or otherwise inlined***, it is still required that the PMPI_ > > version be supplied and work as expected, but it is not possible to > > replace at link time the MPI_ version with a user-defined version. > > ----- > > > > -- > > Jeff Squyres > > jsquyres(a)cisco.com > > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > > _______________________________________________ > > mpiwg-fortran mailing list > > mpiwg-fortran(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-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) > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > > Click > https://www.mailcontrol.com/sr/j9b8NmH+kWjGX2PQPOmvUi5k6UwC8217mwo9DA!ymB+Y… > to report this email as spam. > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-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: [MPIWG Fortran] Proposal: MPI_SIZEOF not profiled
by Hubert Ritzdorf 16 May '14

16 May '14

What does "inlined in Fortran" mean ? Fortran is not case sensitive; I think 512 macros for MPI_Sizeof in the command line of Fortran compiler are not the solution. Do we really want to run a sed (or perl, ...) script on each source file before compilation ? Or do you think on a new include file ? Inlining of PMPI_SIZEOF is missing in the proposal (it's mentioned in the text before, but not in the proposal) Hubert ________________________________________ From: mpiwg-fortran [mpiwg-fortran-bounces(a)lists.mpi-forum.org] on behalf of Rolf Rabenseifner [rabenseifner(a)hlrs.de] Sent: Friday, May 16, 2014 3:59 PM To: MPI-WG Fortran working group Cc: MPI Tool WG Subject: Re: [MPIWG Fortran] Proposal: MPI_SIZEOF not profiled Samll updates, see below. I corrected the page number and I added - "or inlined in Fortran", and - the status-conversion routines in 17.2.5 (They were new in MPI-3.0 and we oversaw that they have similar quality as handle-conversion routines. Major difference, they have an out-argument within the argument list.) Do we also consensus in adding the status-conversions to the macro+inline-allowence? Or do we need to spilt these two things? Rolf ----- Original Message ----- > From: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> > To: "MPI Fortran WG" <mpiwg-fortran(a)lists.mpi-forum.org>, "MPI Tool WG" <mpiwg-tools(a)lists.mpi-forum.org> > Sent: Friday, May 16, 2014 2:44:10 PM > Subject: [MPIWG Fortran] Proposal: MPI_SIZEOF not profiled > > Fortran and Tools WGs: > > (=== this is a bit urgent if we want to get this read at the Chicago > meeting; the T-2 deadline is this upcoming Monday morning ===) > > We seem to have some measure of consensus on the other thread that > MPI_SIZEOF should not be profiled. > > Note, however, that the Tools chapter currently mandates that PMPI_ > versions of all MPI routines must be available (including, for > example, MPI_WTICK), but the MPI_ versions do not have to be > replaceable at link time. I propose adopting this convention for > MPI_SIZEOF, too (i.e. we have to provide PMPI_SIZEOF). > > Does this wording work as a proposal? > MPI-3.0 p19:45 through p20:5 (T&C chapter) currently reads: (Jeff, you may used a wrong pdf with ther page numbers) > > ----- > An implementation is allowed to implement MPI_WTIME, MPI_WTICK, > PMPI_WTIME, PMPI_WTICK, and the handle-conversion functions > (MPI_Group_f2c, etc.) in Section 17.2.4, and no others, as macros in > C. > > Advice to implementors. Implementors should document which routines > are implemented as macros. (End of advice to implementors.) > > Advice to users. If these routines are implemented as macros, they > will not work with the MPI profiling interface. (End of advice to > users.) > ----- > > but should read (new text in ***): > > ----- > An implementation is allowed to implement MPI_WTIME, MPI_WTICK, > PMPI_WTIME, PMPI_WTICK, and the handle- ***and status-*** > conversion functions > (MPI_Group_f2c, etc.) in Section***s*** 17.2.4 ***and 17.2.5***, > and no others, as macros in C ***or inlined in Fortran***. > ***MPI_SIZEOF may also be inlined.*** > > Advice to implementors. Implementors should document which routines > are implemented as macros ***or otherwise inlined***. (End of advice > to implementors.) > > Advice to users. If these routines are implemented as macros ***or > otherwise inlined***, they will not work with the MPI profiling > interface. (End of advice to users.) > ----- > > p555:31-37 (first page of the Tools chapter) currently says: > > ----- > 1. provide a mechanism through which all of the MPI defined > functions, except those allowed as macros (See Section 2.6.4), may > be accessed with a name shift. This requires, in C and Fortran, an > alternate entry point name, with the prefix PMPI_ for each MPI > function in each provided language binding and language support > method. For routines implemented as macros, it is still required > that the PMPI_ version be supplied and work as expected, but it is > not possible to replace at link time the MPI_ version with a > user-defined version. > ----- > > but should say > > ----- > 1. provide a mechanism through which all of the MPI defined > functions, except those allowed as macros ***or otherwise inlined*** > (See Section 2.6.4), may be accessed with a name shift. This > requires, in C and Fortran, an alternate entry point name, with the > prefix PMPI_ for each MPI function in each provided language binding > and language support method. For routines implemented as macros > ***or otherwise inlined***, it is still required that the PMPI_ > version be supplied and work as expected, but it is not possible to > replace at link time the MPI_ version with a user-defined version. > ----- > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-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) _______________________________________________ mpiwg-fortran mailing list mpiwg-fortran(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran Click https://www.mailcontrol.com/sr/j9b8NmH+kWjGX2PQPOmvUi5k6UwC8217mwo9DA!ymB+Y… to report this email as spam.

1 0

Re: [MPIWG Fortran] Proposal: MPI_SIZEOF not profiled
by N.M. Maclaren 16 May '14

16 May '14

On May 16 2014, Bill Long wrote: >> >> From my viewpoint, yes. MPI_Sizeof has never been an ordinary Fortran >> function. I don't know the latest polymorphic features well enough >> to know whether it even CAN be implemented within the standard. Indeed, >> one reasonable way to implement it is by the mpif90 command running a >> preprocessor on the source to replace it by the relevant value! > > The MPI subroutine MPI_SIZEOF is restricted to arguments of intrinsic > numeric type (integer, real, complex). No derived types or polymorphic > arguments. Fortran does have an intrinsic, STORAGE_SIZE, that returns the > size value in bits. Divide by 8 to get the answer for MPI_SIZEOF. ... Only since Fortran 2008 (2011) and MPI_Sizeof is a lot older than that. I don't know how many compilers currently support STORAGE_SIZE, but I will bet that it is not all, even now. Regards, Nick Maclaren.

1 0

Re: [MPIWG Fortran] Proposal: MPI_SIZEOF not profiled
by Jeff Hammond 16 May '14

16 May '14

"any routine with a name starting with MPI_ or PMPI_ has to come from the mpi libraries and cannot be supplied by the user?" This is in the standard. The MPI namespace is reserved. Apps that use it are in violation. Jeff Sent from my iPhone > On May 16, 2014, at 8:44 AM, Bill Long <longb(a)cray.com> wrote: > > any routine with a name starting with MPI_ or PMPI_ has to come from the mpi libraries and cannot be supplied by the user?

1 0

Re: [MPIWG Fortran] Proposal: MPI_SIZEOF not profiled
by Rolf Rabenseifner 16 May '14

16 May '14

Samll updates, see below. I corrected the page number and I added - "or inlined in Fortran", and - the status-conversion routines in 17.2.5 (They were new in MPI-3.0 and we oversaw that they have similar quality as handle-conversion routines. Major difference, they have an out-argument within the argument list.) Do we also consensus in adding the status-conversions to the macro+inline-allowence? Or do we need to spilt these two things? Rolf ----- Original Message ----- > From: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> > To: "MPI Fortran WG" <mpiwg-fortran(a)lists.mpi-forum.org>, "MPI Tool WG" <mpiwg-tools(a)lists.mpi-forum.org> > Sent: Friday, May 16, 2014 2:44:10 PM > Subject: [MPIWG Fortran] Proposal: MPI_SIZEOF not profiled > > Fortran and Tools WGs: > > (=== this is a bit urgent if we want to get this read at the Chicago > meeting; the T-2 deadline is this upcoming Monday morning ===) > > We seem to have some measure of consensus on the other thread that > MPI_SIZEOF should not be profiled. > > Note, however, that the Tools chapter currently mandates that PMPI_ > versions of all MPI routines must be available (including, for > example, MPI_WTICK), but the MPI_ versions do not have to be > replaceable at link time. I propose adopting this convention for > MPI_SIZEOF, too (i.e. we have to provide PMPI_SIZEOF). > > Does this wording work as a proposal? > MPI-3.0 p19:45 through p20:5 (T&C chapter) currently reads: (Jeff, you may used a wrong pdf with ther page numbers) > > ----- > An implementation is allowed to implement MPI_WTIME, MPI_WTICK, > PMPI_WTIME, PMPI_WTICK, and the handle-conversion functions > (MPI_Group_f2c, etc.) in Section 17.2.4, and no others, as macros in > C. > > Advice to implementors. Implementors should document which routines > are implemented as macros. (End of advice to implementors.) > > Advice to users. If these routines are implemented as macros, they > will not work with the MPI profiling interface. (End of advice to > users.) > ----- > > but should read (new text in ***): > > ----- > An implementation is allowed to implement MPI_WTIME, MPI_WTICK, > PMPI_WTIME, PMPI_WTICK, and the handle- ***and status-*** > conversion functions > (MPI_Group_f2c, etc.) in Section***s*** 17.2.4 ***and 17.2.5***, > and no others, as macros in C ***or inlined in Fortran***. > ***MPI_SIZEOF may also be inlined.*** > > Advice to implementors. Implementors should document which routines > are implemented as macros ***or otherwise inlined***. (End of advice > to implementors.) > > Advice to users. If these routines are implemented as macros ***or > otherwise inlined***, they will not work with the MPI profiling > interface. (End of advice to users.) > ----- > > p555:31-37 (first page of the Tools chapter) currently says: > > ----- > 1. provide a mechanism through which all of the MPI defined > functions, except those allowed as macros (See Section 2.6.4), may > be accessed with a name shift. This requires, in C and Fortran, an > alternate entry point name, with the prefix PMPI_ for each MPI > function in each provided language binding and language support > method. For routines implemented as macros, it is still required > that the PMPI_ version be supplied and work as expected, but it is > not possible to replace at link time the MPI_ version with a > user-defined version. > ----- > > but should say > > ----- > 1. provide a mechanism through which all of the MPI defined > functions, except those allowed as macros ***or otherwise inlined*** > (See Section 2.6.4), may be accessed with a name shift. This > requires, in C and Fortran, an alternate entry point name, with the > prefix PMPI_ for each MPI function in each provided language binding > and language support method. For routines implemented as macros > ***or otherwise inlined***, it is still required that the PMPI_ > version be supplied and work as expected, but it is not possible to > replace at link time the MPI_ version with a user-defined version. > ----- > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-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: [MPIWG Fortran] Proposal: MPI_SIZEOF not profiled
by Bill Long 16 May '14

16 May '14

On May 16, 2014, at 8:28 AM, N.M. Maclaren <nmm1(a)cam.ac.uk> wrote: > On May 16 2014, Jeff Squyres (jsquyres) wrote: > >> Fortran and Tools WGs: >> >> (=== this is a bit urgent if we want to get this read at the Chicago meeting; the T-2 deadline is this upcoming Monday morning ===) >> >> We seem to have some measure of consensus on the other thread that MPI_SIZEOF should not be profiled. >> >> Note, however, that the Tools chapter currently mandates that PMPI_ versions of all MPI routines must be available (including, for example, MPI_WTICK), but the MPI_ versions do not have to be replaceable at link time. I propose adopting this convention for MPI_SIZEOF, too (i.e. we have to provide PMPI_SIZEOF). >> >> Does this wording work as a proposal? > > From my viewpoint, yes. MPI_Sizeof has never been an ordinary Fortran > function. I don't know the latest polymorphic features well enough > to know whether it even CAN be implemented within the standard. Indeed, > one reasonable way to implement it is by the mpif90 command running a > preprocessor on the source to replace it by the relevant value! The MPI subroutine MPI_SIZEOF is restricted to arguments of intrinsic numeric type (integer, real, complex). No derived types or polymorphic arguments. Fortran does have an intrinsic, STORAGE_SIZE, that returns the size value in bits. Divide by 8 to get the answer for MPI_SIZEOF. Indeed, a Fortran compiler could inline this function as long as it was accessed through a module (and hence the compiler knows that it is the MPI version and not a user-written subroutine that happened to have this name). Such inlining being allowed by the proposal from Jeff is definitely a good thing. I can’t say about using mpif90 as a compiler. Is that a license to, for example, suspend normal Fortran rules and require that any routine with a name starting with MPI_ or PMPI_ has to come from the mpi libraries and cannot be supplied by the user? If that’s the case, then Nick’s pseudo-macro scheme could work as well. (I’ve no experience with mpif90 - all of our users just compile with ftn, same as for any Fortran program.) Cheers, Bill > > > Regards, > Nick Maclaren. > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran Bill Long longb(a)cray.com Fortran Technical Suport & 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: [MPIWG Fortran] Proposal: MPI_SIZEOF not profiled
by N.M. Maclaren 16 May '14

16 May '14

On May 16 2014, Jeff Squyres (jsquyres) wrote: >Fortran and Tools WGs: > > (=== this is a bit urgent if we want to get this read at the Chicago > meeting; the T-2 deadline is this upcoming Monday morning ===) > > We seem to have some measure of consensus on the other thread that > MPI_SIZEOF should not be profiled. > > Note, however, that the Tools chapter currently mandates that PMPI_ > versions of all MPI routines must be available (including, for example, > MPI_WTICK), but the MPI_ versions do not have to be replaceable at link > time. I propose adopting this convention for MPI_SIZEOF, too (i.e. we > have to provide PMPI_SIZEOF). > >Does this wording work as a proposal? >From my viewpoint, yes. MPI_Sizeof has never been an ordinary Fortran function. I don't know the latest polymorphic features well enough to know whether it even CAN be implemented within the standard. Indeed, one reasonable way to implement it is by the mpif90 command running a preprocessor on the source to replace it by the relevant value! Regards, Nick Maclaren.

1 0

Proposal: MPI_SIZEOF not profiled
by Jeff Squyres (jsquyres) 16 May '14

16 May '14

Fortran and Tools WGs: (=== this is a bit urgent if we want to get this read at the Chicago meeting; the T-2 deadline is this upcoming Monday morning ===) We seem to have some measure of consensus on the other thread that MPI_SIZEOF should not be profiled. Note, however, that the Tools chapter currently mandates that PMPI_ versions of all MPI routines must be available (including, for example, MPI_WTICK), but the MPI_ versions do not have to be replaceable at link time. I propose adopting this convention for MPI_SIZEOF, too (i.e. we have to provide PMPI_SIZEOF). Does this wording work as a proposal? MPI-3.0 p20:46 through p21:5 (T&C chapter) currently reads: ----- An implementation is allowed to implement MPI_WTIME, MPI_WTICK, PMPI_WTIME, PMPI_WTICK, and the handle-conversion functions (MPI_Group_f2c, etc.) in Section 17.2.4, and no others, as macros in C. Advice to implementors. Implementors should document which routines are implemented as macros. (End of advice to implementors.) Advice to users. If these routines are implemented as macros, they will not work with the MPI profiling interface. (End of advice to users.) ----- but should read (new text in ***): ----- An implementation is allowed to implement MPI_WTIME, MPI_WTICK, PMPI_WTIME, PMPI_WTICK, and the handle-conversion functions (MPI_Group_f2c, etc.) in Section 17.2.4, and no others, as macros in C. ***MPI_SIZEOF may also be inlined.*** Advice to implementors. Implementors should document which routines are implemented as macros ***or otherwise inlined***. (End of advice to implementors.) Advice to users. If these routines are implemented as macros ***or otherwise inlined***, they will not work with the MPI profiling interface. (End of advice to users.) ----- p555:31-37 (first page of the Tools chapter) currently says: ----- 1. provide a mechanism through which all of the MPI defined functions, except those allowed as macros (See Section 2.6.4), may be accessed with a name shift. This requires, in C and Fortran, an alternate entry point name, with the prefix PMPI_ for each MPI function in each provided language binding and language support method. For routines implemented as macros, it is still required that the PMPI_ version be supplied and work as expected, but it is not possible to replace at link time the MPI_ version with a user-defined version. ----- but should say ----- 1. provide a mechanism through which all of the MPI defined functions, except those allowed as macros ***or otherwise inlined*** (See Section 2.6.4), may be accessed with a name shift. This requires, in C and Fortran, an alternate entry point name, with the prefix PMPI_ for each MPI function in each provided language binding and language support method. For routines implemented as macros ***or otherwise inlined***, it is still required that the PMPI_ version be supplied and work as expected, but it is not possible to replace at link time the MPI_ version with a user-defined version. ----- -- 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: [MPIWG Fortran] [mpiwg-tools] Profiling for MPI_SIZEOF?
by Martin Schulz 16 May '14

16 May '14

I also can¹t think of a need to intercept this call - I would be OK with option #1 as well. Martin ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://scalability.llnl.gov/ CASC @ Lawrence Livermore National Laboratory, Livermore, USA On 5/15/14, 1:38 PM, "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> wrote: >On May 15, 2014, at 4:17 PM, Marc-Andre Hermanns ><m.a.hermanns(a)grs-sim.de> wrote: > >> isn't MPI_SIZEOF also named as a function that is allowed to be >> implemented as a macro? > >Not that I can find -- that's why I'm asking this question... > >> Also, the call is likely to be so short (in duration) that you'd have a >> huge overhead in intercepting it. >> >> I would also be ok with proposed solution #1. > > >Good. Bill Long is, too. :-) > >-- >Jeff Squyres >jsquyres(a)cisco.com >For corporate legal information go to: >http://www.cisco.com/web/about/doing_business/legal/cri/ > >_______________________________________________ >mpiwg-tools mailing list >mpiwg-tools(a)lists.mpi-forum.org >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools

1 0

Re: [MPIWG Fortran] Profiling for MPI_SIZEOF?
by Bill Long 15 May '14

15 May '14

On May 15, 2014, at 4:00 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >>>> That said, the optimal implementation would be to write all of the specific versions (I’m seeing 10) for a generic named MPI_SIZEOF. For each specific version, the executed code reduces to >>>> >>>> size = storage_size(x)/8 >>>> >>>> which the compiler will evaluate at compile time based on the type of x. >>> >>> No, there's 10 * 7 versions, right? One for each type (10), and then 1 for each rank. >>> >>> The language in the MPI spec explicitly allows you to pass an array as the argument of x (although it does say that it will return the size of the base element -- not the array). >>> >> >> You are right. I just looked at one of the example specifics: >> >> subroutine MPI_Sizeof_xint8 (x, size, ierror) >> use,intrinsic :: iso_fortran_env, only: int8 >> integer(int8),dimension(..) :: x >> INTEGER, intent(out) :: size >> INTEGER, optional, intent(out) :: ierror >> >> size = storage_size(x)/8 >> if (present(ierror)) ierror = 0 >> end subroutine MPI_Sizeof_xint8 >> >> which is declared assumed-rank, but specific type (which is the interesting thing here). That’s how I got 10. To get them all without assumed-rank, you need 10*15 (the Fortran standard allows array ranks up to 15 now). All the more reason for no intercepting. > > I vote for #1. Does anyone thing that there are linkers that can > handle 10^15 symbols? It’s actually 160 = (10 * (1 + 15) ) where the 1 is for scalar, and the 15 for ranks 1..15. Still, an annoying number. If there is compiler support for assumed-rank, the total is 10, since the function result is independent of rank. Cheers, Bill > > Jeff > > > > -- > Jeff Hammond > jeff.science(a)gmail.com > http://jeffhammond.github.io/ > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran Bill Long longb(a)cray.com Fortran Technical Suport & 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