July 2011 - mpiwg-tools - mailman3.cels.anl.gov

[Mpi3-tools] Results from the MPI_T reading / Open issues and next steps
by Martin Schulz 20 Jul '11

20 Jul '11

Hi all, We had a formal reading at this week's MPI forum in Chicago. We did get a lot of feedback and, while many comments were focusing on grammar and language, we also had a few more technical issues which were considered not ticket 0: - The naming issue came up. The single "T" wasn't received well, but people could live with it, if alternatives (like MPI_Tools) are too long (I'll see what fits). If you have ant good ideas what could be there instead of Tools please let me know. - Either way, to conform with MPI naming conversion, we need to change the first upper case letter to lower case, i.e.: MPI_T_Cvar_get_info we need MPI_T_cvar_get_info - One comment was that the things measured by the Pvar interface are almost entirely (all?) unsigned values and hence we should switch to unsigned data types (or at least include them). Also, we should include MPI_LONG. - Some people (especially for platforms with lean OSes) didn't like the signal safety text - I will create a rewrite and send that around for discussion - It was suggested to add a "non-atomic" flag to Pvar_get_info to identify variables that are cannot be passed to Pvar_readreset. I will update the text to reflect these comments (in the next 1-2 weeks) and will send that around. After that we will arrange a phone call to go over any open issues. If there are any comments on the issues raised before that, please let me know. Thanks, Martin

1 0

[Mpi3-tools] New draft for MPI_T available
by Martin Schulz 05 Jul '11

05 Jul '11

Hi all, Thank you all for the many comments on the latest draft of the MPI_T. I have added them to the document and made the new document available on the WikI (tools WG and ticket #266). I will use this version (minus potential ticket #0 corrections) for the reading in July. Martin ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0

Re: [Mpi3-tools] Comments/Questions on Fortran 08 Bindings
by Jeff Squyres (jsquyres) 02 Jul '11

02 Jul '11

See below. I answered only those which weren't alread answered. Sent from my phone. No type good. On Jul 1, 2011, at 3:14 AM, "Marc-Andre Hermanns" <m.a.hermanns(a)grs-sim.de> wrote: > Dear Martin, > > I gathered some feedback from some of the Scalasca team members on the > proposed changes to profiling with the Fortran 08 interface. > > The Scalasca measurement adapter currently creates the Fortran wrappers > for each of the four name-mangling schemes automatically (CPP macros), > as the wrapper is the same, just the symbol name is different. Another > name-mangling scheme for the same wrapper would probably not hurt very much. > > However, some questions arose in the discussions that I have to admit > might stem from our limited knowledge of Fortran and Fortran 08 in > particular. > > 1) Are the Fortran handle types compatible/interchangeable with the C > handle types, or will c2f/f2c still have to be called? > You will still need to call c2f/f2c. MPI f08 handles != MPI mpif or use MPI handles, and != C handles. > 2) Just as John Mellor-Crummey commented: are there standardized > routines to handle the array descriptors in C and C++ which are the > primary languages to implement a measurement layer? If not, how to deal > with it? Can it be interpreted as a void*? How to compare against > MPI_BOTTOM? > > 3) If the Fortran 08-C/C++ interface for the descriptors is not > available. Does it mean I have to implement the wrappers in Fortran? No. > Didn't we just agree that MPI_T does not need Fortran bindings? In this > case it would need them again, right? No. > 4) How is the support for '_f' for just the MPI functions to be done in > the Fortran compiler? Won't it be mangled to '_f_' or '_f__' again? What > are the actual benefits of this '_f'? > There will only be one symbol tools need to worry about: _f. If compilers mangle it further, tools won't know or care. > 5) Why deviate from the existing MPI_STATUS_IGNORE in favor of inflating > the API? Is there a real need for it? > > I can easily imagine users of the Fortran 08 interface, while fixing > some older MPI code written with the Fortran 77 interface, to get > confused about the (in 77) non-optional status parameter. > > 7) Along the lines of Todd's comment on function overloading: It would > be great if the _f08 and _f09_nostatus could just be the same > measurement wrapper, to keep maintenance of measurement code to a minimum. > > Cheers, > Marc-Andre > -- > Marc-Andre Hermanns > German Research School for > Simulation Sciences GmbH > c/o Laboratory for Parallel Programming > 52056 Aachen | Germany > > Tel +49 241 80 99753 > Fax +49 241 80 6 99753 > Web www.grs-sim.de > > Members: Forschungszentrum Jülich GmbH | RWTH Aachen University > Registered in the commercial register of the local court of > Düren (Amtsgericht Düren) under registration number HRB 5268 > Registered office: Jülich > Executive board: Prof. Marek Behr Ph.D. | Dr. Norbert Drewes > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools

1 0

Re: [Mpi3-tools] Comments/Questions on Fortran 08 Bindings
by Martin Schulz 02 Jul '11

02 Jul '11

Hi Marc-Andre, Thanks for gathering the input - this is helpful. I have cc-ed the Fortran WG on this reply, since all of the questions are directed to them. Hopefully we can clarify some of this during the TelCon on Wednesday - I hope and/or some other people from JSC can make it. Martin On Jul 1, 2011, at 1:14 AM, Marc-Andre Hermanns wrote: > Dear Martin, > > I gathered some feedback from some of the Scalasca team members on the > proposed changes to profiling with the Fortran 08 interface. > > The Scalasca measurement adapter currently creates the Fortran wrappers > for each of the four name-mangling schemes automatically (CPP macros), > as the wrapper is the same, just the symbol name is different. Another > name-mangling scheme for the same wrapper would probably not hurt very much. > > However, some questions arose in the discussions that I have to admit > might stem from our limited knowledge of Fortran and Fortran 08 in > particular. > > 1) Are the Fortran handle types compatible/interchangeable with the C > handle types, or will c2f/f2c still have to be called? > > 2) Just as John Mellor-Crummey commented: are there standardized > routines to handle the array descriptors in C and C++ which are the > primary languages to implement a measurement layer? If not, how to deal > with it? Can it be interpreted as a void*? How to compare against > MPI_BOTTOM? > > 3) If the Fortran 08-C/C++ interface for the descriptors is not > available. Does it mean I have to implement the wrappers in Fortran? > Didn't we just agree that MPI_T does not need Fortran bindings? In this > case it would need them again, right? > > 4) How is the support for '_f' for just the MPI functions to be done in > the Fortran compiler? Won't it be mangled to '_f_' or '_f__' again? What > are the actual benefits of this '_f'? > > 5) Why deviate from the existing MPI_STATUS_IGNORE in favor of inflating > the API? Is there a real need for it? > > I can easily imagine users of the Fortran 08 interface, while fixing > some older MPI code written with the Fortran 77 interface, to get > confused about the (in 77) non-optional status parameter. > > 7) Along the lines of Todd's comment on function overloading: It would > be great if the _f08 and _f09_nostatus could just be the same > measurement wrapper, to keep maintenance of measurement code to a minimum. > > Cheers, > Marc-Andre > -- > Marc-Andre Hermanns > German Research School for > Simulation Sciences GmbH > c/o Laboratory for Parallel Programming > 52056 Aachen | Germany > > Tel +49 241 80 99753 > Fax +49 241 80 6 99753 > Web www.grs-sim.de > > Members: Forschungszentrum Jï¿½lich GmbH | RWTH Aachen University > Registered in the commercial register of the local court of > Dï¿½ren (Amtsgericht Dï¿½ren) under registration number HRB 5268 > Registered office: Jï¿½lich > Executive board: Prof. Marek Behr Ph.D. | Dr. Norbert Drewes > > <smime.p7s>_______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0

Re: [Mpi3-tools] Comments/Questions on Fortran 08 Bindings
by Schulz, Martin 02 Jul '11

02 Jul '11

Hi Marc-Andre, Thanks for gathering the input - this is helpful. I have cc-ed the Fortran WG on this reply, since all of the questions are directed to them. Hopefully we can clarify some of this during the TelCon on Wednesday - I hope and/or some other people from JSC can make it. Martin On Jul 1, 2011, at 1:14 AM, Marc-Andre Hermanns wrote: > Dear Martin, > > I gathered some feedback from some of the Scalasca team members on the > proposed changes to profiling with the Fortran 08 interface. > > The Scalasca measurement adapter currently creates the Fortran wrappers > for each of the four name-mangling schemes automatically (CPP macros), > as the wrapper is the same, just the symbol name is different. Another > name-mangling scheme for the same wrapper would probably not hurt very much. > > However, some questions arose in the discussions that I have to admit > might stem from our limited knowledge of Fortran and Fortran 08 in > particular. > > 1) Are the Fortran handle types compatible/interchangeable with the C > handle types, or will c2f/f2c still have to be called? > > 2) Just as John Mellor-Crummey commented: are there standardized > routines to handle the array descriptors in C and C++ which are the > primary languages to implement a measurement layer? If not, how to deal > with it? Can it be interpreted as a void*? How to compare against > MPI_BOTTOM? > > 3) If the Fortran 08-C/C++ interface for the descriptors is not > available. Does it mean I have to implement the wrappers in Fortran? > Didn't we just agree that MPI_T does not need Fortran bindings? In this > case it would need them again, right? > > 4) How is the support for '_f' for just the MPI functions to be done in > the Fortran compiler? Won't it be mangled to '_f_' or '_f__' again? What > are the actual benefits of this '_f'? > > 5) Why deviate from the existing MPI_STATUS_IGNORE in favor of inflating > the API? Is there a real need for it? > > I can easily imagine users of the Fortran 08 interface, while fixing > some older MPI code written with the Fortran 77 interface, to get > confused about the (in 77) non-optional status parameter. > > 7) Along the lines of Todd's comment on function overloading: It would > be great if the _f08 and _f09_nostatus could just be the same > measurement wrapper, to keep maintenance of measurement code to a minimum. > > Cheers, > Marc-Andre > -- > Marc-Andre Hermanns > German Research School for > Simulation Sciences GmbH > c/o Laboratory for Parallel Programming > 52056 Aachen | Germany > > Tel +49 241 80 99753 > Fax +49 241 80 6 99753 > Web www.grs-sim.de > > Members: Forschungszentrum Jï¿½lich GmbH | RWTH Aachen University > Registered in the commercial register of the local court of > Dï¿½ren (Amtsgericht Dï¿½ren) under registration number HRB 5268 > Registered office: Jï¿½lich > Executive board: Prof. Marek Behr Ph.D. | Dr. Norbert Drewes > > <smime.p7s>_______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0

[Mpi3-tools] Tentative: MPI-3 Fortran WG
by Geoffrey Paulsen 01 Jul '11

01 Jul '11

1 0

[Mpi3-tools] Comments/Questions on Fortran 08 Bindings
by Marc-Andre Hermanns 01 Jul '11

01 Jul '11

Dear Martin, I gathered some feedback from some of the Scalasca team members on the proposed changes to profiling with the Fortran 08 interface. The Scalasca measurement adapter currently creates the Fortran wrappers for each of the four name-mangling schemes automatically (CPP macros), as the wrapper is the same, just the symbol name is different. Another name-mangling scheme for the same wrapper would probably not hurt very much. However, some questions arose in the discussions that I have to admit might stem from our limited knowledge of Fortran and Fortran 08 in particular. 1) Are the Fortran handle types compatible/interchangeable with the C handle types, or will c2f/f2c still have to be called? 2) Just as John Mellor-Crummey commented: are there standardized routines to handle the array descriptors in C and C++ which are the primary languages to implement a measurement layer? If not, how to deal with it? Can it be interpreted as a void*? How to compare against MPI_BOTTOM? 3) If the Fortran 08-C/C++ interface for the descriptors is not available. Does it mean I have to implement the wrappers in Fortran? Didn't we just agree that MPI_T does not need Fortran bindings? In this case it would need them again, right? 4) How is the support for '_f' for just the MPI functions to be done in the Fortran compiler? Won't it be mangled to '_f_' or '_f__' again? What are the actual benefits of this '_f'? 5) Why deviate from the existing MPI_STATUS_IGNORE in favor of inflating the API? Is there a real need for it? I can easily imagine users of the Fortran 08 interface, while fixing some older MPI code written with the Fortran 77 interface, to get confused about the (in 77) non-optional status parameter. 7) Along the lines of Todd's comment on function overloading: It would be great if the _f08 and _f09_nostatus could just be the same measurement wrapper, to keep maintenance of measurement code to a minimum. Cheers, Marc-Andre -- Marc-Andre Hermanns German Research School for Simulation Sciences GmbH c/o Laboratory for Parallel Programming 52056 Aachen | Germany Tel +49 241 80 99753 Fax +49 241 80 6 99753 Web www.grs-sim.de Members: Forschungszentrum Jülich GmbH | RWTH Aachen University Registered in the commercial register of the local court of Düren (Amtsgericht Düren) under registration number HRB 5268 Registered office: Jülich Executive board: Prof. Marek Behr Ph.D. | Dr. Norbert Drewes

1 0

Re: [Mpi3-tools] MPI_T - Reviews and Question on Initialization
by Dave Goodell 01 Jul '11

01 Jul '11

On Jun 30, 2011, at 3:22 AM CDT, Martin Schulz wrote: > I am traveling Saturday-Tuesday. I would appreciate > any comments, especially larger changes, before the > weekend. I've made a bunch of "ticket 0" changes directly in the SVN repository already (r858). Here are the notes that I have that may require some group discussion: page 37: Table 2.1 overflows the hbox, but I don't see any obvious way to fix it. Does anyone have a suggestion? page 45: the "obj_handle" argument has a strange type. I expected it to be a "void *", not an "MPI_Aint *" with text about MPI_GET_ADDRESS. Is this right? Whether it is or it isn't, an example would probably go a long way towards clarifying usage of this routine. page 46: "issued by the user consistently in all connected processes" is rather strong for GLOBAL. There's no middle ground between LOCAL and GLOBAL that allows a collective per-communicator setting, for example. I still need to go over the perfvar section more carefully, but I don't think that I'll get to it before the weekend. Hopefully all that I find will be ticket 0 items that are fine to tweak after the 2-week cutoff. -Dave

1 0