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

Re: [mpiwg-tools] [MPIWG Fortran] 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-tools] Ticket #383 -- Final text?
by Kathryn Mohror 19 May '14

19 May '14

Jeff, Is this what you want for the text, attached? Kathryn _________________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA On 5/19/14, 8:03 AM, "Bronis R. de Supinski" <bronis(a)llnl.gov> wrote: > >"sufficiently long enough" is redundant; "sufficiently long" >is sufficient. > >On Mon, 19 May 2014, Jeff Squyres (jsquyres) wrote: > >> On May 18, 2014, at 2:35 AM, Martin Schulz <schulzm(a)llnl.gov> wrote: >> >>> Hi Kathryn, all, >>> >>> A few comments: >>> - "Adhere to the same definition from the MPI implementation.² - not >>>sure >>> what we meant with this anymore. Perhaps we should just drop this part. >> >> What I meant by that is that each MPI implementation will create a >>definition for each cvar/pvar/etc. The implementation must adhere to >>that same definition in all connected processes. I.e., it can't change >>the definition of exactly what that variable is in different processes >>(e.g., bytes_in = bytes received from TCP in one process, but bytes >>received across shared memory in another process). >> >>> - "OUT index values² is not correct, since index values are IN >>>parameters >>> to the get_info calls. Perhaps just drop OUT? >> >> Good catch; missed that. Yes, this whole clause can go. >> >>> - The mandate of equal OUT/INPUT values is also not quite right - for >>>the >>> strings, it¹s OK to return substrings of the size argument is too >>>small. I >>> know that¹s a technicality, but I am not sure if this causes problems >>> later down the road. >> >> Mmm. Good point. So the current text is: >> >> * Return the same INOUT and OUT values from the relevant >>MPI_T_*_GET_INFO function. >> >> (I took the liberty of dropping the index value clause) >> >> I notice that we actually return 3 kinds of things from GET_INFO >>functions: integers/enums, strings, and MPI handles (i.e., >>MPI_Datatype). So how about this: >> >> * Return the same INOUT and OUT integer and enum values from the >>relevant MPI_T_*_GET_INFO function. >> * If sufficiently long enough string length IN parameters are supplied, >>return the same string OUT parameters from the relevant MPI_T_*_GET_INFO >>function. >> * Return a handle to an equivalent MPI object from the relevant >>MPI_T_*_GET_INFO function. >> >> >> >> -- >> Jeff Squyres >> jsquyres(a)cisco.com >> For corporate legal information go to: >>http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> _______________________________________________ >> mpiwg-tools mailing list >> mpiwg-tools(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools

1 0

Re: [mpiwg-tools] Ticket #383 -- Final text?
by Bronis R. de Supinski 19 May '14

19 May '14

"sufficiently long enough" is redundant; "sufficiently long" is sufficient. On Mon, 19 May 2014, Jeff Squyres (jsquyres) wrote: > On May 18, 2014, at 2:35 AM, Martin Schulz <schulzm(a)llnl.gov> wrote: > >> Hi Kathryn, all, >> >> A few comments: >> - "Adhere to the same definition from the MPI implementation.占쏙옙 - not sure >> what we meant with this anymore. Perhaps we should just drop this part. > > What I meant by that is that each MPI implementation will create a definition for each cvar/pvar/etc. The implementation must adhere to that same definition in all connected processes. I.e., it can't change the definition of exactly what that variable is in different processes (e.g., bytes_in = bytes received from TCP in one process, but bytes received across shared memory in another process). > >> - "OUT index values占쏙옙 is not correct, since index values are IN parameters >> to the get_info calls. Perhaps just drop OUT? > > Good catch; missed that. Yes, this whole clause can go. > >> - The mandate of equal OUT/INPUT values is also not quite right - for the >> strings, it占쏙옙s OK to return substrings of the size argument is too small. I >> know that占쏙옙s a technicality, but I am not sure if this causes problems >> later down the road. > > Mmm. Good point. So the current text is: > > * Return the same INOUT and OUT values from the relevant MPI_T_*_GET_INFO function. > > (I took the liberty of dropping the index value clause) > > I notice that we actually return 3 kinds of things from GET_INFO functions: integers/enums, strings, and MPI handles (i.e., MPI_Datatype). So how about this: > > * Return the same INOUT and OUT integer and enum values from the relevant MPI_T_*_GET_INFO function. > * If sufficiently long enough string length IN parameters are supplied, return the same string OUT parameters from the relevant MPI_T_*_GET_INFO function. > * Return a handle to an equivalent MPI object from the relevant MPI_T_*_GET_INFO function. > > > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools

1 0

Re: [mpiwg-tools] Ticket #383 -- Final text?
by Jeff Squyres (jsquyres) 19 May '14

19 May '14

On May 18, 2014, at 2:35 AM, Martin Schulz <schulzm(a)llnl.gov> wrote: > Hi Kathryn, all, > > A few comments: > - "Adhere to the same definition from the MPI implementation.” - not sure > what we meant with this anymore. Perhaps we should just drop this part. What I meant by that is that each MPI implementation will create a definition for each cvar/pvar/etc. The implementation must adhere to that same definition in all connected processes. I.e., it can't change the definition of exactly what that variable is in different processes (e.g., bytes_in = bytes received from TCP in one process, but bytes received across shared memory in another process). > - "OUT index values” is not correct, since index values are IN parameters > to the get_info calls. Perhaps just drop OUT? Good catch; missed that. Yes, this whole clause can go. > - The mandate of equal OUT/INPUT values is also not quite right - for the > strings, it’s OK to return substrings of the size argument is too small. I > know that’s a technicality, but I am not sure if this causes problems > later down the road. Mmm. Good point. So the current text is: * Return the same INOUT and OUT values from the relevant MPI_T_*_GET_INFO function. (I took the liberty of dropping the index value clause) I notice that we actually return 3 kinds of things from GET_INFO functions: integers/enums, strings, and MPI handles (i.e., MPI_Datatype). So how about this: * Return the same INOUT and OUT integer and enum values from the relevant MPI_T_*_GET_INFO function. * If sufficiently long enough string length IN parameters are supplied, return the same string OUT parameters from the relevant MPI_T_*_GET_INFO function. * Return a handle to an equivalent MPI object from the relevant MPI_T_*_GET_INFO function. -- 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-tools] Ticket #383 -- Final text?
by Kathryn Mohror 19 May '14

19 May '14

Jeff, since you wrote this text, what do you think of Martin’s comments? Kathryn _________________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA On 5/17/14, 11:35 PM, "Martin Schulz" <schulzm(a)llnl.gov> wrote: >Hi Kathryn, all, > >A few comments: >- "Adhere to the same definition from the MPI implementation.” - not sure >what we meant with this anymore. Perhaps we should just drop this part. >- "OUT index values” is not correct, since index values are IN parameters >to the get_info calls. Perhaps just drop OUT? >- The mandate of equal OUT/INPUT values is also not quite right - for the >strings, it’s OK to return substrings of the size argument is too small. I >know that’s a technicality, but I am not sure if this causes problems >later down the road. > >The rest looks good to me. > >Thanks, > >Martin > > > > > > > >________________________________________________________________________ >Martin Schulz, schulzm(a)llnl.gov, http://scalability.llnl.gov/ >CASC @ Lawrence Livermore National Laboratory, Livermore, USA > > > > > > > > >On 5/15/14, 2:55 PM, "Kathryn Mohror" <kathryn(a)llnl.gov> wrote: > >>Hi all, >> >>Here¹s the draft for ticket #383 that we want to have voted on in June. >>That means we need to send out the final version on Monday May 19. So, >>have a look and speak up if you don¹t like it ASAP! >> >>Kathryn >> >> >>_________________________________________________________________ >>Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ >>Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, >>USA >> >> >> >> > > >_______________________________________________ >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-tools] Ticket #414: MPI_T: Array of Enumeration Items for Variables
by Kathryn Mohror 19 May '14

19 May '14

No, that was a mistake. It is not ready to be read yet. Thanks for noticing Jeff! Kathryn _________________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA On 5/17/14, 11:38 PM, "Martin Schulz" <schulzm(a)llnl.gov> wrote: >Took it off for now - Kathryn, let me know if you want to change this. > >Martin > >________________________________________________________________________ >Martin Schulz, schulzm(a)llnl.gov, http://scalability.llnl.gov/ >CASC @ Lawrence Livermore National Laboratory, Livermore, USA > > > > > > > > >On 5/16/14, 3:02 AM, "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> wrote: > >>Ticket 414 is listed as being up for a reading in Chicago. >> >>But AFAICS, it's only got a photo of a whiteboard sketch attached to it >>-- there's no proposed text. >> >>Kathryn: do you have some text somewhere about this ticket? >> >>If not, I'm thinking that #414 should be removed from the list of tickets >>to be read in Chicago. >> >>-- >>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-tools mailing list >mpiwg-tools(a)lists.mpi-forum.org >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools

1 0

Re: [mpiwg-tools] Ticket #414: MPI_T: Array of Enumeration Items for Variables
by Martin Schulz 18 May '14

18 May '14

Took it off for now - Kathryn, let me know if you want to change this. Martin ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://scalability.llnl.gov/ CASC @ Lawrence Livermore National Laboratory, Livermore, USA On 5/16/14, 3:02 AM, "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> wrote: >Ticket 414 is listed as being up for a reading in Chicago. > >But AFAICS, it's only got a photo of a whiteboard sketch attached to it >-- there's no proposed text. > >Kathryn: do you have some text somewhere about this ticket? > >If not, I'm thinking that #414 should be removed from the list of tickets >to be read in Chicago. > >-- >Jeff Squyres >jsquyres(a)cisco.com >For corporate legal information go to: >http://www.cisco.com/web/about/doing_business/legal/cri/ > >_______________________________________________ >mpiwg-tools mailing list >mpiwg-tools(a)lists.mpi-forum.org >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools

1 0

Re: [mpiwg-tools] Ticket #383 -- Final text?
by Martin Schulz 18 May '14

18 May '14

Hi Kathryn, all, A few comments: - "Adhere to the same definition from the MPI implementation.” - not sure what we meant with this anymore. Perhaps we should just drop this part. - "OUT index values” is not correct, since index values are IN parameters to the get_info calls. Perhaps just drop OUT? - The mandate of equal OUT/INPUT values is also not quite right - for the strings, it’s OK to return substrings of the size argument is too small. I know that’s a technicality, but I am not sure if this causes problems later down the road. The rest looks good to me. Thanks, Martin ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://scalability.llnl.gov/ CASC @ Lawrence Livermore National Laboratory, Livermore, USA On 5/15/14, 2:55 PM, "Kathryn Mohror" <kathryn(a)llnl.gov> wrote: >Hi all, > >Here¹s the draft for ticket #383 that we want to have voted on in June. >That means we need to send out the final version on Monday May 19. So, >have a look and speak up if you don¹t like it ASAP! > >Kathryn > > >_________________________________________________________________ >Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ >Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, >USA > > > >

1 0

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

17 May '14

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

16 May '14

On May 16, 2014, at 11:24 AM, Jeff Squyres <jsquyres(a)cisco.com> wrote: > To be clear, here's what I'm currently proposing: GAH! I copied-pasted too much; the last one I sent was incorrect. Sorry for the confusion! There is sufficient interest in this such that I made a ticket and put the definitive version there: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/428 We can keep discussing here in this thread, but at least the definitive text is now on the ticket. -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0