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

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:14 AM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: > We need a correct expression telling that it is allowed to be > not interceptable. > > MPI-3.0 wording: "as macro in C." > [does not tell anything about Fortran] Per my other mail, I think we don't want to touch this in an errata. Allowing WTICK/WTIME to be inlined in Fortran -- which I intentionally avoided in the original proposal -- is a new thing, and should wait until MPI-4. My proposal was amended by your prior mail, but I do not like this "Maybe better proposal" you sent. To be clear, here's what I'm currently proposing: ----- An implementation is allowed to implement MPI_WTIME, MPI_WTICK, PMPI_WTIME, PMPI_WTICK, and the handle- ***and status-*** conversion functions (MPI_Group_f2c, etc.) in Section***s*** 17.2.4 ***and 17.2.5***, and no others, as macros in C ***or inlined in Fortran***. ***MPI_SIZEOF may also be inlined.*** Advice to implementors. Implementors should document which routines are implemented as macros ***or otherwise inlined***. (End of advice to implementors.) Advice to users. If these routines are implemented as macros ***or otherwise inlined***, they will not work with the MPI profiling interface. (End of advice to users.) ----- and ----- 1. provide a mechanism through which all of the MPI defined functions, except those allowed as macros ***or otherwise inlined*** (See Section 2.6.4), may be accessed with a name shift. This requires, in C and Fortran, an alternate entry point name, with the prefix PMPI_ for each MPI function in each provided language binding and language support method. For routines implemented as macros ***or otherwise inlined***, it is still required that the PMPI_ version be supplied and work as expected, but it is not possible to replace at link time the MPI_ version with a user-defined version. ------ -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [mpiwg-tools] [MPIWG Fortran] Proposal: MPI_SIZEOF not profiled
by Jeff Squyres (jsquyres) 16 May '14

16 May '14

I agree with everything (good catch on the status conversion routines), but I think the "***or inlined in Fortran***" phrase is a separate/new thing. Fortran was specifically not mentioned in the original text (w.r.t. WTICK and WTIME); if we want to change that, I think that's a separate/new thing. It could have ABI issues, for example, and would therefore have to go to MPI-4. I think the rest of this can go in as errata. On May 16, 2014, at 9:59 AM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: > Samll updates, see below. > > I corrected the page number and I added > - "or inlined in Fortran", and > - the status-conversion routines in 17.2.5 > (They were new in MPI-3.0 and we oversaw that they > have similar quality as handle-conversion routines. > Major difference, they have an out-argument > within the argument list.) > > Do we also consensus in adding the status-conversions > to the macro+inline-allowence? > Or do we need to spilt these two things? > > Rolf > > ----- Original Message ----- >> From: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> >> To: "MPI Fortran WG" <mpiwg-fortran(a)lists.mpi-forum.org>, "MPI Tool WG" <mpiwg-tools(a)lists.mpi-forum.org> >> Sent: Friday, May 16, 2014 2:44:10 PM >> Subject: [MPIWG Fortran] Proposal: MPI_SIZEOF not profiled >> >> Fortran and Tools WGs: >> >> (=== this is a bit urgent if we want to get this read at the Chicago >> meeting; the T-2 deadline is this upcoming Monday morning ===) >> >> We seem to have some measure of consensus on the other thread that >> MPI_SIZEOF should not be profiled. >> >> Note, however, that the Tools chapter currently mandates that PMPI_ >> versions of all MPI routines must be available (including, for >> example, MPI_WTICK), but the MPI_ versions do not have to be >> replaceable at link time. I propose adopting this convention for >> MPI_SIZEOF, too (i.e. we have to provide PMPI_SIZEOF). >> >> Does this wording work as a proposal? >> > MPI-3.0 p19:45 through p20:5 (T&C chapter) currently reads: > (Jeff, you may used a wrong pdf with ther page numbers) >> >> ----- >> An implementation is allowed to implement MPI_WTIME, MPI_WTICK, >> PMPI_WTIME, PMPI_WTICK, and the handle-conversion functions >> (MPI_Group_f2c, etc.) in Section 17.2.4, and no others, as macros in >> C. >> >> Advice to implementors. Implementors should document which routines >> are implemented as macros. (End of advice to implementors.) >> >> Advice to users. If these routines are implemented as macros, they >> will not work with the MPI profiling interface. (End of advice to >> users.) >> ----- >> >> but should read (new text in ***): >> >> ----- >> An implementation is allowed to implement MPI_WTIME, MPI_WTICK, >> PMPI_WTIME, PMPI_WTICK, and the handle- > ***and status-*** >> conversion functions >> (MPI_Group_f2c, etc.) in Section***s*** 17.2.4 ***and 17.2.5***, >> and no others, as macros in C > ***or inlined in Fortran***. >> ***MPI_SIZEOF may also be inlined.*** >> >> Advice to implementors. Implementors should document which routines >> are implemented as macros ***or otherwise inlined***. (End of advice >> to implementors.) >> >> Advice to users. If these routines are implemented as macros ***or >> otherwise inlined***, they will not work with the MPI profiling >> interface. (End of advice to users.) >> ----- >> >> p555:31-37 (first page of the Tools chapter) currently says: >> >> ----- >> 1. provide a mechanism through which all of the MPI defined >> functions, except those allowed as macros (See Section 2.6.4), may >> be accessed with a name shift. This requires, in C and Fortran, an >> alternate entry point name, with the prefix PMPI_ for each MPI >> function in each provided language binding and language support >> method. For routines implemented as macros, it is still required >> that the PMPI_ version be supplied and work as expected, but it is >> not possible to replace at link time the MPI_ version with a >> user-defined version. >> ----- >> >> but should say >> >> ----- >> 1. provide a mechanism through which all of the MPI defined >> functions, except those allowed as macros ***or otherwise inlined*** >> (See Section 2.6.4), may be accessed with a name shift. This >> requires, in C and Fortran, an alternate entry point name, with the >> prefix PMPI_ for each MPI function in each provided language binding >> and language support method. For routines implemented as macros >> ***or otherwise inlined***, it is still required that the PMPI_ >> version be supplied and work as expected, but it is not possible to >> replace at link time the MPI_ version with a user-defined version. >> ----- >> >> -- >> Jeff Squyres >> jsquyres(a)cisco.com >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> _______________________________________________ >> mpiwg-fortran mailing list >> mpiwg-fortran(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran >> > > -- > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran -- 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] [MPIWG Fortran] Proposal: MPI_SIZEOF not profiled
by Hubert Ritzdorf 16 May '14

16 May '14

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

1 0

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

16 May '14

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

1 0

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

16 May '14

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

1 0

Ticket #414: MPI_T: Array of Enumeration Items for Variables
by Jeff Squyres (jsquyres) 16 May '14

16 May '14

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/

1 0

Re: [mpiwg-tools] Profiling for MPI_SIZEOF?
by Martin Schulz 16 May '14

16 May '14

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

1 0

Re: [mpiwg-tools] Meeting reminder for tomorrow May 14
by Kathryn Mohror 15 May '14

15 May '14

Hi all, Notes from the meeting are up: https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Tools/notes-2014-05-15 Kathryn _________________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA From: Wesley Bland <wbland(a)anl.gov> Date: Wednesday, May 14, 2014 at 11:55 AM To: "mpiwg-tools(a)lists.mpi-forum.org" <mpiwg-tools(a)lists.mpi-forum.org> Cc: Kathryn Mohror <kathryn(a)llnl.gov> Subject: Re: [mpiwg-tools] Meeting reminder for tomorrow May 14 Thanks for allowing us to join your call this week. We appreciate getting your feedback on the impact of FT on the tools chapter. There have only been minor changes to the text since the last reading (mostly related to RMA), but the newest version of the text can be found on the ticket: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/323. Thanks, Wesley On Wed, May 14, 2014 at 1:29 PM, Kathryn Mohror <kathryn(a)llnl.gov> wrote: > Hi all, > > This is a reminder of our bi-weekly phone call tomorrow at 8 AM PDT, 11 AM > EDT. > > The agenda will cover MPI_T related topics in preparation for votes at the > June meeting: > > - How does the MPI FT interface affect the tools interface? Members of > the FT Working Group will join to discuss this with us. > - Text for the ³variables with same name must have same meaning² ticket > #383 > - Ticket #358 (new to us, proposed by Rolf) > > As always, the sign in information for the call is on the tools wiki: > https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Tools > > Talk to you soon! > Kathryn > _________________________________________________________________ > Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ > Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA > > From: Kathryn Mohror <kathryn(a)llnl.gov> > Date: Thursday, May 8, 2014 at 8:04 AM > To: "mpiwg-tools(a)lists.mpi-forum.org" <mpiwg-tools(a)lists.mpi-forum.org> > Subject: Re: [mpiwg-tools] Next Telecon Heads Up > > Hi all, > > Sorry! It was not my intention to confuse anyone that the meeting was today! I > only thought that an early heads up would give people time to arrange their > schedules accordingly. > > Kathryn > > On May 8, 2014, at 8:02 AM, Michael Knobloch <m.knobloch(a)fz-juelich.de> wrote: > >> Hi Marc-Andre, >> >> the meeting is next week. I was confused too, so no blame on you. >> >> -Micha >> >> On 05/08/2014 04:05 PM, Marc-Andre Hermanns wrote: >>> Hi Kathryn, >>> >>> I got delayed in another meeting, so I don't know if I can make it in >>> time for the our meeting today. I have to see if I can shuffle my >>> schedule a bit to still join. >>> >>> Please do not wait for me. If I can successfully shuffle I will be there >>> on time, if not, I won't be able to make it anyway. >>> >>> Cheers, >>> Marc-Andre >>> >>> On 07.05.14 21:05, John DelSignore wrote: >>>> Hi Kathryn, >>>> >>>> Unfortunately, last week my boss moved his staff meeting (every Thursday >>>> at 11am ET) right on top of the MPI Tools concall time slot, so I'm not >>>> sure how many of the MPI Tools calls I'll be able to make going forward. >>>> For the handles work, we'll have to find another time. >>>> >>>> Cheers, John D. >>>> >>>> >>>> Kathryn Mohror wrote: >>>>> Hi all, >>>>> >>>>> For our call next week, instead of focusing on the debugger topics as >>>>> we had planned, we¹ll go back to MPI_T topics in the interest of time >>>>> (meaning in time for voting at the next forum meeting). >>>>> >>>>> Topics >>>>> - How does the MPI FT interface affect the tools interface? Members >>>>> of the FT Working Group will join to discuss this with us. >>>>> - Text for the ³variables with same name must have same meaning² >>>>> ticket #383 >>>>> >>>>> So, anyone who is only interested in debugger topics can skip next >>>>> time and we¹ll come back to them next time. >>>>> >>>>> Kathryn >>>>> _________________________________________________________________ >>>>> Kathryn Mohror, kathryn(a)llnl.gov >>>>> <mailto:[email protected]>, 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 >>>> >>> >>> >>> >>> _______________________________________________ >>> mpiwg-tools mailing list >>> mpiwg-tools(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >>> >> >> -- >> Michael Knobloch >> Institute for Advanced Simulation (IAS) >> Jülich Supercomputing Centre (JSC) >> Telefon: +49 2461 61-3546 <tel:%2B49%202461%2061-3546> >> Telefax: +49 2461 61-6656 <tel:%2B49%202461%2061-6656> >> E-Mail: m.knobloch(a)fz-juelich.de >> Internet: http://www.fz-juelich.de/jsc >> >> >> ----------------------------------------------------------------------------- >> ------------------- >> ----------------------------------------------------------------------------- >> ------------------- >> Forschungszentrum Juelich GmbH >> 52425 Juelich >> Sitz der Gesellschaft: Juelich >> Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 >> Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher >> Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), >> Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, >> Prof. Dr. Sebastian M. Schmidt >> ----------------------------------------------------------------------------- >> ------------------- >> ----------------------------------------------------------------------------- >> ------------------- >> >> _______________________________________________ >> mpiwg-tools mailing list >> mpiwg-tools(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > > _________________________________________________________________ > Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ > Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA > > > > > > > >

1 0

Ticket #383 -- Final text?
by Kathryn Mohror 15 May '14

15 May '14

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] Profiling for MPI_SIZEOF?
by Jeff Squyres (jsquyres) 15 May '14

15 May '14

On May 15, 2014, at 4:17 PM, Marc-Andre Hermanns <m.a.hermanns(a)grs-sim.de> wrote: > isn't MPI_SIZEOF also named as a function that is allowed to be > implemented as a macro? Not that I can find -- that's why I'm asking this question... > Also, the call is likely to be so short (in duration) that you'd have a > huge overhead in intercepting it. > > I would also be ok with proposed solution #1. Good. Bill Long is, too. :-) -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0