April 2013 - mpiwg-tools - mailman3.cels.anl.gov

[Mpi3-tools] MPIT 3.1: look up by name
by Kathryn Mohror 30 Apr '13

30 Apr '13

Hi all, I've started to work on 3.1 items. The first one is to allow the look up of variables by name instead of having to iterate through all variables until you find the one you want (assuming you know the name in advance). What do people think of this for supporting that functionality: MPI_T_CVAR_GET_INFO_NAMED IN name OUT cvar_index OUT verbosity OUT datatype OUT enumtype OUT desc INOUT desc_len OUT bind OUT scope MPI_T_CVAR_GET_INFO_NAMED behaves similarly to MPI_T_CVAR_GET_INFO except that the lookup is done by control variable name instead of its index. All restrictions and requirements for MPI_T_CVAR_GET_INFO are the same for MPI_GET_CVAR_INFO_NAMED except that the cvar_index is now returned from the function, and name is an input. Then define MPI_T_PVAR_GET_INFO_NAMED in a similar fashion. Thoughts? Objections? Kathryn ______________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://people.llnl.gov/mohror1 CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA

1 0

Re: [Mpi3-tools] [MPI3 Fortran] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
by Bill Long 22 Apr '13

22 Apr '13

On 4/22/13 3:09 AM, Tobias Burnus wrote: > Bill Long wrote: >>> 2) The Fortran implementation will take the performance penalty of using >>> a wrapper routine to perform the operation (discounting sophisticated >>> IPA/WPA (interprocedural analysis/whole program analysis)). Taking this >>> performance penalty is common but not universal. >>> >> >> I agree there will be call overhead for the user who accesses MPI >> through the include file mechanism, unless, as you say, there is a >> sophisticated IPA/WPA mode in the compiler. However, the compiler >> does not have to be all that sophisticated to inline a module >> routine. The compiler has to know how to find the module information >> at compile time, and could have access to all the information needed >> to inline the wrapper. > > My possibly wrong impression is that only the Cray Fortran compiler does > so. I think most (all?) other compiler have a .mod file which contains > the interface of the procedures but not the procedure code itself. > Hence, they do not do any inlining at this stage. Those compilers will > presumably only do this kind of optimization with multi-file > interprocedural optimization (IPO)/link-time optimization (LTO). > > That crayftn does this inlining earlier is probably also a consequence > of (by default) storing the module-interface information in the .o file > instead of using a separate .mod file. If one already has the .o file, > considering IPO is more obvious than if assembler code and module > information are separated into .mod and .o files. The Cray compiler has a switch (-em) that causes module information to be put into .mod files instead of the .o file. This was added mainly to accommodate dependency rules in exiting Make files. Inlining of module procedures by CCE is unaffected by which method (.mod or .o) the user chooses. I'm aware that some compilers are more aggressive about inlining than others, which is why is wrote "could have access" instead of "will have access" or "has access". On the other hand, most compilers routinely inline intrinsics and procedures defined in intrinsic modules, so the technology is available to inline "known" routines. There is nothing to prevent them from treating the mpi and mpi_f08 modules that are accessed from known locations the same way they treat intrinsic modules. The key difference with module procedures (or internal procedures or procedures defined in the same source file) is that there is no ambiguity as to what procedure is being referenced, so it is theoretically possible to inline on the spot. Any particular compiler may or may not take advantage of this. For a non-module or submodule procedure or that is defined in a different file, you don't know until the link step what actual procedure is being referenced (unless there are specific compiler options to point to the desired procedure). Waiting until the link step requires a more "heroic" effort. Cheers, Bill > > * * * > > Regarding the latest PDF, I also have two nits: > > * [p.13,ll. 5-17] The example lists several directives to disable TKR > checks. It should add the following* to the list: > !GCC$ ATTRIBUTES NO_ARG_CHECK > which GCC/gfortran now supports.* > > * [p.17] The TS29113 reference should be updated now that it is an > approved ISO Technical Specification. Additionally, the name has now an > "of Fortran" in the name: "Further Interoperability of Fortran with C" > and latest draft (FDTS) is N1942, which contains some minor changes. See > http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnu… > and ftp://ftp.nag.co.uk/sc22wg5/N1901-N1950/N1942.pdf > > > Tobias > > * Cf. http://gcc.gnu.org/gcc-4.9/changes.html -- Bill Long longb(a)cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101

1 0

Re: [Mpi3-tools] [MPI3 Fortran] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
by Tobias Burnus 22 Apr '13

22 Apr '13

Bill Long wrote: >> 2) The Fortran implementation will take the performance penalty of using >> a wrapper routine to perform the operation (discounting sophisticated >> IPA/WPA (interprocedural analysis/whole program analysis)). Taking this >> performance penalty is common but not universal. >> > > I agree there will be call overhead for the user who accesses MPI > through the include file mechanism, unless, as you say, there is a > sophisticated IPA/WPA mode in the compiler. However, the compiler > does not have to be all that sophisticated to inline a module > routine. The compiler has to know how to find the module information > at compile time, and could have access to all the information needed > to inline the wrapper. My possibly wrong impression is that only the Cray Fortran compiler does so. I think most (all?) other compiler have a .mod file which contains the interface of the procedures but not the procedure code itself. Hence, they do not do any inlining at this stage. Those compilers will presumably only do this kind of optimization with multi-file interprocedural optimization (IPO)/link-time optimization (LTO). That crayftn does this inlining earlier is probably also a consequence of (by default) storing the module-interface information in the .o file instead of using a separate .mod file. If one already has the .o file, considering IPO is more obvious than if assembler code and module information are separated into .mod and .o files. * * * Regarding the latest PDF, I also have two nits: * [p.13,ll. 5-17] The example lists several directives to disable TKR checks. It should add the following* to the list: !GCC$ ATTRIBUTES NO_ARG_CHECK which GCC/gfortran now supports.* * [p.17] The TS29113 reference should be updated now that it is an approved ISO Technical Specification. Additionally, the name has now an "of Fortran" in the name: "Further Interoperability of Fortran with C" and latest draft (FDTS) is N1942, which contains some minor changes. See http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnu… and ftp://ftp.nag.co.uk/sc22wg5/N1901-N1950/N1942.pdf Tobias * Cf. http://gcc.gnu.org/gcc-4.9/changes.html

1 0

Re: [Mpi3-tools] [MPI3 Fortran] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
by Bill Long 21 Apr '13

21 Apr '13

On 4/21/13 10:57 AM, William Gropp wrote: > > There appears to be the following major implicit assumptions: > > 1) Tools will not define a Fortran interface that defines the MPI > routines but rely on intercepting either the corresponding C routine > (current practice) or some wrapper routine (this document, hence the > definition of the wrapper names). Some tools do implement the Fortran > interface in Fortran. My interpretation is that the long term goal is to have only one implementation of the actual workings of each MPI routine, and that routine has the C name and calling conventions. This certainly simplifies implementation and maintenance of the MPI library routines. It seems that it makes the tools simpler as well. The proposal allows for that style of implementation in MPI 3. Whether that becomes the only allowed style sometime in the future is out of scope for this proposal. But getting experience with it would be useful input to that later discussion, and that requires it being at least permitted now. > > 2) The Fortran implementation will take the performance penalty of using > a wrapper routine to perform the operation (discounting sophisticated > IPA/WPA (interprocedural analysis/whole program analysis)). Taking this > performance penalty is common but not universal. > I agree there will be call overhead for the user who accesses MPI through the include file mechanism, unless, as you say, there is a sophisticated IPA/WPA mode in the compiler. However, the compiler does not have to be all that sophisticated to inline a module routine. The compiler has to know how to find the module information at compile time, and could have access to all the information needed to inline the wrapper. This might even encourage users to cross that scary 1990 barrier and switch to using the modules instead of include files. That would be a good thing. Cheers, Bill -- Bill Long longb(a)cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101

1 0

Re: [Mpi3-tools] [MPI3 Fortran] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
by Jeff Hammond 21 Apr '13

21 Apr '13

On Sun, Apr 21, 2013 at 10:57 AM, William Gropp <wgropp(a)illinois.edu> wrote: > Only g77 typically maps Foo_foo (in Fortran) to Foo_foo__ (double trailing > underscore); if the Fortran name contains no underscore, only a single > underscore is appended, so Foofoo goes to foofoo_ (I know of no Fortran > compiler that has exactly the behavior in the text). gfortran uses a single > trailing underscore, for example. g95 also generates double-underscoring by default but now that gfortran has proper support for modern Fortran, I don't see much use of this compiler. Jeff -- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute jhammond(a)alcf.anl.gov / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond ALCF docs: http://www.alcf.anl.gov/user-guides

1 0

Re: [Mpi3-tools] [MPI3 Fortran] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
by William Gropp 21 Apr '13

21 Apr '13

This is better motivated than the earlier version that I read, but I still have problems with the underlying assumptions. Though this is not explicitly stated, but is implied by the advice to users, the goal is to enable the use of tools that exploit the profiling library from Fortran (hint: this needs to be at the top of the first paragraph), as well as repair the error introduced in the f08 module with respect to the use of BIND(C). There appears to be the following major implicit assumptions: 1) Tools will not define a Fortran interface that defines the MPI routines but rely on intercepting either the corresponding C routine (current practice) or some wrapper routine (this document, hence the definition of the wrapper names). Some tools do implement the Fortran interface in Fortran. 2) The Fortran implementation will take the performance penalty of using a wrapper routine to perform the operation (discounting sophisticated IPA/WPA (interprocedural analysis/whole program analysis)). Taking this performance penalty is common but not universal. Neither of these is addressed directly. I understand why tools builders would like to be able to define a single set of routines and then use them with all languages (or implement the tool in one language but call from any), but this scheme is complex. I may also misunderstand the intent of the section, but in that case, I doubt people who haven't attended the forum will have much better luck. I recommend two things: 1) start with a clearer set of goals and constraints. Explain why other choices are not viable. 2) reconsider the consequences of the choices. Minor errors: Only g77 typically maps Foo_foo (in Fortran) to Foo_foo__ (double trailing underscore); if the Fortran name contains no underscore, only a single underscore is appended, so Foofoo goes to foofoo_ (I know of no Fortran compiler that has exactly the behavior in the text). gfortran uses a single trailing underscore, for example. The description of the macros says that the macro "must not be available" (available is the same as defined, so #ifdef can be used to check for availability) but then appears to define the value in this case as the value zero. The rationale on page 6, lines 17-23 talks about "After a compiler provides …". What I believe is really meant is: "Should a subsequent release of a compiler used to build the object or library files provide the facilities of TS29113 when the version use to build the original object or library files did not, and IF THAT VERSION OF THE COMPILER GENERATES CODE THAT IS BINARY COMPATIBLE WITH CODE GENERATED BY THE PREVIOUS VERSION, THEN <remaining text about not needed to recompile other parts of the code in this case>." The text in upper case is important - the text as it is promises something that the MPI standard cannot guarantee. William Gropp Director, Parallel Computing Institute Deputy Director for Research Institute for Advanced Computing Applications and Technologies Thomas M. Siebel Chair in Computer Science University of Illinois Urbana-Champaign On Apr 18, 2013, at 3:22 AM, Rolf Rabenseifner wrote: > <binding-2_Sec.17.1.5_2013-04-18.pdf>

1 0

Re: [Mpi3-tools] Next telecon tomorrow 4/18
by Rolf Rabenseifner 19 Apr '13

19 Apr '13

Dear Kathryn and all, I try to answer to the concerns mentioned at the telecon on April 18, 2013 an in your notes about this telecon: ( https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Tools/notes-2013-04-18 ) > - Concerns raised: > - This complicated scheme means that implementors and tool developers > need to become Fortran experts. We would need a standardized > wrapper generator to help with complexity. In principle, whether there are only two linker names, e.g., - MPI_Isend (for the C MPI routine), and - mpi_isend__ (for the Fortran MPI routine, mapped from Fortran MPI_ISEND to this linker name through the mpi module and in mpif.h together with the Fortran compiler's compiler-dependent linker name mangling), or whether there are some more linker names with marginal changes in the argument list, e.g., - mpi_isend__ uses INTEGER handles - mpi_isend_f08__ uses these TYPE(MPI_Comm) handles, etc. should not be a great deal. With the new MPI-3.0, a profiling provider must mainly compile the same set of profiling wrappers several times with small modifications. These modifications are full systematic and apply to: - Which linker name must be used. - How handle arguments are done (this is only a theoretical aspect because old-style INTEGER handles and new-style TYPE(MPI_Comm) ... handles are internally the same: INTEGER. - How the buffer arguments are passed: this is the only real new stuff. - Whether the ierror argument is optional or not. - How Fortran callback procedures are passed (this is also as in MPI-2) Therefore it looks complicated, but it is not. I do not plan to write and additional advice to users for the user that are tools provider. I hope this email is enough to resolve this concern. > - What if application developers choose to call the various > linker names directly instead of the high level MPI call? I'll add an advice to users at page 6 line 40 in binding-2_Sec.17.1.5_2013-04-18.pdf (see previous email): Advice to users. The additional C routines MPI_..._cdesc, MPI_..._f08cb, and MPI_..._fcb for the implementation schemes B2 an B3 should not be called by application program, i.e., an application program that uses these {\em internal} routines does not conform to this \MPI/ standard. These routine names and their interfaces are standardized only for profiling purpose, i.e., that the routines can be intercepted with a profiling wrapper that internally calls the corresponding PMPI_..._cdesc, PMPI_..._f08cb, and PMPI_..._fcb routines. These additional MPI_... and PMPI_... C routines are not or only partially available if B2 and B3 is not or only partially used in the implementation of an \MPI/ library. This is described with the macros as follows. End of advice to users. I hope that this is clear enough, and that this advice resolves the second concern. Best regards Rolf ----- Original Message ----- > From: "Kathryn Mohror" <kathryn(a)llnl.gov> > To: mpi3-tools(a)lists.mpi-forum.org > Sent: Thursday, April 18, 2013 10:31:07 PM > Subject: Re: [Mpi3-tools] Next telecon tomorrow 4/18 > Hi Rolf, > > > Thanks for the corrections and additions. I updated the wiki > accordingly. > > > Kathryn > > > > On Apr 18, 2013, at 12:31 PM, Rolf Rabenseifner < rabenseifner(a)hlrs.de > > > wrote: > > > Dear kathryn, > > Good catch, here only a few small corrections and additions: > > 1) > Now, in Fortran if you declare the buffer in a particular way, the > compiler produces a descriptor instead of using a pointer, where a > descriptor is a pointer plus some description of the buffer. > --> > Now, in Fortran if the MPI library (in the mpi_f08 or mpi module or > mpif.h) declares the buffer .... > > 2) > different linker names for routines in MPI applications. > --> > different linker names for the same MPI operation. > The appropriate mapping of the MPI call is done through > the specifications within the mpi_f08 or mpi module or mpif.h > > 3) > After "Some routines will be able to be intercepted ...": > - Special macros in mpi.h report to the tools, which linker names are > provided > and whether interception through the C interface is available. > Based on these macros, all needed tool wrappers can be generated. > > Best regards > Rolf > > > > ----- Original Message ----- > > > From: "Kathryn Mohror" < kathryn(a)llnl.gov > > To: mpi3-tools(a)lists.mpi-forum.org > Sent: Thursday, April 18, 2013 9:14:06 PM > Subject: Re: [Mpi3-tools] Next telecon tomorrow 4/18 > Hi all, > > > For anyone who missed the call, I put some notes on the wiki. > Hopefully, I got the Fortran details right. Anyone with more expertise > in Fortran than I have is welcome to correct me! > > > Kathryn > > > > On Apr 17, 2013, at 10:13 AM, Kathryn Mohror < kathryn(a)llnl.gov > > wrote: > > > > Hi all, > > > This is a reminder of our next telecon tomorrow 4/18 at 8:00 AM PDT, > 11:00 AM EDT. The Webex information is posted on the wiki: > https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Tools > > > I expect the main topic of discussion will be the issues dealing with > the new Fortran interface in MPI-3 as they relate to tools. Rolf and > Craig will join the call to fill us in on the details. > > > If there is time, other topics may include: > - MPI_Pcontrol Fortran problem > - Updates to the MQS document > - Possible change in telecon time to accommodate changed schedules > - What is the openMP tools WG doing for DLL loading? > - Status of ticket #357, threading problems in MPI-3 > > > Kathryn > > > > ______________________________________________________________ > Kathryn Mohror, kathryn(a)llnl.gov , http://people.llnl.gov/mohror1 > CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA > > > > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > > > ______________________________________________________________ > Kathryn Mohror, kathryn(a)llnl.gov , http://people.llnl.gov/mohror1 > CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA > > > > > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-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) > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > > > > ______________________________________________________________ > Kathryn Mohror, kathryn(a)llnl.gov , http://people.llnl.gov/mohror1 > CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA > > > > > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-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: [Mpi3-tools] Next telecon tomorrow 4/18
by Kathryn Mohror 18 Apr '13

18 Apr '13

Hi Rolf, Thanks for the corrections and additions. I updated the wiki accordingly. Kathryn On Apr 18, 2013, at 12:31 PM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: > Dear kathryn, > > Good catch, here only a few small corrections and additions: > > 1) > Now, in Fortran if you declare the buffer in a particular way, the compiler produces a descriptor instead of using a pointer, where a descriptor is a pointer plus some description of the buffer. > --> > Now, in Fortran if the MPI library (in the mpi_f08 or mpi module or mpif.h) declares the buffer .... > > 2) > different linker names for routines in MPI applications. > --> > different linker names for the same MPI operation. > The appropriate mapping of the MPI call is done through > the specifications within the mpi_f08 or mpi module or mpif.h > > 3) > After "Some routines will be able to be intercepted ...": > - Special macros in mpi.h report to the tools, which linker names are provided > and whether interception through the C interface is available. > Based on these macros, all needed tool wrappers can be generated. > > Best regards > Rolf > > > > ----- Original Message ----- >> From: "Kathryn Mohror" <kathryn(a)llnl.gov> >> To: mpi3-tools(a)lists.mpi-forum.org >> Sent: Thursday, April 18, 2013 9:14:06 PM >> Subject: Re: [Mpi3-tools] Next telecon tomorrow 4/18 >> Hi all, >> >> >> For anyone who missed the call, I put some notes on the wiki. >> Hopefully, I got the Fortran details right. Anyone with more expertise >> in Fortran than I have is welcome to correct me! >> >> >> Kathryn >> >> >> >> On Apr 17, 2013, at 10:13 AM, Kathryn Mohror < kathryn(a)llnl.gov > >> wrote: >> >> >> >> Hi all, >> >> >> This is a reminder of our next telecon tomorrow 4/18 at 8:00 AM PDT, >> 11:00 AM EDT. The Webex information is posted on the wiki: >> https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Tools >> >> >> I expect the main topic of discussion will be the issues dealing with >> the new Fortran interface in MPI-3 as they relate to tools. Rolf and >> Craig will join the call to fill us in on the details. >> >> >> If there is time, other topics may include: >> - MPI_Pcontrol Fortran problem >> - Updates to the MQS document >> - Possible change in telecon time to accommodate changed schedules >> - What is the openMP tools WG doing for DLL loading? >> - Status of ticket #357, threading problems in MPI-3 >> >> >> Kathryn >> >> >> >> ______________________________________________________________ >> Kathryn Mohror, kathryn(a)llnl.gov , http://people.llnl.gov/mohror1 >> CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA >> >> >> >> >> _______________________________________________ >> Mpi3-tools mailing list >> Mpi3-tools(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >> >> >> >> ______________________________________________________________ >> Kathryn Mohror, kathryn(a)llnl.gov , http://people.llnl.gov/mohror1 >> CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA >> >> >> >> >> >> _______________________________________________ >> Mpi3-tools mailing list >> Mpi3-tools(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-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) > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools ______________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://people.llnl.gov/mohror1 CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA

1 0

Re: [Mpi3-tools] Next telecon tomorrow 4/18
by Rolf Rabenseifner 18 Apr '13

18 Apr '13

Dear kathryn, Good catch, here only a few small corrections and additions: 1) Now, in Fortran if you declare the buffer in a particular way, the compiler produces a descriptor instead of using a pointer, where a descriptor is a pointer plus some description of the buffer. --> Now, in Fortran if the MPI library (in the mpi_f08 or mpi module or mpif.h) declares the buffer .... 2) different linker names for routines in MPI applications. --> different linker names for the same MPI operation. The appropriate mapping of the MPI call is done through the specifications within the mpi_f08 or mpi module or mpif.h 3) After "Some routines will be able to be intercepted ...": - Special macros in mpi.h report to the tools, which linker names are provided and whether interception through the C interface is available. Based on these macros, all needed tool wrappers can be generated. Best regards Rolf ----- Original Message ----- > From: "Kathryn Mohror" <kathryn(a)llnl.gov> > To: mpi3-tools(a)lists.mpi-forum.org > Sent: Thursday, April 18, 2013 9:14:06 PM > Subject: Re: [Mpi3-tools] Next telecon tomorrow 4/18 > Hi all, > > > For anyone who missed the call, I put some notes on the wiki. > Hopefully, I got the Fortran details right. Anyone with more expertise > in Fortran than I have is welcome to correct me! > > > Kathryn > > > > On Apr 17, 2013, at 10:13 AM, Kathryn Mohror < kathryn(a)llnl.gov > > wrote: > > > > Hi all, > > > This is a reminder of our next telecon tomorrow 4/18 at 8:00 AM PDT, > 11:00 AM EDT. The Webex information is posted on the wiki: > https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Tools > > > I expect the main topic of discussion will be the issues dealing with > the new Fortran interface in MPI-3 as they relate to tools. Rolf and > Craig will join the call to fill us in on the details. > > > If there is time, other topics may include: > - MPI_Pcontrol Fortran problem > - Updates to the MQS document > - Possible change in telecon time to accommodate changed schedules > - What is the openMP tools WG doing for DLL loading? > - Status of ticket #357, threading problems in MPI-3 > > > Kathryn > > > > ______________________________________________________________ > Kathryn Mohror, kathryn(a)llnl.gov , http://people.llnl.gov/mohror1 > CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA > > > > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > > > ______________________________________________________________ > Kathryn Mohror, kathryn(a)llnl.gov , http://people.llnl.gov/mohror1 > CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA > > > > > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-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: [Mpi3-tools] Next telecon tomorrow 4/18
by Kathryn Mohror 18 Apr '13

18 Apr '13

Hi all, For anyone who missed the call, I put some notes on the wiki. Hopefully, I got the Fortran details right. Anyone with more expertise in Fortran than I have is welcome to correct me! Kathryn On Apr 17, 2013, at 10:13 AM, Kathryn Mohror <kathryn(a)llnl.gov> wrote: > Hi all, > > This is a reminder of our next telecon tomorrow 4/18 at 8:00 AM PDT, 11:00 AM EDT. The Webex information is posted on the wiki: https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Tools > > I expect the main topic of discussion will be the issues dealing with the new Fortran interface in MPI-3 as they relate to tools. Rolf and Craig will join the call to fill us in on the details. > > If there is time, other topics may include: > - MPI_Pcontrol Fortran problem > - Updates to the MQS document > - Possible change in telecon time to accommodate changed schedules > - What is the openMP tools WG doing for DLL loading? > - Status of ticket #357, threading problems in MPI-3 > > Kathryn > ______________________________________________________________ > Kathryn Mohror, kathryn(a)llnl.gov, http://people.llnl.gov/mohror1 > CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA > > > > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools ______________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://people.llnl.gov/mohror1 CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA

1 0