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

Re: [MPIWG Fortran] MPI-3.0 Fortran errata latex integration: Reviews requested
by Jeff Squyres (jsquyres) 28 May '14

28 May '14

Thank you! Fixed. On May 27, 2014, at 7:51 AM, Hubert Ritzdorf <Hubert.Ritzdorf(a)emea.nec.com> wrote: > Hi Jeff, > > I have reviewed it and found 1 missing change: > > oldwin must be of TYPE (MPI_Win) in Functions MPI_WIN_DUP_FN and MPI_WIN_NULL_COPY_FN > (Page 730, Line 43; Page 731, Line 3) > > Best regards > > Hubert > ________________________________________ > From: mpiwg-fortran [mpiwg-fortran-bounces(a)lists.mpi-forum.org] on behalf of Jeff Squyres (jsquyres) [jsquyres(a)cisco.com] > Sent: Monday, May 26, 2014 8:08 PM > To: MPI-WG Fortran working group > Subject: Re: [MPIWG Fortran] MPI-3.0 Fortran errata latex integration: Reviews requested > > Has anyone had a chance to review this text yet, perchance? > > On May 14, 2014, at 12:54 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > >> I have integrated all the MPI-3.0 Fortran-related errata as of this morning into the MPI-3.1 tree latex. It is not committed in the SVN MPI-3.1 tree because I'd like to get reviews first. >> >> Per Forum direction, I did *not* use the latex change macros. Instead, we're relying on diffs to review the changes. >> >> Once I get 2-3 reviews to ensure that I have applied the errata properly, I'll commit all of it to the official MPI-3.1 SVN tree. >> >> ----- >> >> Here's how I've made the changes available for review: >> >> 0. All the files listed below are available here: >> >> http://www.open-mpi.org/~jsquyres/mpi-forum/ >> >> 1. A PDF of the entire standard is there; all Fortran-related errata have been applied. You should proof this document. To know exactly what to proof in this PDF, however, see the follow documents... >> >> 2. I also put my copy of errata-30.pdf there, including BRIGHT RED annotations indicating which errata items I incorporated into the PDF from #1. >> >> 3. I also posted a tarball of a git tree where I did my work (NOTE: because this git tree includes the entire latex source, it is behind a trivial password. Email me to get it). There are 36 commits; each commit is the application of an individual errata item. You can use normal git commands to view the diffs. For example: >> >> tar xf mpi-3.1-tree-with-fortran-errata-applied-git.tar.bz2 >> cd mpi-3.1 >> git log >> # ...see all my individual commits... >> git show c126721 >> # ...see the trivial addition of Type(MPI_Message) into the annex... >> >> 4. Or, if you don't like/know git, the individual patch files (numbered in order) are also available. For example: >> >> See a list of all the individual patches at >> http://www.open-mpi.org/~jsquyres/mpi-forum/individual-patches/ >> >> See an individual patch: >> wget http://www.open-mpi.org/~jsquyres/mpi-forum/individual-patches/0033-Add-TYP… >> >> -- >> 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 > > > -- > 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 > > > Click https://www.mailcontrol.com/sr/qREHYrD4RTjGX2PQPOmvUmGqEHcKtgpy8ZM81Cw5Nx3o… 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 -- 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] MPI-3.0 Fortran errata latex integration: Reviews requested
by Hubert Ritzdorf 27 May '14

27 May '14

Hi Jeff, I have reviewed it and found 1 missing change: oldwin must be of TYPE (MPI_Win) in Functions MPI_WIN_DUP_FN and MPI_WIN_NULL_COPY_FN (Page 730, Line 43; Page 731, Line 3) Best regards Hubert ________________________________________ From: mpiwg-fortran [mpiwg-fortran-bounces(a)lists.mpi-forum.org] on behalf of Jeff Squyres (jsquyres) [jsquyres(a)cisco.com] Sent: Monday, May 26, 2014 8:08 PM To: MPI-WG Fortran working group Subject: Re: [MPIWG Fortran] MPI-3.0 Fortran errata latex integration: Reviews requested Has anyone had a chance to review this text yet, perchance? On May 14, 2014, at 12:54 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > I have integrated all the MPI-3.0 Fortran-related errata as of this morning into the MPI-3.1 tree latex. It is not committed in the SVN MPI-3.1 tree because I'd like to get reviews first. > > Per Forum direction, I did *not* use the latex change macros. Instead, we're relying on diffs to review the changes. > > Once I get 2-3 reviews to ensure that I have applied the errata properly, I'll commit all of it to the official MPI-3.1 SVN tree. > > ----- > > Here's how I've made the changes available for review: > > 0. All the files listed below are available here: > > http://www.open-mpi.org/~jsquyres/mpi-forum/ > > 1. A PDF of the entire standard is there; all Fortran-related errata have been applied. You should proof this document. To know exactly what to proof in this PDF, however, see the follow documents... > > 2. I also put my copy of errata-30.pdf there, including BRIGHT RED annotations indicating which errata items I incorporated into the PDF from #1. > > 3. I also posted a tarball of a git tree where I did my work (NOTE: because this git tree includes the entire latex source, it is behind a trivial password. Email me to get it). There are 36 commits; each commit is the application of an individual errata item. You can use normal git commands to view the diffs. For example: > > tar xf mpi-3.1-tree-with-fortran-errata-applied-git.tar.bz2 > cd mpi-3.1 > git log > # ...see all my individual commits... > git show c126721 > # ...see the trivial addition of Type(MPI_Message) into the annex... > > 4. Or, if you don't like/know git, the individual patch files (numbered in order) are also available. For example: > > See a list of all the individual patches at > http://www.open-mpi.org/~jsquyres/mpi-forum/individual-patches/ > > See an individual patch: > wget http://www.open-mpi.org/~jsquyres/mpi-forum/individual-patches/0033-Add-TYP… > > -- > 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 -- 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 Click https://www.mailcontrol.com/sr/qREHYrD4RTjGX2PQPOmvUmGqEHcKtgpy8ZM81Cw5Nx3o… to report this email as spam.

1 0

Re: [MPIWG Fortran] MPI-3.0 Fortran errata latex integration: Reviews requested
by Jeff Squyres (jsquyres) 26 May '14

26 May '14

Has anyone had a chance to review this text yet, perchance? On May 14, 2014, at 12:54 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > I have integrated all the MPI-3.0 Fortran-related errata as of this morning into the MPI-3.1 tree latex. It is not committed in the SVN MPI-3.1 tree because I'd like to get reviews first. > > Per Forum direction, I did *not* use the latex change macros. Instead, we're relying on diffs to review the changes. > > Once I get 2-3 reviews to ensure that I have applied the errata properly, I'll commit all of it to the official MPI-3.1 SVN tree. > > ----- > > Here's how I've made the changes available for review: > > 0. All the files listed below are available here: > > http://www.open-mpi.org/~jsquyres/mpi-forum/ > > 1. A PDF of the entire standard is there; all Fortran-related errata have been applied. You should proof this document. To know exactly what to proof in this PDF, however, see the follow documents... > > 2. I also put my copy of errata-30.pdf there, including BRIGHT RED annotations indicating which errata items I incorporated into the PDF from #1. > > 3. I also posted a tarball of a git tree where I did my work (NOTE: because this git tree includes the entire latex source, it is behind a trivial password. Email me to get it). There are 36 commits; each commit is the application of an individual errata item. You can use normal git commands to view the diffs. For example: > > tar xf mpi-3.1-tree-with-fortran-errata-applied-git.tar.bz2 > cd mpi-3.1 > git log > # ...see all my individual commits... > git show c126721 > # ...see the trivial addition of Type(MPI_Message) into the annex... > > 4. Or, if you don't like/know git, the individual patch files (numbered in order) are also available. For example: > > See a list of all the individual patches at > http://www.open-mpi.org/~jsquyres/mpi-forum/individual-patches/ > > See an individual patch: > wget http://www.open-mpi.org/~jsquyres/mpi-forum/individual-patches/0033-Add-TYP… > > -- > 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 -- 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 Martin Schulz 21 May '14

21 May '14

I fully agree - we won’t have all people at the meeting, but I have already added the ticket to the tools WG slot and we’ll come up with at least a draft that we can discuss via email after the meeting. The earlier we get this done, the better. Martin ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://scalability.llnl.gov/ CASC @ Lawrence Livermore National Laboratory, Livermore, USA On 5/21/14, 12:11 AM, "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> wrote: >Yes, to take the time is a good idea, but best would be to >take the time now and having the final text latest at the end >of this meeting. To make a 3 month pause would not help. > >And for me, the result goes in this direction: >> >Allow for all these special cases that they are non-interceptable, >> >and require that the PMPI version is still available, >> >and to mention "macro in C" only as an "e.g.", >> >and the list includes the existing list plus MPI_SIZEOF >> >plus status conversion routines. >> >Due to the problems in the existing wording, and with MPI_SIZEOF, >> >I would propose it as an erratum, that is needed for MPI-3.1. > >Best regards >Rolf > >----- Original Message ----- >> From: "Martin Schulz" <schulzm(a)llnl.gov> >> To: mpiwg-tools(a)lists.mpi-forum.org >> Cc: "MPI-WG Fortran working group" <mpiwg-fortran(a)lists.mpi-forum.org> >> Sent: Tuesday, May 20, 2014 1:40:26 AM >> Subject: Re: [mpiwg-tools] [MPIWG Fortran] Proposal: MPI_SIZEOF not >>profiled >> >> Hi Rolf, >> >> I agree and (I think) so does Jeff - I think Jeff’s point was only >> that we >> should take the time and get the wording right. We can still bring >> this up >> as an errata item in Japan and it will get into MPI 3.1. >> >> Sound OK? >> >> Martin >> >> ________________________________________________________________________ >> Martin Schulz, schulzm(a)llnl.gov, http://scalability.llnl.gov/ >> CASC @ Lawrence Livermore National Laboratory, Livermore, USA >> >> >> >> >> >> >> >> >> On 5/19/14, 1:49 PM, "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> >> wrote: >> >> >I'll be not at the June Meeting in Chicago. My apologies. >> > >> >For me, the solution is now nearly clear: >> >Allow for all these special cases that they are non-interceptable, >> >and require that the PMPI Version is still available, >> >and to mention "macro in C" only as an "e.g.", >> >and the list includes the existing list plus MPI_SIZEOF >> >plus status conversion routines. >> >Du to the problems in the existing wording, and with MPI_SIZEOF, >> >I would propose it as an erratum, that is needed for MPI-3.1. >> > >> >Best regards >> >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: mpiwg-tools(a)lists.mpi-forum.org >> >> Sent: Monday, May 19, 2014 8:19:58 PM >> >> Subject: Re: [mpiwg-tools] [MPIWG Fortran] Proposal: MPI_SIZEOF >> >> not >> >>profiled >> >> >> >> Ok. Will any other Fortran people be there? (besides me) >> >> >> >> >> >> On May 19, 2014, at 2:03 PM, Martin Schulz <schulzm(a)llnl.gov> >> >> wrote: >> >> >> >> > Yes, sounds like it - I¹ll take 428 off the list then. We should >> >> > take some >> >> > time on Monday afternoon as part of the tools WG time to talk >> >> > about >> >> > this. >> >> > >> >> > Martin >> >> > >> >> > >> >>>>_______________________________________________________________________ >>>>_ >> >> > Martin Schulz, schulzm(a)llnl.gov, http://scalability.llnl.gov/ >> >> > CASC @ Lawrence Livermore National Laboratory, Livermore, USA >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > On 5/19/14, 8:35 AM, "Jeff Squyres (jsquyres)" >> >> > <jsquyres(a)cisco.com> >> >> > wrote: >> >> > >> >> >> 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/ >> >> >> >> >> >> _______________________________________________ >> >> >> mpiwg-tools mailing list >> >> >> mpiwg-tools(a)lists.mpi-forum.org >> >> >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >> >> > >> >> > >> >> > _______________________________________________ >> >> > 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-tools mailing list >> >> mpiwg-tools(a)lists.mpi-forum.org >> >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >> >> >> > >> >-- >> >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-tools mailing list >> >mpiwg-tools(a)lists.mpi-forum.org >> >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >> >> >> _______________________________________________ >> mpiwg-tools mailing list >> mpiwg-tools(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > >-- >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-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] [mpiwg-tools] Proposal: MPI_SIZEOF not profiled
by Rolf Rabenseifner 21 May '14

21 May '14

Yes, to take the time is a good idea, but best would be to take the time now and having the final text latest at the end of this meeting. To make a 3 month pause would not help. And for me, the result goes in this direction: > >Allow for all these special cases that they are non-interceptable, > >and require that the PMPI version is still available, > >and to mention "macro in C" only as an "e.g.", > >and the list includes the existing list plus MPI_SIZEOF > >plus status conversion routines. > >Due to the problems in the existing wording, and with MPI_SIZEOF, > >I would propose it as an erratum, that is needed for MPI-3.1. Best regards Rolf ----- Original Message ----- > From: "Martin Schulz" <schulzm(a)llnl.gov> > To: mpiwg-tools(a)lists.mpi-forum.org > Cc: "MPI-WG Fortran working group" <mpiwg-fortran(a)lists.mpi-forum.org> > Sent: Tuesday, May 20, 2014 1:40:26 AM > Subject: Re: [mpiwg-tools] [MPIWG Fortran] Proposal: MPI_SIZEOF not profiled > > Hi Rolf, > > I agree and (I think) so does Jeff - I think Jeff’s point was only > that we > should take the time and get the wording right. We can still bring > this up > as an errata item in Japan and it will get into MPI 3.1. > > Sound OK? > > Martin > > ________________________________________________________________________ > Martin Schulz, schulzm(a)llnl.gov, http://scalability.llnl.gov/ > CASC @ Lawrence Livermore National Laboratory, Livermore, USA > > > > > > > > > On 5/19/14, 1:49 PM, "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> > wrote: > > >I'll be not at the June Meeting in Chicago. My apologies. > > > >For me, the solution is now nearly clear: > >Allow for all these special cases that they are non-interceptable, > >and require that the PMPI Version is still available, > >and to mention "macro in C" only as an "e.g.", > >and the list includes the existing list plus MPI_SIZEOF > >plus status conversion routines. > >Du to the problems in the existing wording, and with MPI_SIZEOF, > >I would propose it as an erratum, that is needed for MPI-3.1. > > > >Best regards > >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: mpiwg-tools(a)lists.mpi-forum.org > >> Sent: Monday, May 19, 2014 8:19:58 PM > >> Subject: Re: [mpiwg-tools] [MPIWG Fortran] Proposal: MPI_SIZEOF > >> not > >>profiled > >> > >> Ok. Will any other Fortran people be there? (besides me) > >> > >> > >> On May 19, 2014, at 2:03 PM, Martin Schulz <schulzm(a)llnl.gov> > >> wrote: > >> > >> > Yes, sounds like it - I¹ll take 428 off the list then. We should > >> > take some > >> > time on Monday afternoon as part of the tools WG time to talk > >> > about > >> > this. > >> > > >> > Martin > >> > > >> > > >>________________________________________________________________________ > >> > Martin Schulz, schulzm(a)llnl.gov, http://scalability.llnl.gov/ > >> > CASC @ Lawrence Livermore National Laboratory, Livermore, USA > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > On 5/19/14, 8:35 AM, "Jeff Squyres (jsquyres)" > >> > <jsquyres(a)cisco.com> > >> > wrote: > >> > > >> >> 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/ > >> >> > >> >> _______________________________________________ > >> >> mpiwg-tools mailing list > >> >> mpiwg-tools(a)lists.mpi-forum.org > >> >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > >> > > >> > > >> > _______________________________________________ > >> > 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-tools mailing list > >> mpiwg-tools(a)lists.mpi-forum.org > >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > >> > > > >-- > >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-tools mailing list > >mpiwg-tools(a)lists.mpi-forum.org > >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools -- 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 Martin Schulz 19 May '14

19 May '14

Hi Rolf, I agree and (I think) so does Jeff - I think Jeff’s point was only that we should take the time and get the wording right. We can still bring this up as an errata item in Japan and it will get into MPI 3.1. Sound OK? Martin ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://scalability.llnl.gov/ CASC @ Lawrence Livermore National Laboratory, Livermore, USA On 5/19/14, 1:49 PM, "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> wrote: >I'll be not at the June Meeting in Chicago. My apologies. > >For me, the solution is now nearly clear: >Allow for all these special cases that they are non-interceptable, >and require that the PMPI Version is still available, >and to mention "macro in C" only as an "e.g.", >and the list includes the existing list plus MPI_SIZEOF >plus status conversion routines. >Du to the problems in the existing wording, and with MPI_SIZEOF, >I would propose it as an erratum, that is needed for MPI-3.1. > >Best regards >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: mpiwg-tools(a)lists.mpi-forum.org >> Sent: Monday, May 19, 2014 8:19:58 PM >> Subject: Re: [mpiwg-tools] [MPIWG Fortran] Proposal: MPI_SIZEOF not >>profiled >> >> Ok. Will any other Fortran people be there? (besides me) >> >> >> On May 19, 2014, at 2:03 PM, Martin Schulz <schulzm(a)llnl.gov> wrote: >> >> > Yes, sounds like it - I¹ll take 428 off the list then. We should >> > take some >> > time on Monday afternoon as part of the tools WG time to talk about >> > this. >> > >> > Martin >> > >> > >>________________________________________________________________________ >> > Martin Schulz, schulzm(a)llnl.gov, http://scalability.llnl.gov/ >> > CASC @ Lawrence Livermore National Laboratory, Livermore, USA >> > >> > >> > >> > >> > >> > >> > >> > >> > On 5/19/14, 8:35 AM, "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> >> > wrote: >> > >> >> 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/ >> >> >> >> _______________________________________________ >> >> mpiwg-tools mailing list >> >> mpiwg-tools(a)lists.mpi-forum.org >> >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >> > >> > >> > _______________________________________________ >> > 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-tools mailing list >> mpiwg-tools(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >> > >-- >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-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] [mpiwg-tools] Proposal: MPI_SIZEOF not profiled
by Rolf Rabenseifner 19 May '14

19 May '14

I'll be not at the June Meeting in Chicago. My apologies. For me, the solution is now nearly clear: Allow for all these special cases that they are non-interceptable, and require that the PMPI Version is still available, and to mention "macro in C" only as an "e.g.", and the list includes the existing list plus MPI_SIZEOF plus status conversion routines. Du to the problems in the existing wording, and with MPI_SIZEOF, I would propose it as an erratum, that is needed for MPI-3.1. Best regards 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: mpiwg-tools(a)lists.mpi-forum.org > Sent: Monday, May 19, 2014 8:19:58 PM > Subject: Re: [mpiwg-tools] [MPIWG Fortran] Proposal: MPI_SIZEOF not profiled > > Ok. Will any other Fortran people be there? (besides me) > > > On May 19, 2014, at 2:03 PM, Martin Schulz <schulzm(a)llnl.gov> wrote: > > > Yes, sounds like it - I¹ll take 428 off the list then. We should > > take some > > time on Monday afternoon as part of the tools WG time to talk about > > this. > > > > Martin > > > > ________________________________________________________________________ > > Martin Schulz, schulzm(a)llnl.gov, http://scalability.llnl.gov/ > > CASC @ Lawrence Livermore National Laboratory, Livermore, USA > > > > > > > > > > > > > > > > > > On 5/19/14, 8:35 AM, "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> > > wrote: > > > >> 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/ > >> > >> _______________________________________________ > >> mpiwg-tools mailing list > >> mpiwg-tools(a)lists.mpi-forum.org > >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > > > > > > _______________________________________________ > > 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-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > -- 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 Jeff Squyres (jsquyres) 19 May '14

19 May '14

Ok. Will any other Fortran people be there? (besides me) On May 19, 2014, at 2:03 PM, Martin Schulz <schulzm(a)llnl.gov> wrote: > Yes, sounds like it - I¹ll take 428 off the list then. We should take some > time on Monday afternoon as part of the tools WG time to talk about this. > > Martin > > ________________________________________________________________________ > Martin Schulz, schulzm(a)llnl.gov, http://scalability.llnl.gov/ > CASC @ Lawrence Livermore National Laboratory, Livermore, USA > > > > > > > > > On 5/19/14, 8:35 AM, "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> wrote: > >> 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/ >> >> _______________________________________________ >> mpiwg-tools mailing list >> mpiwg-tools(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > > > _______________________________________________ > 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

inline in C and C++
by Craig Rasmussen 19 May '14

19 May '14

Hi Nick, I saw your recent post to the MPI Fortran working group. I recently ran into a problem with some code I was trying to compile on my new Mac Pro. Apple's compiler now by default follow the latest C standard (2011 I think?). So I was running into warning's that suggested the C codes usage of inline wouldn't be treated the same as the GNU compiler. Since it wasn't my code I had no idea what the original programmers intended so I compiled the code using flags for standard GNU usage. Can you explain the difference between inline for C and C++? I have this sinking feeling that neither C nor C++ does what I intuitively want it to do. I've been using inline in C++ for a couple of years but now and I'm pondering using it in C. Are you going to the Las Vegas WG5 meeting? I will be going. In the future, I'm going to try and hit all of the WG5 meetings and start to pick up on some of the J3 meetings. I have a little bit of funding at the University of Oregon that I can spend on this. Thanks, Craig

1 0

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

19 May '14

Yes, sounds like it - I¹ll take 428 off the list then. We should take some time on Monday afternoon as part of the tools WG time to talk about this. Martin ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://scalability.llnl.gov/ CASC @ Lawrence Livermore National Laboratory, Livermore, USA On 5/19/14, 8:35 AM, "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> wrote: >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/ > >_______________________________________________ >mpiwg-tools mailing list >mpiwg-tools(a)lists.mpi-forum.org >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools

1 0