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

Re: [MPIWG Fortran] [MPI Forum] #403: Error in description of size-specific types
by Rolf Rabenseifner 19 May '14

19 May '14

After additional reviews, somebody should set the ticket to "Scheduled". I'll cannot because I'll be on vacation. Rolf ----- Original Message ----- > From: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> > To: "MPI-WG Fortran working group" <mpiwg-fortran(a)lists.mpi-forum.org> > Cc: "Bill Gropp" <wgropp(a)uiuc.edu>, "Martin Schulz" <schulzm(a)llnl.gov> > Sent: Monday, May 19, 2014 5:56:16 PM > Subject: Re: [MPIWG Fortran] [MPI Forum] #403: Error in description of size-specific types > > Sure. > > This is the first time I've seen this, so I need to think about it > more. But I have no problem with it being put on the schedule to be > read. > > > > On May 19, 2014, at 8:39 AM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> > wrote: > > > Dear Fortran WG, > > > > Bill Gropp has detected a bug in the Fortran Interface > > text on MPI-3.0 page 620 and proposed a perfect correction. > > > > I would like to set this to "scheduled" as MPI-3.0 Erratum > > at the upcoming Forum meeting. > > > > Okay? > > > > Best regards > > Rolf > > > > > > ----- Forwarded Message ----- > > From: "MPI Forum" <mpi-forum(a)lists.mpi-forum.org> > > Sent: Monday, May 19, 2014 12:49:22 PM > > Subject: Re: [MPI Forum] #403: Error in description of > > size-specific types > > > > #403: Error in description of size-specific types > > -------------------------------------+------------------------------------- > > Reporter: gropp | Owner: > > Type: Correction to standard | Status: new > > (for upcoming release + errata) | Milestone: > > 2014/06/02 > > Priority: Not ready / author | Chicago, USA > > rework | Resolution: > > Version: MPI 3.0 errata | Implementation status: > > Unnecessary > > Keywords: | > > -------------------------------------+------------------------------------- > > > > Comment (by RolfRabenseifner): > > > > Review: For me, the solution seems to be perfect. > > > > -- > > Ticket URL: > > <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/403#comment:4> > > MPI Forum <https://svn.mpi-forum.org/> > > MPI Forum > > > > -- > > 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 > > > -- > 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] [mpiwg-tools] Proposal: MPI_SIZEOF not profiled
by Bill Long 19 May '14

19 May '14

On May 19, 2014, at 10:45 AM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > On May 19, 2014, at 11:34 AM, Bill Long <longb(a)cray.com> wrote: > >> I was curious why the PMPI versions had been exempted in the text quoted in the ticket. It seems to contradict the text quoted above. I’m inclined to require that the C library PMPI versions be supplied even if the MPI versions are implemented as non-interceptable. The PMPI version could be as simple as a wrapper around a macro. But it ensures that the C library PMPI version exists for cross-language calling (where macros don’t work). > > p555 says that the PMPI_ versions must be supplied. But it does not say anything about forcing them to be in a library (e.g., being able to call the C version from Fortran). That would be a new requirement. > Ah, OK. I then assume “supplied” can be satisfied by providing a macro for PMPI_Wtick, for example. In that case, the Fortran side can supply a non-MPI-named C wrapper that uses that macro. It seems reasonable to expect that the Fortran and C versions of routines like MPI_WTICK return the same values, which would be ensured if the Fortran version always calls the C equivalent. It’s useful to realize that some level of trickery might be needed to make that happen. Cheers, Bill > -- > 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 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] [MPI Forum] #403: Error in description of size-specific types
by Jeff Squyres (jsquyres) 19 May '14

19 May '14

Sure. This is the first time I've seen this, so I need to think about it more. But I have no problem with it being put on the schedule to be read. On May 19, 2014, at 8:39 AM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: > Dear Fortran WG, > > Bill Gropp has detected a bug in the Fortran Interface > text on MPI-3.0 page 620 and proposed a perfect correction. > > I would like to set this to "scheduled" as MPI-3.0 Erratum > at the upcoming Forum meeting. > > Okay? > > Best regards > Rolf > > > ----- Forwarded Message ----- > From: "MPI Forum" <mpi-forum(a)lists.mpi-forum.org> > Sent: Monday, May 19, 2014 12:49:22 PM > Subject: Re: [MPI Forum] #403: Error in description of size-specific types > > #403: Error in description of size-specific types > -------------------------------------+------------------------------------- > Reporter: gropp | Owner: > Type: Correction to standard | Status: new > (for upcoming release + errata) | Milestone: 2014/06/02 > Priority: Not ready / author | Chicago, USA > rework | Resolution: > Version: MPI 3.0 errata | Implementation status: Unnecessary > Keywords: | > -------------------------------------+------------------------------------- > > Comment (by RolfRabenseifner): > > Review: For me, the solution seems to be perfect. > > -- > Ticket URL: <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/403#comment:4> > MPI Forum <https://svn.mpi-forum.org/> > MPI Forum > > -- > 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 -- 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] Proposal: MPI_SIZEOF not profiled
by Jeff Squyres (jsquyres) 19 May '14

19 May '14

On May 19, 2014, at 11:34 AM, Bill Long <longb(a)cray.com> wrote: > I was curious why the PMPI versions had been exempted in the text quoted in the ticket. It seems to contradict the text quoted above. I’m inclined to require that the C library PMPI versions be supplied even if the MPI versions are implemented as non-interceptable. The PMPI version could be as simple as a wrapper around a macro. But it ensures that the C library PMPI version exists for cross-language calling (where macros don’t work). p555 says that the PMPI_ versions must be supplied. But it does not say anything about forcing them to be in a library (e.g., being able to call the C version from Fortran). That would be a new requirement. -- 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] Proposal: MPI_SIZEOF not profiled
by Jeff Squyres (jsquyres) 19 May '14

19 May '14

I think we need to push this errata out to the Japan meeting. There seems to be a bunch of subtlety here; trying to rush this through today does not seem like a good idea just to meet the T-2 week deadline for the Chicago meeting (which technically expires at 2pm US Central time today -- which is about 3.5 hours from now). Let me try to summarize the salient points so far: 1. The old text kinda sucks: a. it says "macros" (including the section title) where it really means "not interceptable" b. p19 implies that these function can only be macros in C (not inlined, and not in Fortran), which seems to contradict p555 2. We need to add the Status conversion functions in there 3. We want to add MPI_SIZEOF (which is Fortran-only, BTW) to the list 4. The use of the word "inline" seems to be a bad idea because it can have many different meanings. We should say that these functions are not interceptable, which is the real requirement. 5. I think it would be better to change p555 to not say "macros" (i.e., "non-interceptable"), but rather to say "the routines listed in 2.6.4" (i.e., who cares what the reason is -- just cite 2.6.4 and let 2.6.4 explain everything). Is that all? On May 19, 2014, at 11:08 AM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: > Yes, the "allowed as macros" on MPI-3.0 p555:32 > would allow a different mechanism for these routines > that makes them non-interceptable. > > If this "non-interceptable" is done by other means > than macro, then p555:35 "For routines implemented > as macros, it is still required that the PMPI_ > version be supplied" would not apply! > > It is bad to use different wording for having > better English quality ;-( > > And your are right, my "#ifdef MPI_Wait" says > therefore nothing. > > Do you all agree that wording in > p19:48 - p20:5 and p555:31-37 is at all inconsistent > and therefore new and useful wording is needed > in this erratum? > > Rolf > > ----- Original Message ----- >> From: "N.M. Maclaren" <nmm1(a)cam.ac.uk> >> To: "MPI-WG Fortran working group" <mpiwg-fortran(a)lists.mpi-forum.org> >> Sent: Monday, May 19, 2014 4:35:10 PM >> Subject: Re: [MPIWG Fortran] [mpiwg-tools] Proposal: MPI_SIZEOF not profiled >> >> On May 19 2014, Rolf Rabenseifner wrote: >>> >>> Bill, >>> >>> your text goes beyond the errata goal. >>> >>> The errata goal was: >>> - adding the missing Status conversion >>> - adding MPI_SIZEOF >>> >>> And this works as errata. >>> >>> Your goal is to allow also >>> - Fortran non-interceptable for these routines. >>> >>> Your additional Change is to allow other methods >>> than C macros for C. >>> This would prevent "#ifdef MPI_Wtime". >>> >>> All this would be MPI-4.0 and not MPI-3.0 errata. >> >> Would it? I don't know what useful effect you would expect >> "#ifdef MPI_Wtime" to achieve, but it assuredly would NOT tell >> you (reliably) whether or not it can be accessed through the >> profiling interface. 14.2 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. >> >> Because it says "ALLOWED as macros", MPI_Wtime may not be accessed >> through the profiling interface, whether or not it is implemented >> as a macro. Doing so is a user error, leading to undefined >> behaviour. >> Therefore, an implementation may implement them as C inline >> functions, >> and would meet all of the requirements of MPI. >> >> The error is more pervasive than just for Fortran. Because it did >> not say what it meant, but something that was equivalent under K&R C >> (sic), it wasn't strictly true in C90 and was rendered significantly >> misleading (arguably erroneous) by C99. And that's the reason that >> some people get very unhappy about the proposed partial fix. >> >> It's also why the best solution is to regard ALL of the wording as >> an error - which would probably mean starting a new ticket. But it's >> definitely an error in the wording, not a change. >> >> >> Regards, >> Nick Maclaren. >> >> _______________________________________________ >> 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 -- 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] Proposal: MPI_SIZEOF not profiled
by Bill Long 19 May '14

19 May '14

On May 19, 2014, at 10:08 AM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: > Yes, the "allowed as macros" on MPI-3.0 p555:32 > would allow a different mechanism for these routines > that makes them non-interceptable. > > If this "non-interceptable" is done by other means > than macro, then p555:35 "For routines implemented > as macros, it is still required that the PMPI_ > version be supplied" would not apply! I was curious why the PMPI versions had been exempted in the text quoted in the ticket. It seems to contradict the text quoted above. I’m inclined to require that the C library PMPI versions be supplied even if the MPI versions are implemented as non-interceptable. The PMPI version could be as simple as a wrapper around a macro. But it ensures that the C library PMPI version exists for cross-language calling (where macros don’t work). Cheers, Bill > > It is bad to use different wording for having > better English quality ;-( > > And your are right, my "#ifdef MPI_Wait" says > therefore nothing. > > Do you all agree that wording in > p19:48 - p20:5 and p555:31-37 is at all inconsistent > and therefore new and useful wording is needed > in this erratum? > > Rolf > > ----- Original Message ----- >> From: "N.M. Maclaren" <nmm1(a)cam.ac.uk> >> To: "MPI-WG Fortran working group" <mpiwg-fortran(a)lists.mpi-forum.org> >> Sent: Monday, May 19, 2014 4:35:10 PM >> Subject: Re: [MPIWG Fortran] [mpiwg-tools] Proposal: MPI_SIZEOF not profiled >> >> On May 19 2014, Rolf Rabenseifner wrote: >>> >>> Bill, >>> >>> your text goes beyond the errata goal. >>> >>> The errata goal was: >>> - adding the missing Status conversion >>> - adding MPI_SIZEOF >>> >>> And this works as errata. >>> >>> Your goal is to allow also >>> - Fortran non-interceptable for these routines. >>> >>> Your additional Change is to allow other methods >>> than C macros for C. >>> This would prevent "#ifdef MPI_Wtime". >>> >>> All this would be MPI-4.0 and not MPI-3.0 errata. >> >> Would it? I don't know what useful effect you would expect >> "#ifdef MPI_Wtime" to achieve, but it assuredly would NOT tell >> you (reliably) whether or not it can be accessed through the >> profiling interface. 14.2 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. >> >> Because it says "ALLOWED as macros", MPI_Wtime may not be accessed >> through the profiling interface, whether or not it is implemented >> as a macro. Doing so is a user error, leading to undefined >> behaviour. >> Therefore, an implementation may implement them as C inline >> functions, >> and would meet all of the requirements of MPI. >> >> The error is more pervasive than just for Fortran. Because it did >> not say what it meant, but something that was equivalent under K&R C >> (sic), it wasn't strictly true in C90 and was rendered significantly >> misleading (arguably erroneous) by C99. And that's the reason that >> some people get very unhappy about the proposed partial fix. >> >> It's also why the best solution is to regard ALL of the wording as >> an error - which would probably mean starting a new ticket. But it's >> definitely an error in the wording, not a change. >> >> >> Regards, >> Nick Maclaren. >> >> _______________________________________________ >> 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 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] [mpiwg-tools] Proposal: MPI_SIZEOF not profiled
by Rolf Rabenseifner 19 May '14

19 May '14

Yes, the "allowed as macros" on MPI-3.0 p555:32 would allow a different mechanism for these routines that makes them non-interceptable. If this "non-interceptable" is done by other means than macro, then p555:35 "For routines implemented as macros, it is still required that the PMPI_ version be supplied" would not apply! It is bad to use different wording for having better English quality ;-( And your are right, my "#ifdef MPI_Wait" says therefore nothing. Do you all agree that wording in p19:48 - p20:5 and p555:31-37 is at all inconsistent and therefore new and useful wording is needed in this erratum? Rolf ----- Original Message ----- > From: "N.M. Maclaren" <nmm1(a)cam.ac.uk> > To: "MPI-WG Fortran working group" <mpiwg-fortran(a)lists.mpi-forum.org> > Sent: Monday, May 19, 2014 4:35:10 PM > Subject: Re: [MPIWG Fortran] [mpiwg-tools] Proposal: MPI_SIZEOF not profiled > > On May 19 2014, Rolf Rabenseifner wrote: > > > >Bill, > > > >your text goes beyond the errata goal. > > > >The errata goal was: > > - adding the missing Status conversion > > - adding MPI_SIZEOF > > > >And this works as errata. > > > >Your goal is to allow also > > - Fortran non-interceptable for these routines. > > > >Your additional Change is to allow other methods > >than C macros for C. > >This would prevent "#ifdef MPI_Wtime". > > > >All this would be MPI-4.0 and not MPI-3.0 errata. > > Would it? I don't know what useful effect you would expect > "#ifdef MPI_Wtime" to achieve, but it assuredly would NOT tell > you (reliably) whether or not it can be accessed through the > profiling interface. 14.2 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. > > Because it says "ALLOWED as macros", MPI_Wtime may not be accessed > through the profiling interface, whether or not it is implemented > as a macro. Doing so is a user error, leading to undefined > behaviour. > Therefore, an implementation may implement them as C inline > functions, > and would meet all of the requirements of MPI. > > The error is more pervasive than just for Fortran. Because it did > not say what it meant, but something that was equivalent under K&R C > (sic), it wasn't strictly true in C90 and was rendered significantly > misleading (arguably erroneous) by C99. And that's the reason that > some people get very unhappy about the proposed partial fix. > > It's also why the best solution is to regard ALL of the wording as > an error - which would probably mean starting a new ticket. But it's > definitely an error in the wording, not a change. > > > Regards, > Nick Maclaren. > > _______________________________________________ > 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] [mpiwg-tools] Proposal: MPI_SIZEOF not profiled
by N.M. Maclaren 19 May '14

19 May '14

On May 19 2014, Rolf Rabenseifner wrote: > >Bill, > >your text goes beyond the errata goal. > >The errata goal was: > - adding the missing Status conversion > - adding MPI_SIZEOF > >And this works as errata. > >Your goal is to allow also > - Fortran non-interceptable for these routines. > >Your additional Change is to allow other methods >than C macros for C. >This would prevent "#ifdef MPI_Wtime". > >All this would be MPI-4.0 and not MPI-3.0 errata. Would it? I don't know what useful effect you would expect "#ifdef MPI_Wtime" to achieve, but it assuredly would NOT tell you (reliably) whether or not it can be accessed through the profiling interface. 14.2 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. Because it says "ALLOWED as macros", MPI_Wtime may not be accessed through the profiling interface, whether or not it is implemented as a macro. Doing so is a user error, leading to undefined behaviour. Therefore, an implementation may implement them as C inline functions, and would meet all of the requirements of MPI. The error is more pervasive than just for Fortran. Because it did not say what it meant, but something that was equivalent under K&R C (sic), it wasn't strictly true in C90 and was rendered significantly misleading (arguably erroneous) by C99. And that's the reason that some people get very unhappy about the proposed partial fix. It's also why the best solution is to regard ALL of the wording as an error - which would probably mean starting a new ticket. But it's definitely an error in the wording, not a change. Regards, Nick Maclaren.

1 0

Re: [MPIWG Fortran] [mpiwg-tools] Proposal: MPI_SIZEOF not profiled
by Rolf Rabenseifner 19 May '14

19 May '14

Bill, your text goes beyond the errata goal. The errata goal was: - adding the missing Status conversion - adding MPI_SIZEOF And this works as errata. Your goal is to allow also - Fortran non-interceptable for these routines. Your additional Change is to allow other methods than C macros for C. This would prevent "#ifdef MPI_Wtime". All this would be MPI-4.0 and not MPI-3.0 errata. Rolf ----- Original Message ----- > From: "Bill Long" <longb(a)cray.com> > To: "MPI-WG Fortran working group" <mpiwg-fortran(a)lists.mpi-forum.org> > Sent: Monday, May 19, 2014 2:57:41 PM > Subject: Re: [MPIWG Fortran] [mpiwg-tools] Proposal: MPI_SIZEOF not profiled > > > On May 19, 2014, at 5:27 AM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> > wrote: > > > About https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/428 > > > >> It is far better to say what you mean, that say something which > >> most > >> people believe is equivalent, because it won't be for all > >> compilers > >> or necessarily so in the future. > > > > Yes, therefore I would like to see a wording like > > > > 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 Sections 17.2.4 and 17.2.5, and no others, as macros in C. > > ***MPI_SIZEOF and PMPI_SIZEOF may also be implemented > > such that they may not be interceptable.*** > > > > Advice to implementors. Implementors should document > > which routines are implemented as macros ***or otherwise > > non-interceptable***. (End of advice to implementors.) > > > > Advice to users. If these routines are implemented > > as macros ***or otherwise non-interceptable***, they will not > > work with the MPI profiling interface. (End of advice to users.) > > > > > > But for an Erratum, it should be a minimal change. > > Currently, C applications can test wether a MPI_Wtime macro is > > defined. > > There is no need to change this. > > > > For Fortran, I learnt from these mails, that we Need to scpecify > > the > > outcome: non-intereptable. > > > I’m still concerned about making a distinction between Fortran and C > that is entirely artificial. If a Fortran program wants to avoid > interception of MPI_WTICK, for example, it is trivial to write a > wrapper C function my_wtick_ that contains the macro for MPI_Wtick. > Macros in C are just another form of inlining. I think it would be > better to merge together text from Martin and Rolf to end up with > something simpler and clearer: > > > An implementation is allowed to implement MPI_WTIME, > MPI_WTICK, PMPI_WTIME, PMPI_WTICK, MPI_SIZEOF, PMPI_SIZEOF, and the > handle- > and status-conversion functions (MPI_Group_f2c, etc.) > in Sections 17.2.4 and 17.2.5, and no others, such that they are not > interceptable. > > 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 > as not interceptable, they will not > work with the MPI profiling interface. (End of advice to users.) > > > > > > > > > Best regards > > Rolf > > > > ----- Original Message ----- > >> From: "N.M. Maclaren" <nmm1(a)cam.ac.uk> > >> To: "MPI-WG Fortran working group" > >> <mpiwg-fortran(a)lists.mpi-forum.org> > >> Cc: mpiwg-tools(a)lists.mpi-forum.org > >> Sent: Sunday, May 18, 2014 12:02:32 PM > >> Subject: Re: [MPIWG Fortran] [mpiwg-tools] Proposal: MPI_SIZEOF > >> not profiled > >> > >> On May 18 2014, Martin Schulz wrote: > >>> > >>> I agree with what you are planning to propose, I am not sure, > >>> though, the > >>> wording is quite right, and with this I mean more the wording in > >>> the > >>> existing standard: this sound like as if all these functions are > >>> still > >>> interceptable in Fortran. > >>> > >>> What if we say: > >>> > >>> An implementation is allowed to implement MPI_WTIME, MPI_WTICK, > >>> PMPI_WTIME, PMPI_WTICK, MPI_SIZEOF, PMPI_SIZEOF, and the > >>> handle-conversion > >>> functions (MPI_Group_f2c, etc.) in Section 17.2.4, and no others, > >>> as > >>> macros in C or allow them to be inlined. > >>> > >>> Advice to implementors. Implementors should document which > >>> routines > >>> are > >>> implemented as macros or are implemented so that they can be > >>> inlined. (End > >>> of advice to implementors.) > >>> > >>> Advice to users. If these routines are implemented as macros or > >>> are > >>> inlined, they will not work with the MPI profiling interface. > >>> (End > >>> of > >>> advice to users.) > >> > >> Basically, what you are doing is spelling out what the term > >> 'inline' > >> means in MPI, but it is STILL technically wrong and remains > >> confusing. > >> Lots of compilers generate multiple calling sequences with > >> different > >> properties - that is near-universal for library calls, but isn't > >> rare > >> for highly optimised user ones. Well, those are not inlined, and > >> not > >> interceptable. > >> > >> That is also true in C and C++, incidentally, where the word > >> 'inline' > >> means two subtly different things, neither of which is > >> particularly > >> close to the concept on 'inlining' being debated in this thread. > >> But > >> that mess originated in C99, where 'inline' had a LOT of > >> opposition > >> on > >> precisely these grounds. > >> > >> It is far better to say what you mean, that say something which > >> most > >> people believe is equivalent, because it won't be for all > >> compilers > >> or > >> necessarily so in the future. > >> > >> > >> Regards, > >> Nick Maclaren. > >> > >> > >> _______________________________________________ > >> 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 > > 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 > > > _______________________________________________ > 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] [mpiwg-tools] Proposal: MPI_SIZEOF not profiled
by N.M. Maclaren 19 May '14

19 May '14

On May 19 2014, Bill Long wrote: > > I'm still concerned about making a distinction between Fortran and C that > is entirely artificial. If a Fortran program wants to avoid interception > of MPI_WTICK, for example, it is trivial to write a wrapper C function > my_wtick_ that contains the macro for MPI_Wtick. Macros in C are just > another form of inlining. I think it would be better to merge together > text from Martin and Rolf to end up with something simpler and clearer: > > > An implementation is allowed to implement MPI_WTIME, MPI_WTICK, > PMPI_WTIME, PMPI_WTICK, MPI_SIZEOF, PMPI_SIZEOF, and the handle- and > status-conversion functions (MPI_Group_f2c, etc.) in Sections 17.2.4 and > 17.2.5, and no others, such that they are not interceptable. > > 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 > as not interceptable, they will not > work with the MPI profiling interface. (End of advice to users.) Yes! That says precisely what it means and leaves any special code generated for those functions as entirely the implementor's business. Regards, Nick Maclaren.

1 0