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

Re: [Mpi3-tools] [MPI3 Fortran] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
by Rolf Rabenseifner 18 Apr '13

18 Apr '13

Late input for our telecon (mpi3-tools) today (Thursday). I added a few corrections, especially page 2, line 44, the macros are in mpi.h and not in mpif.h. Pages and lines of version 2013-04-17 and 2013-04.18 are nearly identical, except additional new line 25 on page 2. Best regards Rolf ----- Original Message ----- > From: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> > To: "MPI-3 Fortran working group" <mpi3-fortran(a)lists.mpi-forum.org>, mpi3-tools(a)lists.mpi-forum.org > Sent: Wednesday, April 17, 2013 7:09:59 PM > Subject: Re: [MPI3 Fortran] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind > Dear all in the Fortran and Tools WGs, > > #364 presents a real bug in the MPI-3.0 Fortran binding of > all three Fortran support methods. > Reason: LOGICAL is used in MPI together with BIND(C), > but LOGICAL is not interoperable with C. > > Based on a lot of help from Bill Long, Craig, Jeff, Tobias, and > Hubert, > I produced a consistent proposal on how to fix the broken Section > 17.1.5. > > It is attached. > > It looks quite long, but most of the text rationale, advices and > examples > to make life a bit easier. > The normative part is similar in length as in the broken section. > > The basics are simple: > - Three implementation schemes: > - A = no BIND(C) > - B = standardized wrapping to the MPI C routines > with strong reporting to the tools people > - C = with BIND(C), but only partial possible and only for > the new mpi_f08. > - A and B works for all MPI routines and all compilers > and all three support methods (mp_f08, mipi, mpif.h). > - B can be combined with A or C. > - B alone would be the most efficient way to implement > the Fortran interface with wrappers to the MPI routines > written in C > - B alone or combined with A/C has the > smallest impact to the tools provider. > - mpif.h and mpi module require A or A+B > for PMPI backward compatibility. > - mpi_f08 can be implemented with A, A+B, B only, C/A, or C/A+B, > i.e., most freedom for the new module. > There is smaller need for backward compatibility > of the profiling interface. > > A+B would be a minimal solution, > A+B+C is similar to what we have in the broken section. > > Because current Section 17.1.5 is broken, it should be fixed > through an erratum. > > Craig and I will be at the tools telecon tomorrow. > I hope, you have time to look at the document > that I can answer your questions tomorrow. > > Best regards > Rolf > > -- > 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-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-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

Re: [Mpi3-tools] Next telecon tomorrow 4/18
by Anh Vo 17 Apr '13

17 Apr '13

Hi all, I'm attaching the latest MQS document so that if we have time tomorrow, we can discuss a bit about it. --Anh From: mpi3-tools-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Kathryn Mohror Sent: Wednesday, April 17, 2013 10:13 AM To: <mpi3-tools(a)lists.mpi-forum.org> Cc: Craig Rasmussen Subject: [Mpi3-tools] Next telecon tomorrow 4/18 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<mailto:[email protected]>, http://people.llnl.gov/mohror1 CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA

1 0

[Mpi3-tools] Next telecon tomorrow 4/18
by Kathryn Mohror 17 Apr '13

17 Apr '13

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

1 0

Re: [Mpi3-tools] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
by Rolf Rabenseifner 17 Apr '13

17 Apr '13

Dear all in the Fortran and Tools WGs, #364 presents a real bug in the MPI-3.0 Fortran binding of all three Fortran support methods. Reason: LOGICAL is used in MPI together with BIND(C), but LOGICAL is not interoperable with C. Based on a lot of help from Bill Long, Craig, Jeff, Tobias, and Hubert, I produced a consistent proposal on how to fix the broken Section 17.1.5. It is attached. It looks quite long, but most of the text rationale, advices and examples to make life a bit easier. The normative part is similar in length as in the broken section. The basics are simple: - Three implementation schemes: - A = no BIND(C) - B = standardized wrapping to the MPI C routines with strong reporting to the tools people - C = with BIND(C), but only partial possible and only for the new mpi_f08. - A and B works for all MPI routines and all compilers and all three support methods (mp_f08, mipi, mpif.h). - B can be combined with A or C. - B alone would be the most efficient way to implement the Fortran interface with wrappers to the MPI routines written in C - B alone or combined with A/C has the smallest impact to the tools provider. - mpif.h and mpi module require A or A+B for PMPI backward compatibility. - mpi_f08 can be implemented with A, A+B, B only, C/A, or C/A+B, i.e., most freedom for the new module. There is smaller need for backward compatibility of the profiling interface. A+B would be a minimal solution, A+B+C is similar to what we have in the broken section. Because current Section 17.1.5 is broken, it should be fixed through an erratum. Craig and I will be at the tools telecon tomorrow. I hope, you have time to look at the document that I can answer your questions tomorrow. Best regards Rolf -- 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] [MPI3 Fortran] Issues with Fortran bindings for MPI_Pcontrol
by William Gropp 16 Apr '13

16 Apr '13

True, but not the original goal, and the current design makes the common case *very* easy for users. A more general but equally easy to use interface would be great, of course. Bill 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 16, 2013, at 12:39 PM, Jeff Squyres (jsquyres) wrote: > But without a portable run-time way to query what tool is being used, it makes it darn difficult to write portable MPI applications that want to tune for multiple different tools. > > > On Apr 16, 2013, at 9:56 AM, William Gropp <wgropp(a)illinois.edu> wrote: > >> The idea was not portability between different tools, but between linking with *a* tool that uses the profiling interface, and without that tool. The varargs interface allows the user to customize for *one* tool, while not needing to change the code to link without the tool. I personally find this sufficient for most needs. >> >> Bill >> >> 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 16, 2013, at 10:56 AM, Marc-Andre Hermanns wrote: >> >>> Hi Martin, >>> >>>>>> On 4/15/13 4:38 PM, Schulz, Martin wrote: >>>>>>> As a first simple approach, this could be done with >>>>>>> >>>>>>> MPI_Pcontrol_new(MPI_Info info) >>>>>> >>>>>> The original question seemed specific to the Fortran interface for MPI_PCONTROL. Would it be possible to keep the C interface, either as is or modified as suggested above, but delete the Fortran interface for this routine? That solves the immediate issue. >>>>>> >>>>>> I would argue that the few people who use this routine are "expert users" who would have little trouble writing their own MY_PCONTROL, written in C but callable from Fortran that had whatever interoperable arguments were desired, and internally called the C MPI_Pcontrol function. >>>>> >>>>> Or not even bother with MPI_Pcontrol, because it's less hassle to >>>>> implement the whole thing from scratch and provide their own interfaces. >>>>> I agree - this isn't likely to impact more than 0.1% of users, who are >>>>> quite capable of resolving any difficulties. >>>> >>>> I don't think that's quite true - Pcontrol is useful in many cases >>>> and is used by profilers (that are advertised as easy to use). It is >>>> certainly a bit more advanced usage, but in many cases we tell users >>>> where to put it, so they can run their code and get data, but it has >>>> to be easy for them to add it or they won't do it. Having to go >>>> through C in Fortran codes is not really a workable solution in this >>>> case. That's also how we ran into the problem that we are discussing: >>>> we had a user new to performance analysis during a tutorial and he >>>> wanted to profile a particular snapshot and so we asked him to add >>>> the calls. Due to the ierr issue, this crashed the code. >>> >>> But where did it crash? In the MPI library or in the profiler? >>> >>>> The only way to make only having a C call work would be a separate >>>> library, but then that defeats the purpose of adding something that >>>> can just stay in the code without having to link to special libraries >>>> (which was the main reason for adding MPI_Pcontrol). MPI_Pcontrol is >>>> (unlike MPI_T) intended to be used in the application code and hence >>>> should have bindings in all languages supported by MPI. >>> >>> What I still don't understand about Pcontrol is that the varargs make it inherently non-portable, or not? I don't mean the "portablility" between C and Fortran, I mean: If the call to MPI_Pcontrol takes anything else than the initial 'level' it will very likely crash with the use of another tool that expects different parameters. If the user has to modify the code for using a different tool to use a feature, I would argue against its portability. >>> >>> I think the only way of handling this portably would be if the call itself, took a handle-like identifier, and the tool itself would implement another call that creates the opaque object behind it. >>> >>> Something along the lines of: >>> >>> int MPI_Pcontrol_create(MPI_Pctrl* handle); >>> int MPI_Pcontrol_free(MPI_Pctrl* handle); >>> >>> The idea is that the Profiling tool would not call PMPI_Pcontrol_create but just create the a structure, do its own book-keeping and return the handle. >>> >>> Then Pcontrol takes this handle (which can transport anything the profiling tool would expect) >>> >>> int MPI_Pcontrol(int level, MPI_Pctrl handle); >>> >>> and maybe something like: >>> >>> int MPI_Pcontrol_set(MPI_Pctrl handle, MPI_Info info); >>> >>> If the tool does not understand some of the infos (because they are meant for a different tool) it ignores it and should use some form of a consistent default state. >>> >>> But I don't know if the latter would really improve over your initial proposal with the info object as a parameter to the Pcontrol call itself, as I don't have any experience with how often one would have to modify the handle. If you have to modify the handle with every call, then you don't gain anything. >>> >>> Cheers, >>> Marc-Andre >>> -- >>> Marc-Andre Hermanns >>> German Research School for >>> Simulation Sciences GmbH >>> c/o Laboratory for Parallel Programming >>> 52062 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 | Prof. Dr. Sebastian M. Schmidt >>> _______________________________________________ >>> Mpi3-tools mailing list >>> Mpi3-tools(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >> >> _______________________________________________ >> Mpi3-tools mailing list >> Mpi3-tools(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > > > _______________________________________________ > 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] [MPI3 Fortran] Issues with Fortran bindings for MPI_Pcontrol
by Jeff Squyres (jsquyres) 16 Apr '13

16 Apr '13

But without a portable run-time way to query what tool is being used, it makes it darn difficult to write portable MPI applications that want to tune for multiple different tools. On Apr 16, 2013, at 9:56 AM, William Gropp <wgropp(a)illinois.edu> wrote: > The idea was not portability between different tools, but between linking with *a* tool that uses the profiling interface, and without that tool. The varargs interface allows the user to customize for *one* tool, while not needing to change the code to link without the tool. I personally find this sufficient for most needs. > > Bill > > 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 16, 2013, at 10:56 AM, Marc-Andre Hermanns wrote: > >> Hi Martin, >> >>>>> On 4/15/13 4:38 PM, Schulz, Martin wrote: >>>>>> As a first simple approach, this could be done with >>>>>> >>>>>> MPI_Pcontrol_new(MPI_Info info) >>>>> >>>>> The original question seemed specific to the Fortran interface for MPI_PCONTROL. Would it be possible to keep the C interface, either as is or modified as suggested above, but delete the Fortran interface for this routine? That solves the immediate issue. >>>>> >>>>> I would argue that the few people who use this routine are "expert users" who would have little trouble writing their own MY_PCONTROL, written in C but callable from Fortran that had whatever interoperable arguments were desired, and internally called the C MPI_Pcontrol function. >>>> >>>> Or not even bother with MPI_Pcontrol, because it's less hassle to >>>> implement the whole thing from scratch and provide their own interfaces. >>>> I agree - this isn't likely to impact more than 0.1% of users, who are >>>> quite capable of resolving any difficulties. >>> >>> I don't think that's quite true - Pcontrol is useful in many cases >>> and is used by profilers (that are advertised as easy to use). It is >>> certainly a bit more advanced usage, but in many cases we tell users >>> where to put it, so they can run their code and get data, but it has >>> to be easy for them to add it or they won't do it. Having to go >>> through C in Fortran codes is not really a workable solution in this >>> case. That's also how we ran into the problem that we are discussing: >>> we had a user new to performance analysis during a tutorial and he >>> wanted to profile a particular snapshot and so we asked him to add >>> the calls. Due to the ierr issue, this crashed the code. >> >> But where did it crash? In the MPI library or in the profiler? >> >>> The only way to make only having a C call work would be a separate >>> library, but then that defeats the purpose of adding something that >>> can just stay in the code without having to link to special libraries >>> (which was the main reason for adding MPI_Pcontrol). MPI_Pcontrol is >>> (unlike MPI_T) intended to be used in the application code and hence >>> should have bindings in all languages supported by MPI. >> >> What I still don't understand about Pcontrol is that the varargs make it inherently non-portable, or not? I don't mean the "portablility" between C and Fortran, I mean: If the call to MPI_Pcontrol takes anything else than the initial 'level' it will very likely crash with the use of another tool that expects different parameters. If the user has to modify the code for using a different tool to use a feature, I would argue against its portability. >> >> I think the only way of handling this portably would be if the call itself, took a handle-like identifier, and the tool itself would implement another call that creates the opaque object behind it. >> >> Something along the lines of: >> >> int MPI_Pcontrol_create(MPI_Pctrl* handle); >> int MPI_Pcontrol_free(MPI_Pctrl* handle); >> >> The idea is that the Profiling tool would not call PMPI_Pcontrol_create but just create the a structure, do its own book-keeping and return the handle. >> >> Then Pcontrol takes this handle (which can transport anything the profiling tool would expect) >> >> int MPI_Pcontrol(int level, MPI_Pctrl handle); >> >> and maybe something like: >> >> int MPI_Pcontrol_set(MPI_Pctrl handle, MPI_Info info); >> >> If the tool does not understand some of the infos (because they are meant for a different tool) it ignores it and should use some form of a consistent default state. >> >> But I don't know if the latter would really improve over your initial proposal with the info object as a parameter to the Pcontrol call itself, as I don't have any experience with how often one would have to modify the handle. If you have to modify the handle with every call, then you don't gain anything. >> >> Cheers, >> Marc-Andre >> -- >> Marc-Andre Hermanns >> German Research School for >> Simulation Sciences GmbH >> c/o Laboratory for Parallel Programming >> 52062 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 | Prof. Dr. Sebastian M. Schmidt >> _______________________________________________ >> Mpi3-tools mailing list >> Mpi3-tools(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools -- 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: [Mpi3-tools] [MPI3 Fortran] Issues with Fortran bindings for MPI_Pcontrol
by William Gropp 16 Apr '13

16 Apr '13

The idea was not portability between different tools, but between linking with *a* tool that uses the profiling interface, and without that tool. The varargs interface allows the user to customize for *one* tool, while not needing to change the code to link without the tool. I personally find this sufficient for most needs. Bill 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 16, 2013, at 10:56 AM, Marc-Andre Hermanns wrote: > Hi Martin, > >>>> On 4/15/13 4:38 PM, Schulz, Martin wrote: >>>>> As a first simple approach, this could be done with >>>>> >>>>> MPI_Pcontrol_new(MPI_Info info) >>>> >>>> The original question seemed specific to the Fortran interface for MPI_PCONTROL. Would it be possible to keep the C interface, either as is or modified as suggested above, but delete the Fortran interface for this routine? That solves the immediate issue. >>>> >>>> I would argue that the few people who use this routine are "expert users" who would have little trouble writing their own MY_PCONTROL, written in C but callable from Fortran that had whatever interoperable arguments were desired, and internally called the C MPI_Pcontrol function. >>> >>> Or not even bother with MPI_Pcontrol, because it's less hassle to >>> implement the whole thing from scratch and provide their own interfaces. >>> I agree - this isn't likely to impact more than 0.1% of users, who are >>> quite capable of resolving any difficulties. >> >> I don't think that's quite true - Pcontrol is useful in many cases >> and is used by profilers (that are advertised as easy to use). It is >> certainly a bit more advanced usage, but in many cases we tell users >> where to put it, so they can run their code and get data, but it has >> to be easy for them to add it or they won't do it. Having to go >> through C in Fortran codes is not really a workable solution in this >> case. That's also how we ran into the problem that we are discussing: >> we had a user new to performance analysis during a tutorial and he >> wanted to profile a particular snapshot and so we asked him to add >> the calls. Due to the ierr issue, this crashed the code. > > But where did it crash? In the MPI library or in the profiler? > >> The only way to make only having a C call work would be a separate >> library, but then that defeats the purpose of adding something that >> can just stay in the code without having to link to special libraries >> (which was the main reason for adding MPI_Pcontrol). MPI_Pcontrol is >> (unlike MPI_T) intended to be used in the application code and hence >> should have bindings in all languages supported by MPI. > > What I still don't understand about Pcontrol is that the varargs make it inherently non-portable, or not? I don't mean the "portablility" between C and Fortran, I mean: If the call to MPI_Pcontrol takes anything else than the initial 'level' it will very likely crash with the use of another tool that expects different parameters. If the user has to modify the code for using a different tool to use a feature, I would argue against its portability. > > I think the only way of handling this portably would be if the call itself, took a handle-like identifier, and the tool itself would implement another call that creates the opaque object behind it. > > Something along the lines of: > > int MPI_Pcontrol_create(MPI_Pctrl* handle); > int MPI_Pcontrol_free(MPI_Pctrl* handle); > > The idea is that the Profiling tool would not call PMPI_Pcontrol_create but just create the a structure, do its own book-keeping and return the handle. > > Then Pcontrol takes this handle (which can transport anything the profiling tool would expect) > > int MPI_Pcontrol(int level, MPI_Pctrl handle); > > and maybe something like: > > int MPI_Pcontrol_set(MPI_Pctrl handle, MPI_Info info); > > If the tool does not understand some of the infos (because they are meant for a different tool) it ignores it and should use some form of a consistent default state. > > But I don't know if the latter would really improve over your initial proposal with the info object as a parameter to the Pcontrol call itself, as I don't have any experience with how often one would have to modify the handle. If you have to modify the handle with every call, then you don't gain anything. > > Cheers, > Marc-Andre > -- > Marc-Andre Hermanns > German Research School for > Simulation Sciences GmbH > c/o Laboratory for Parallel Programming > 52062 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 | Prof. Dr. Sebastian M. Schmidt > _______________________________________________ > 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] [MPI3 Fortran] Issues with Fortran bindings for MPI_Pcontrol
by Marc-Andre Hermanns 16 Apr '13

16 Apr '13

Hi Martin, >>> On 4/15/13 4:38 PM, Schulz, Martin wrote: >>>> As a first simple approach, this could be done with >>>> >>>> MPI_Pcontrol_new(MPI_Info info) >>> >>> The original question seemed specific to the Fortran interface for MPI_PCONTROL. Would it be possible to keep the C interface, either as is or modified as suggested above, but delete the Fortran interface for this routine? That solves the immediate issue. >>> >>> I would argue that the few people who use this routine are "expert users" who would have little trouble writing their own MY_PCONTROL, written in C but callable from Fortran that had whatever interoperable arguments were desired, and internally called the C MPI_Pcontrol function. >> >> Or not even bother with MPI_Pcontrol, because it's less hassle to >> implement the whole thing from scratch and provide their own interfaces. >> I agree - this isn't likely to impact more than 0.1% of users, who are >> quite capable of resolving any difficulties. > > I don't think that's quite true - Pcontrol is useful in many cases > and is used by profilers (that are advertised as easy to use). It is > certainly a bit more advanced usage, but in many cases we tell users > where to put it, so they can run their code and get data, but it has > to be easy for them to add it or they won't do it. Having to go > through C in Fortran codes is not really a workable solution in this > case. That's also how we ran into the problem that we are discussing: > we had a user new to performance analysis during a tutorial and he > wanted to profile a particular snapshot and so we asked him to add > the calls. Due to the ierr issue, this crashed the code. But where did it crash? In the MPI library or in the profiler? > The only way to make only having a C call work would be a separate > library, but then that defeats the purpose of adding something that > can just stay in the code without having to link to special libraries > (which was the main reason for adding MPI_Pcontrol). MPI_Pcontrol is > (unlike MPI_T) intended to be used in the application code and hence > should have bindings in all languages supported by MPI. What I still don't understand about Pcontrol is that the varargs make it inherently non-portable, or not? I don't mean the "portablility" between C and Fortran, I mean: If the call to MPI_Pcontrol takes anything else than the initial 'level' it will very likely crash with the use of another tool that expects different parameters. If the user has to modify the code for using a different tool to use a feature, I would argue against its portability. I think the only way of handling this portably would be if the call itself, took a handle-like identifier, and the tool itself would implement another call that creates the opaque object behind it. Something along the lines of: int MPI_Pcontrol_create(MPI_Pctrl* handle); int MPI_Pcontrol_free(MPI_Pctrl* handle); The idea is that the Profiling tool would not call PMPI_Pcontrol_create but just create the a structure, do its own book-keeping and return the handle. Then Pcontrol takes this handle (which can transport anything the profiling tool would expect) int MPI_Pcontrol(int level, MPI_Pctrl handle); and maybe something like: int MPI_Pcontrol_set(MPI_Pctrl handle, MPI_Info info); If the tool does not understand some of the infos (because they are meant for a different tool) it ignores it and should use some form of a consistent default state. But I don't know if the latter would really improve over your initial proposal with the info object as a parameter to the Pcontrol call itself, as I don't have any experience with how often one would have to modify the handle. If you have to modify the handle with every call, then you don't gain anything. Cheers, Marc-Andre -- Marc-Andre Hermanns German Research School for Simulation Sciences GmbH c/o Laboratory for Parallel Programming 52062 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 | Prof. Dr. Sebastian M. Schmidt

1 0

Re: [Mpi3-tools] Issues with Fortran bindings for MPI_Pcontrol
by Rolf Rabenseifner 16 Apr '13

16 Apr '13

Dear all, only about the missing ierror in the Fortran MPI_PCONTROL(level): Of course, this interface is valid since MPI-1.1 and never had an additional ierror argument. Nobody never complained about the conflict to the wording MPI-3.0 page 19 lines 8-12. We may correct this with the following additional wording, i.e., without touching the interface specifications: MPI-3.0 page 19 lines 11-12 read A few MPI operations which are functions do not have the return code argument. but should read The subroutine MPI_PCONTROL and a few MPI operations which are functions do not have the return code argument. MPI-3.0 page 557 line 27-28 read MPI libraries themselves make no use of this routine, and simply return immediately to the user code. but should read MPI libraries themselves make no use of this routine, and simply return immediately to the user code. Note that the Fortran interface does not include an ierror argument. I expect that this is all what should be done as erratum about MPI_PCONTROL. My concret wording may/should be optimized (--> Jeff?). Additional remark: I would not say anything about the return-value of the C interface. The wording "and simply return immediately" should say enough, i.e., nobody can expect that a MPI_SUCCESS is returned, because returning MPI_SUCCESS may be more than "and simply return immediately". Although I expect that all high-quality MPI implementations return MPI_SUCCESS, which is also okay, because a function must return something. Best regards Rolf ----- Original Message ----- > From: "Martin Schulz" <schulzm(a)llnl.gov> > To: mpi3-tools(a)lists.mpi-forum.org > Cc: "MPI-3 Fortran working group" <mpi3-fortran(a)lists.mpi-forum.org> > Sent: Tuesday, April 16, 2013 4:34:53 PM > Subject: Re: [Mpi3-tools] Issues with Fortran bindings for MPI_Pcontrol > On Apr 16, 2013, at 3:19 AM, Marc-Andre Hermanns > <m.a.hermanns(a)grs-sim.de> > wrote: > > > Jeff, > > > >> I certainly don't mean deleting PMPI from MPI-4. I mean putting > >> something better in MPI-4 that, over time, can replace PMPI (so > >> that > >> PMPI *can* be deleted in some future version). > > > > I don't really understand why the issues with Pcontrol has an > > influence on whether the PMPI should be surpassed by anything else? > > I agree - we are starting to mix topics and we should keep them > separate. I think we have at least four threads going as one: > - How can we fix the current issues in the Fortran bindings for the > PMPI interface > - How can we fix the ambiguity in the current definition of > MPI_Pcontrol > - Should we replace PMPI with something else > - Should we add a new (additional) MPI_Pcontrol mechanism > > I think all of these are independent. > > > Isn't it for use of the profiling tool only? > > MPI_Pcontrol is used by the application writer to control/inform > tools. The initial intent was to turn on/off profilers, but it kind > has outgrown this. In any case, calls to MPI_Pcontrol go into the > application code and have to be usable by developers (as any other MPI > call). Therefore, we should support all language bindings for it. > Otherwise we might as well remove all Fortran bindings with the > argument that people can wrap their calls to MPI from Fortran > themselves. > > > Scalasca does not use Pcontrol at the moment. Could anyone give me > > an example of a tool using it, and some context in how it is used to > > understand what kind of interface is needed? > > mpiP and O|SS use it to enable phase profiling (in the sense it was > originally designed for), the load balance analysis tool Libra uses it > to allow codes to identify major time steps, our collection tools for > Boxfish use it to annotate phases, we are working on load balancers > that use Pcontrol to communicate application topology to the load > balancer and in the future (as part of the exascale software stack > design) we are thinking about creating families of APIs that use > Pcontrol to pass general application information to runtime systems. > The advantage is always that this is a call whose link symbol is > always present and hence applications can easily pass hints and the > tools/runtimes that can interpret it can use it, while on other > systems we can still link and run. > > Martin > > > > > > Cheers, > > Marc-Andre > > > > -- > > Marc-Andre Hermanns > > German Research School for > > Simulation Sciences GmbH > > c/o Laboratory for Parallel Programming > > 52062 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 | Prof. Dr. Sebastian M. > > Schmidt > > _______________________________________________ > > 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 > > > > > _______________________________________________ > 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] Issues with Fortran bindings for MPI_Pcontrol
by Schulz, Martin 16 Apr '13

16 Apr '13

On Apr 16, 2013, at 3:19 AM, Marc-Andre Hermanns <m.a.hermanns(a)grs-sim.de> wrote: > Jeff, > >> I certainly don't mean deleting PMPI from MPI-4. I mean putting >> something better in MPI-4 that, over time, can replace PMPI (so that >> PMPI *can* be deleted in some future version). > > I don't really understand why the issues with Pcontrol has an influence on whether the PMPI should be surpassed by anything else? I agree - we are starting to mix topics and we should keep them separate. I think we have at least four threads going as one: - How can we fix the current issues in the Fortran bindings for the PMPI interface - How can we fix the ambiguity in the current definition of MPI_Pcontrol - Should we replace PMPI with something else - Should we add a new (additional) MPI_Pcontrol mechanism I think all of these are independent. > Isn't it for use of the profiling tool only? MPI_Pcontrol is used by the application writer to control/inform tools. The initial intent was to turn on/off profilers, but it kind has outgrown this. In any case, calls to MPI_Pcontrol go into the application code and have to be usable by developers (as any other MPI call). Therefore, we should support all language bindings for it. Otherwise we might as well remove all Fortran bindings with the argument that people can wrap their calls to MPI from Fortran themselves. > Scalasca does not use Pcontrol at the moment. Could anyone give me an example of a tool using it, and some context in how it is used to understand what kind of interface is needed? mpiP and O|SS use it to enable phase profiling (in the sense it was originally designed for), the load balance analysis tool Libra uses it to allow codes to identify major time steps, our collection tools for Boxfish use it to annotate phases, we are working on load balancers that use Pcontrol to communicate application topology to the load balancer and in the future (as part of the exascale software stack design) we are thinking about creating families of APIs that use Pcontrol to pass general application information to runtime systems. The advantage is always that this is a call whose link symbol is always present and hence applications can easily pass hints and the tools/runtimes that can interpret it can use it, while on other systems we can still link and run. Martin > > Cheers, > Marc-Andre > > -- > Marc-Andre Hermanns > German Research School for > Simulation Sciences GmbH > c/o Laboratory for Parallel Programming > 52062 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 | Prof. Dr. Sebastian M. Schmidt > _______________________________________________ > 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