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

Re: [Mpi3-tools] Type sizes in MPI_T
by William Gropp 24 Jun '11

24 Jun '11

Martin, Possible refers to the values (and that there are other choices, including the derived types); sizeof may be used for the basic types instead of MPI_Type_size. Bill On Jun 23, 2011, at 9:39 PM, Martin Schulz wrote: > Hi all, > > Christof has been going over the MPI_T document (thanks!) and > found a few issues - I will fix those and post a new draft tonight. > > One issue, however, we were not sure about: since we are > not allowing any MPI calls between MPI_T_Init_thread and > MPI_Init (only MPI_T calls), we also cannot call any MPI > Type related calls, such as MPI_Type_size or calls for > naming or setting attributes. The latter we can probably > get away with not having until MPI_Init, but we were not sure > on MPI_Type_size. > > Since we are only using basic types, can we assume that they > always represent their corresponding C types as specified in > Section 3.2.2? I always assumed this, but looking closer, we > were not 100% certain on how to interpret the following sentence > in that section: > > Possible values for this argument for C and the corresponding > C types are listed in Table 3.2. > > Does the possible only refer to the values or also to the > corresponding C types? If it is the former, then we can get > the size simply by calling sizeof(...) and this is not an > issue. > > Thanks, > > Martin > > > ________________________________________________________________________ > 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 William Gropp Director, Parallel Computing Institute Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign

1 0

[Mpi3-tools] New version of MPI_T available
by Martin Schulz 23 Jun '11

23 Jun '11

Hi all, I just uploaded a new version of the MPI_T document, which has some fixes for issues that Christof found. The new version is on the tools Wiki, on ticket #266, and in SVN. Martin ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0

Re: [Mpi3-tools] [MPI3 Fortran] MPI function symbol naming convention for tools
by Martin Schulz 23 Jun '11

23 Jun '11

Hi Jeff, On Jun 23, 2011, at 4:07 AM, Jeff Squyres wrote: > On Jun 23, 2011, at 3:39 AM, Martin Schulz wrote: > >> That makes more sense now - just to clarify: the new names only >> apply if an application uses "use mpi_f08", otherwise the old >> interface applies. Is this correct? > > It's almost that simple, but not quite. > > An MPI application can use any of all of the interfaces. In one .f90 file, for example, there could be a subroutine that uses mpif.h, another subroutine that uses "use mpi", and another that uses "use mpi_f08". Sure, there may be mixed mode programs. > > So tools will need to be expanded to cover all of the MPI Fortran interfaces; if you only catch the old names, you might miss some run-time information. Also that makes sense and is what I expected. What I meant was more that existing tools work without modifications on programs that do not use mpi_f08 at all in any part. Is this correct? > >>>> So in one sense, we're not breaking tools because the use mpi_f08 interface is new. >> >> I read Craig's email as if the existing interface (without using mpi_f08) >> would get the new symbol as well. If I read you right, this is not the case. > > That *is* the case. That's why I started my sentence with "So in one sense..." :-) Now, I am confused - this seems to contradict the above. If I compile a F77 only program that uses mpif.h and has a call to MPI_Recv, which symbol(s) do I get? > >>>> In another sense, if we mandate specific symbols for mpif.h/use mpi, we might break some tools, but put ourselves in a better place for the future. Since a tool already has to sense which back-end symbol to use mpif.h/use mpi (lower case, caps, 1 underscore, 2 underscores -- none of which are mandated by the Fortran spec, by the way; it's just common convention), is it really a hardship to add another symbol name to check during the tools configuration/building mechanism? >> >> I am more worrying about existing tools - those would all >> have to be changed. > > They're all going to have to be changed anyway. > > However, it's not as bad as it sounds. Tools today must intercept the mpif.h symbols by finding the right symbol to intercept: > > MPI_SEND > mpi_send > mpi_send_ > mpi_send__ > > In Craig's proposal, you now have to look for one more form of the symbol: > > mpi_send_f > > Hence, if you add supporting the one new symbol, you'll cover all old MPI implementations and all new ones. Sure, the addition is not hard - the more complicated part will be the routines for the optional parameters. We can no longer deduce them automatically from any header file and will always have to special code them. Do we really need them? Why not pass a STATUS_IGNORE argument? > > And, more importantly, I believe there's plenty of time for existing tools to adapt (e.g., to add intercepting the 5th symbol) -- maybe a year or more. OMPI will have a first prototype implementation soon; I imagine the others will follow over time (assuming that this proposal, or something like it, is passed into the MPI-3 spec over the course of the next 6 months). In the meantime, they will be labeled as MPI 2.2 tools and will work with any MPI 2.2 compliant code. As long as that still works (and I see no reason why not) then I think things are fine. > > Also note that there is no standardized nomenclature for intercepting "use mpi" symbols, so I'll bet you a high-quality beer that there are no portable tools that properly instrument "use mpi" interfaces. OMPI's "use mpi" implementation, for example, *sometimes* calls the corresponding mpif.h symbol, but not always. Heck, I'll even bet you another HQ beer that there's *no* MPI implementation that supports explicit Fortran interfaces for all MPI functions in its "use mpi" interfaces that has a corresponding interception / tracing tool -- specifically because of the lack of standardization of how to do it. > > Craig's proposal gives you a way to reliably intercept the "use mpi" symbols. Well, not quite - we still have to play the tricks for older MPIs and for the parts of the codes that don't use the module. Those will use the old naming convention, right? > > The "use mpi_f08" stuff is new, so tools obviously have to be expanded to instrument those symbols (and new types). But I don't think that's the main point of your question. Sure, we'll have to work on this, but that was to be expected. Martin > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0

[Mpi3-tools] Type sizes in MPI_T
by Martin Schulz 23 Jun '11

23 Jun '11

Hi all, Christof has been going over the MPI_T document (thanks!) and found a few issues - I will fix those and post a new draft tonight. One issue, however, we were not sure about: since we are not allowing any MPI calls between MPI_T_Init_thread and MPI_Init (only MPI_T calls), we also cannot call any MPI Type related calls, such as MPI_Type_size or calls for naming or setting attributes. The latter we can probably get away with not having until MPI_Init, but we were not sure on MPI_Type_size. Since we are only using basic types, can we assume that they always represent their corresponding C types as specified in Section 3.2.2? I always assumed this, but looking closer, we were not 100% certain on how to interpret the following sentence in that section: Possible values for this argument for C and the corresponding C types are listed in Table 3.2. Does the possible only refer to the values or also to the corresponding C types? If it is the former, then we can get the size simply by calling sizeof(...) and this is not an issue. Thanks, Martin ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0

Re: [Mpi3-tools] [MPI3 Fortran] MPI function symbol naming convention for tools
by Jeff Squyres 23 Jun '11

23 Jun '11

Craig -- see my reply. I think tools will need to support both for a while (i.e., while there's still implementations with the old way out there). But eventually all implementations will move to the new way, and the 4 old conventions (MPI_SEND, mpi_send, mpi_send_, mpi_send__) will go away. That's my $0.02, at least... On Jun 23, 2011, at 9:50 AM, Rasmussen, Craig E wrote: > > On Jun 23, 2011, at 1:39 AM, Martin Schulz wrote: > >>>> >>>> In another sense, if we mandate specific symbols for mpif.h/use mpi, we might break some tools, but put ourselves in a better place for the future. Since a tool already has to sense which back-end symbol to use mpif.h/use mpi (lower case, caps, 1 underscore, 2 underscores -- none of which are mandated by the Fortran spec, by the way; it's just common convention), is it really a hardship to add another symbol name to check during the tools configuration/building mechanism? >> >> I am more worrying about existing tools - those would all >> have to be changed. >> >> Martin >> > > Could you comment on the possibility of deprecating what is essentially the current mpif.h tool access. > > -craig > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-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: [Mpi3-tools] [MPI3 Fortran] MPI function symbol naming convention for tools
by Jeff Squyres 23 Jun '11

23 Jun '11

On Jun 23, 2011, at 3:39 AM, Martin Schulz wrote: > That makes more sense now - just to clarify: the new names only > apply if an application uses "use mpi_f08", otherwise the old > interface applies. Is this correct? It's almost that simple, but not quite. An MPI application can use any of all of the interfaces. In one .f90 file, for example, there could be a subroutine that uses mpif.h, another subroutine that uses "use mpi", and another that uses "use mpi_f08". So tools will need to be expanded to cover all of the MPI Fortran interfaces; if you only catch the old names, you might miss some run-time information. >>> So in one sense, we're not breaking tools because the use mpi_f08 interface is new. > > I read Craig's email as if the existing interface (without using mpi_f08) > would get the new symbol as well. If I read you right, this is not the case. That *is* the case. That's why I started my sentence with "So in one sense..." :-) >>> In another sense, if we mandate specific symbols for mpif.h/use mpi, we might break some tools, but put ourselves in a better place for the future. Since a tool already has to sense which back-end symbol to use mpif.h/use mpi (lower case, caps, 1 underscore, 2 underscores -- none of which are mandated by the Fortran spec, by the way; it's just common convention), is it really a hardship to add another symbol name to check during the tools configuration/building mechanism? > > I am more worrying about existing tools - those would all > have to be changed. They're all going to have to be changed anyway. However, it's not as bad as it sounds. Tools today must intercept the mpif.h symbols by finding the right symbol to intercept: MPI_SEND mpi_send mpi_send_ mpi_send__ In Craig's proposal, you now have to look for one more form of the symbol: mpi_send_f Hence, if you add supporting the one new symbol, you'll cover all old MPI implementations and all new ones. And, more importantly, I believe there's plenty of time for existing tools to adapt (e.g., to add intercepting the 5th symbol) -- maybe a year or more. OMPI will have a first prototype implementation soon; I imagine the others will follow over time (assuming that this proposal, or something like it, is passed into the MPI-3 spec over the course of the next 6 months). Also note that there is no standardized nomenclature for intercepting "use mpi" symbols, so I'll bet you a high-quality beer that there are no portable tools that properly instrument "use mpi" interfaces. OMPI's "use mpi" implementation, for example, *sometimes* calls the corresponding mpif.h symbol, but not always. Heck, I'll even bet you another HQ beer that there's *no* MPI implementation that supports explicit Fortran interfaces for all MPI functions in its "use mpi" interfaces that has a corresponding interception / tracing tool -- specifically because of the lack of standardization of how to do it. Craig's proposal gives you a way to reliably intercept the "use mpi" symbols. The "use mpi_f08" stuff is new, so tools obviously have to be expanded to instrument those symbols (and new types). But I don't think that's the main point of your question. -- 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] MPI function symbol naming convention for tools
by Martin Schulz 23 Jun '11

23 Jun '11

Hi Jeff and Bill, On Jun 22, 2011, at 12:16 PM, Bill Long wrote: > > > On 6/22/11 11:48 AM, Jeff Squyres wrote: >> Martin -- >> >> It is important to realize the difference between the different Fortran bindings. Sure. >> >> The "old" form (via include 'mpif.h') will still be available, and (likely) use whatever mechanism an implementation used for it before (e.g., have an underlying symbol for MPI_RECV as mpi_recv, MPI_RECV, mpi_recv_, and/or mpi_recv__). These will likely also be the same underlying symbols for the "use mpi" interface. Great - that was my question. This means that existing tools are still compatible with existing codes. This was my main concern. >> >> However, the "use mpi_f08" interface uses different parameter types than mpi.h/use mpi. So it has a different back-end function for MPI_RECV than the other two. Modern fortran also allows us to specify what the back-end symbol name will be; hence, Craig is proposing a specific set of back-end symbol names for the "use mpi_f08" functions like MPI_RECV that will be different than those used for mpif.h and "use mpi". This will actually allow tool authors to know for sure what the symbol names will be. That makes more sense now - just to clarify: the new names only apply if an application uses "use mpi_f08", otherwise the old interface applies. Is this correct? >> > > A bit more detail here: If you specify BIND(C, name="Jeff") in Fortran > the external symbol is the same as the external symbol for a C object > named Jeff in C source code. If the C compiler does some sort of name > mangling for external symbols, then the Fortran compiler is required to > do the SAME mangling on its name. That way you can look at the Fortran > and C statements and see the same names and know they correspond. If, > as is common, the C name is the same as the back-end symbol, they the > the name= specifier does end up specifying the back-end symbol as well. > But the rule is in terms of the C name. That sounds good. > > Cheers, > Bill > > >> So in one sense, we're not breaking tools because the use mpi_f08 interface is new. I read Craig's email as if the existing interface (without using mpi_f08) would get the new symbol as well. If I read you right, this is not the case. >> >> In another sense, if we mandate specific symbols for mpif.h/use mpi, we might break some tools, but put ourselves in a better place for the future. Since a tool already has to sense which back-end symbol to use mpif.h/use mpi (lower case, caps, 1 underscore, 2 underscores -- none of which are mandated by the Fortran spec, by the way; it's just common convention), is it really a hardship to add another symbol name to check during the tools configuration/building mechanism? I am more worrying about existing tools - those would all have to be changed. Martin >> >> >> >> >> On Jun 22, 2011, at 12:12 PM, Rasmussen, Craig E wrote: >> >>> >>> On Jun 20, 2011, at 9:45 PM, Martin Schulz wrote: >>> >>>> Hi Craig, all, >>>> >>>> (I cc-ed the tools group on this as well - this is regarding the >>>> issue how the profiling interface will work with the proposed >>>> new Fortran bindings): >>>> >>>> >>>> On Jun 20, 2011, at 10:15 AM, Rasmussen, Craig E wrote: >>>> >>>>> I've talked with Jeff Squyres and we come up with naming convention that we'd like to propose for tools to have access to Fortran. >>>>> >>>>> I believe we need four different symbol naming conventions. Consider MPI_Recv(), the four functions are >>>>> >>>>> 1. mpi_recv_f >>>>> - This function implements (in C or Fortran) MPI_Recv with integer handles and the choice buffer passed by address. >>>> >>>> Does this mean the existing mpi_recv binding will go away? >>>> This would break any existing tool. Can we keep the old naming >>>> scheme for the old interface? Or is this intended as an additional >>>> symbol? >>> >>> Hum and YUK. There really isn't an mpi_recv symbol as the Fortran compilers mangle the name. We could keep the old mixed up name mangling scheme (and hopefully deprecate it) for the mpif.h usage. This proposal give the C tools writer a common symbol name hook rather than compiler dependent mangling. >>> >>>> >>>>> >>>>> 2. mpi_recv_f_nostatus >>>>> - This function implements (in C or Fortran) MPI_Recv with integer handles without a status variable and the choice buffer passed by address. >>>> >>>> Is this just for the new bindings? >>> >>> New bindings only but could be made available to "use mpi" users. >>> >>>> >>>>> >>>>> 3. mpi_recv_f08 >>>>> - This function implements (in C or Fortran) MPI_Recv with integer handles and the choice buffer passed via an array descriptor. >>>>> >>>>> 4. mpi_recv_f_nostatus >>>>> - This function implements (in C or Fortran) MPI_Recv with integer handles without a status variable and the choice buffer passed via an array descriptor. >>>> >>>> I assume you mean mpi_recv_f08_nostatus? >>> >>> Yes. But Steve requested a name change to mpi_recv_desc and mpi_recv_desc_nostatus. >>> >>>> >>>>> >>>>> Note that these functions only need to support integer handles because of the way we (thanks to Rolf) have chosen to define the handle types in the mpi_f08 module. >>> >>> I should say support integer handles in C. If implemented in Fortran the interface would be with typed Fortran handles for mpi_recv_desc and mpi_recv_desc_nostatus. >>> >>> -craig >>> _______________________________________________ >>> mpi3-fortran mailing list >>> mpi3-fortran(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran >> >> > > -- > 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 > > ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0

Re: [Mpi3-tools] [MPI3 Fortran] MPI function symbol naming convention for tools
by Jeff Squyres 22 Jun '11

22 Jun '11

Martin -- It is important to realize the difference between the different Fortran bindings. The "old" form (via include 'mpif.h') will still be available, and (likely) use whatever mechanism an implementation used for it before (e.g., have an underlying symbol for MPI_RECV as mpi_recv, MPI_RECV, mpi_recv_, and/or mpi_recv__). These will likely also be the same underlying symbols for the "use mpi" interface. However, the "use mpi_f08" interface uses different parameter types than mpi.h/use mpi. So it has a different back-end function for MPI_RECV than the other two. Modern fortran also allows us to specify what the back-end symbol name will be; hence, Craig is proposing a specific set of back-end symbol names for the "use mpi_f08" functions like MPI_RECV that will be different than those used for mpif.h and "use mpi". This will actually allow tool authors to know for sure what the symbol names will be. So in one sense, we're not breaking tools because the use mpi_f08 interface is new. In another sense, if we mandate specific symbols for mpif.h/use mpi, we might break some tools, but put ourselves in a better place for the future. Since a tool already has to sense which back-end symbol to use mpif.h/use mpi (lower case, caps, 1 underscore, 2 underscores -- none of which are mandated by the Fortran spec, by the way; it's just common convention), is it really a hardship to add another symbol name to check during the tools configuration/building mechanism? On Jun 22, 2011, at 12:12 PM, Rasmussen, Craig E wrote: > > On Jun 20, 2011, at 9:45 PM, Martin Schulz wrote: > >> Hi Craig, all, >> >> (I cc-ed the tools group on this as well - this is regarding the >> issue how the profiling interface will work with the proposed >> new Fortran bindings): >> >> >> On Jun 20, 2011, at 10:15 AM, Rasmussen, Craig E wrote: >> >>> I've talked with Jeff Squyres and we come up with naming convention that we'd like to propose for tools to have access to Fortran. >>> >>> I believe we need four different symbol naming conventions. Consider MPI_Recv(), the four functions are >>> >>> 1. mpi_recv_f >>> - This function implements (in C or Fortran) MPI_Recv with integer handles and the choice buffer passed by address. >> >> Does this mean the existing mpi_recv binding will go away? >> This would break any existing tool. Can we keep the old naming >> scheme for the old interface? Or is this intended as an additional >> symbol? > > Hum and YUK. There really isn't an mpi_recv symbol as the Fortran compilers mangle the name. We could keep the old mixed up name mangling scheme (and hopefully deprecate it) for the mpif.h usage. This proposal give the C tools writer a common symbol name hook rather than compiler dependent mangling. > >> >>> >>> 2. mpi_recv_f_nostatus >>> - This function implements (in C or Fortran) MPI_Recv with integer handles without a status variable and the choice buffer passed by address. >> >> Is this just for the new bindings? > > New bindings only but could be made available to "use mpi" users. > >> >>> >>> 3. mpi_recv_f08 >>> - This function implements (in C or Fortran) MPI_Recv with integer handles and the choice buffer passed via an array descriptor. >>> >>> 4. mpi_recv_f_nostatus >>> - This function implements (in C or Fortran) MPI_Recv with integer handles without a status variable and the choice buffer passed via an array descriptor. >> >> I assume you mean mpi_recv_f08_nostatus? > > Yes. But Steve requested a name change to mpi_recv_desc and mpi_recv_desc_nostatus. > >> >>> >>> Note that these functions only need to support integer handles because of the way we (thanks to Rolf) have chosen to define the handle types in the mpi_f08 module. > > I should say support integer handles in C. If implemented in Fortran the interface would be with typed Fortran handles for mpi_recv_desc and mpi_recv_desc_nostatus. > > -craig > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-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

[Mpi3-tools] Fwd: New version of MPI_T available
by Martin Schulz 21 Jun '11

21 Jun '11

Sorry, this time with attachment. Begin forwarded message: > From: Martin Schulz <schulzm(a)llnl.gov> > Date: June 21, 2011 12:02:25 AM PDT > To: MPI3 Tools <mpi3-tools(a)lists.mpi-forum.org> > Subject: New version of MPI_T available > > Hi all, > > I uploaded a new version of the MPI_T document (with all > modified chapters included) to the tools Wiki and to ticket > #266. I also included it here for reference. It should contain > all the discussion points from the last forum and from our > phone discussion. > > We now have two weeks to review the document and to make > any non-ticket 0 changes. The more eyes look over the > document the better. After that (7/1) we need to deliver a final > copy to the forum for the reading. Hence, please comment > sooner than later, especially for larger comments! > > Thanks! > > Martin > > > > ________________________________________________________________________ > Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm > CASC @ Lawrence Livermore National Laboratory, Livermore, USA > > > ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0

[Mpi3-tools] New version of MPI_T available
by Martin Schulz 21 Jun '11

21 Jun '11

Hi all, I uploaded a new version of the MPI_T document (with all modified chapters included) to the tools Wiki and to ticket #266. I also included it here for reference. It should contain all the discussion points from the last forum and from our phone discussion. We now have two weeks to review the document and to make any non-ticket 0 changes. The more eyes look over the document the better. After that (7/1) we need to deliver a final copy to the forum for the reading. Hence, please comment sooner than later, especially for larger comments! Thanks! Martin ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0