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

Re: [Mpi3-tools] One more suggested change to MPI_T / moving count from get_info to alloc_handle
by Kathryn Mohror 30 Jun '11

30 Jun '11

Hi all, I spoke with Adam Moody and Christof about this issue a bit ago. We all like the proposed change -- moving the count to the allocate_handle function. Kathryn On 6/30/2011 12:10 PM, Martin Schulz wrote: > Hi all, > > Christof has found a potential problem in the API design that > I think is worth discussing and (at least IMHO) worth changing: > > The current design returns the "count" of a variable, i.e., how many > data elements are used to return or set the data, during the > Get_info calls. For some variables, though, it may return information > in multiple elements, e.g., once for each rank. The number of > these elements, in this case, would depend on the MPI object > we are binding the variable to and hence is not known until > we allocate the matching handle. > > Examples for these kind of variables are eager limits that can > be set on individual rank pairs or number of packets received > or sent, again on individual communication pairs. In both cases > the variable would be bound to / associated with a Comm > object. > > The only way to support this in the current interface proposal > is to return a count that is the biggest possible. In the example > that would be the size of MPI_COMM_WORLD, which wouldn't > scale. > > One (easy) way to solve this (and the credit for this goes to > Christof) is to move returning the count from the Get_info > calls to the Handle_allocate calls. This way, the count could > be set based on the MPI object we are associating the > variable with. > > Anybody see any problems with this change? Note, that valid > implementations can still use scalar variables only by always > return one for each allocated handle. > > Comments? > > 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

1 0

[Mpi3-tools] One more suggested change to MPI_T / moving count from get_info to alloc_handle
by Martin Schulz 30 Jun '11

30 Jun '11

Hi all, Christof has found a potential problem in the API design that I think is worth discussing and (at least IMHO) worth changing: The current design returns the "count" of a variable, i.e., how many data elements are used to return or set the data, during the Get_info calls. For some variables, though, it may return information in multiple elements, e.g., once for each rank. The number of these elements, in this case, would depend on the MPI object we are binding the variable to and hence is not known until we allocate the matching handle. Examples for these kind of variables are eager limits that can be set on individual rank pairs or number of packets received or sent, again on individual communication pairs. In both cases the variable would be bound to / associated with a Comm object. The only way to support this in the current interface proposal is to return a count that is the biggest possible. In the example that would be the size of MPI_COMM_WORLD, which wouldn't scale. One (easy) way to solve this (and the credit for this goes to Christof) is to move returning the count from the Get_info calls to the Handle_allocate calls. This way, the count could be set based on the MPI object we are associating the variable with. Anybody see any problems with this change? Note, that valid implementations can still use scalar variables only by always return one for each allocated handle. Comments? 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] MPI_T - Reviews and Question on Initialization
by Marty Itzkowitz 30 Jun '11

30 Jun '11

On 6/30/11 7:08 AM, Dave Goodell wrote: > On Jun 30, 2011, at 3:22 AM CDT, Martin Schulz wrote: > >> Here is Bronis's comment: >> >> The advice to users on page 39 is not just advice to users. >> The problem is that I do not see anywhere that requires inheritance >> of the tool information interface state. You only mention it in this >> advice to users, which is non-normative. You need a normative statement >> that it is inherited. >> >> I know we wanted to be careful when we wrote that part, but >> I kind of agree with Bronis, that this should be stronger. Would >> it be OK to just drop the "advice" environment, i.e., make the >> text that is now an advice to a regular part of the document? > Works for me. That was a good catch, Bronis. I agree. Marty

1 0

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

30 Jun '11

On Jun 30, 2011, at 3:22 AM CDT, Martin Schulz wrote: > Here is Bronis's comment: > > The advice to users on page 39 is not just advice to users. > The problem is that I do not see anywhere that requires inheritance > of the tool information interface state. You only mention it in this > advice to users, which is non-normative. You need a normative statement > that it is inherited. > > I know we wanted to be careful when we wrote that part, but > I kind of agree with Bronis, that this should be stronger. Would > it be OK to just drop the "advice" environment, i.e., make the > text that is now an advice to a regular part of the document? Works for me. That was a good catch, Bronis. -Dave

1 0

[Mpi3-tools] MPI_T - Reviews and Question on Initialization
by Martin Schulz 30 Jun '11

30 Jun '11

Hi all, First, just a quick reminder that we need to have the MPI_T document in a final draft state by Monday to make the two week deadline for the MPI forum. Hence, if you have any comments that are more than ticket 0 changes, please let me know. Also, if you edit the document directly, please make sure to update your SVN repository, since people are making changes to it (and send me email afterwards). I am traveling Saturday-Tuesday. I would appreciate any comments, especially larger changes, before the weekend. Further, Bronis has been going over the document and making comments. One in particular I wanted to pass along and put up for discussion. This is regarding the MPI_T_Init_thread behavior, which we discussed before on one of our TelCons. At that time, we decided to add the following advice to users (p.39): \begin{users} The MPI specification does not require all MPI processes to exist before the call to MPI_INIT. If the MPI tool information interface is used before MPI_INIT has been called, MPI_T_INIT_THREAD must be called on each process that exists. Processes created by the MPI implementation during MPI_INIT inherit the status of MPI tool information interface (whether it is initialized or not as well as all active handles) from the process from which they are created. \end{users} Here is Bronis's comment: The advice to users on page 39 is not just advice to users. The problem is that I do not see anywhere that requires inheritance of the tool information interface state. You only mention it in this advice to users, which is non-normative. You need a normative statement that it is inherited. I know we wanted to be careful when we wrote that part, but I kind of agree with Bronis, that this should be stronger. Would it be OK to just drop the "advice" environment, i.e., make the text that is now an advice to a regular part of the document? Thanks! Martin ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0

[Mpi3-tools] MPI-3 Fortran WG
by Jeff Squyres (jsquyres) 29 Jun '11

29 Jun '11

Discuss results of Fortran standards body meeting (from week of June 27), Craig's proposal for standard symbol names, backwards compatibility ramifications, PMPI issues, and implications for MPI tools. ----- WebEx Invite ----- Meeting Number: 201297528 Password: fortran ------------------------ To join the meeting online ------------------------ 1. Go to https://cisco.webex.com/cisco/j.php?ED=168240732&UID=0&PW=NNjkzNTNjYWY4&RT=… 2. Enter your name and email address. 3. Enter the meeting password: fortran 4. Click "Join". 5. If the meeting includes a teleconference, follow the instructions that appear on your screen. ------------------------ To join the teleconference only ------------------------ 1. Dial into Cisco WebEx - view all Global Access Numbers at http://cisco.com/en/US/about/doing_business/conferencing/index.html 2. Follow the prompts to enter the Meeting Number (listed above) or Access Code followed by the # sign. San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 India: +91.80.4350.1111 Germany: +49.619.6773.9002 Japan: +81.3.5763.9394 China: +86.10.8515.5666 Access code: 201297528 Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, do not join the session.

1 0

[Mpi3-tools] Fwd: [MPI3 Fortran] Fortran WG teleconf
by Jeff Squyres 27 Jun '11

27 Jun '11

For anyone who wanted to join the Fortran MPI-3 issues (Martin: please fill out your availability; I think you need to be there :-) ). Begin forwarded message: > From: Jeff Squyres <jsquyres(a)cisco.com> > Date: June 27, 2011 10:29:42 AM EDT > To: MPI-3 WG <mpi3-fortran(a)lists.mpi-forum.org> > Subject: [MPI3 Fortran] Fortran WG teleconf > Reply-To: MPI-3 Fortran working group <mpi3-fortran(a)lists.mpi-forum.org> > > Please indicate your availability here: > > http://www.doodle.com/a3fbkpxca9nbgksh > > Thanks. > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > 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 Martin Schulz 27 Jun '11

27 Jun '11

Hi all, I agree with Jeff and Craig - having a TelCon next week would be helpful. What about Wednesday 7/6 at 8am PDT, 11am EDT, 5pm MSZ, since this would also give people from Europe a chance to dial-in. Would this work for everyone/most of you? Once we have a time, I'll also send this to the group of tools people we had on the other email, in case someone wanted to join us. Martin On Jun 27, 2011, at 6:42 AM, Rasmussen, Craig wrote: > I finally have had a chance to read through all of the responses. > Hopefully I can clarify a few things without muddying the waters > further. > > If Martin is correct and no tools support the "use mpi" option, then > things are pretty simple. > > 1. mpih.f option: For the immediate future this works as it always > has. I was only suggesting to deprecate it. But on reconsideration, > I think this is the wrong thing to do. We are trying to deprecate > mpih.f itself so the tools using mpih.f can continue using the current > naming convention as long as mpih.f stays around. Fortran users could > write an MPI_Send routine and it would work with the PMPI interface as > before (at least as I understand how this works). > > 2. use mpi or use mpi_f08 option: We would mandate that these > interfaces supply the names mpi_send_f, mpi_send_f_nostatus, > mpi_send_desc, and mpi_send_desc_nostatus. The problem comes when a > Fortran user want to use the PMPI interface. I need to understand > this more and write some tests and examples we can all look at. > > So I suggest we schedule a conference call sometime next week (after July 5). > > -craig > > > On Mon, Jun 27, 2011 at 6:38 AM, Hubert Ritzdorf > <Hubert.Ritzdorf(a)emea.nec.com> wrote: >> >> >>> -----Original Message----- >>> From: mpi3-fortran-bounces(a)lists.mpi-forum.org [mailto:mpi3-fortran- >>> bounces(a)lists.mpi-forum.org] On Behalf Of Bill Long >>> Sent: Saturday, June 25, 2011 11:33 AM >>> To: Martin Schulz >>> Cc: MPI3 Tools; MPI-3 Fortran working group >>> Subject: Re: [MPI3 Fortran] MPI function symbol naming convention for tools >>> >>> >>> >>> On 6/24/11 11:54 AM, Martin Schulz wrote: >>> >>>> >>>> This is probably my lack of knowledge in Fortran compilers, but >>>> is this all even possible with regular compilers: I would assume >>>> that you can use an MPI 3.0 implementation with Craig's proposal >>>> (case A) with an older F77 or F90 compiler, right? If so, one would >>>> use "use mpi" or "mpif.h", i.e., case A.1. Can you do the name >>>> mapping from mpi_send to mpi_send_f - I thought this was a new >>>> feature from F08? >>>> >>> >>> If you still have an old f77 compiler on you system (from decades ago), >>> it will not be adequate. If you have a current version of a Fortran >>> compiler available, you are in much better shape. The meaning of >>> "Fortran" changes over time, and the compilers progress accordingly, >>> with some time delay. >>> >>> The name mapping of a call to MPI_send into a call to mpi_send_f is >>> accomplished with generic interfaces. These were part of Fortran 90 (20 >>> year old technology now) - F08 is not required for this. Other details >>> of the interfaces do require more recent standards, however. >>> >>> >> >> Craig's proposal would require at least Fortran 2003. Otherwise, the compiler may still generate MPI_SEND_F, mpi_send_f, mpi_send_f_ or >> mpi_send_f__. >> >> Hubert >> >> _______________________________________________ >> mpi3-fortran mailing list >> mpi3-fortran(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran >> ________________________________________________________________________ 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 27 Jun '11

27 Jun '11

On Jun 27, 2011, at 9:42 AM, Rasmussen, Craig wrote: > I finally have had a chance to read through all of the responses. > Hopefully I can clarify a few things without muddying the waters > further. > > If Martin is correct and no tools support the "use mpi" option, then > things are pretty simple. > > 1. mpih.f option: For the immediate future this works as it always > has. I was only suggesting to deprecate it. But on reconsideration, > I think this is the wrong thing to do. We are trying to deprecate > mpih.f itself so the tools using mpih.f can continue using the current > naming convention as long as mpih.f stays around. Fortran users could > write an MPI_Send routine and it would work with the PMPI interface as > before (at least as I understand how this works). I don't think we can deprecate mpif.h -- Rolf outlined the reasons why in one of our Chicago Forum meetings (some organizations outlaw the use of *any* "deprecated" interface). Rolf's text from the last meeting had strongly worded language advising people not to use mpif.h, but stopped short of deprecating it. > 2. use mpi or use mpi_f08 option: We would mandate that these > interfaces supply the names mpi_send_f, mpi_send_f_nostatus, > mpi_send_desc, and mpi_send_desc_nostatus. The problem comes when a > Fortran user want to use the PMPI interface. I need to understand > this more and write some tests and examples we can all look at. > > So I suggest we schedule a conference call sometime next week (after July 5). That would be good. I think that at least the following should attend (others are welcome, of course): - Craig - Jeff - Rolf - Martin - Hubert I'll post a doodle for scheduling shortly. Note that 4 July is a holiday in the US; many (including me) also take the 5th as vacation to make it a 4-day weekend. -- 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 Hubert Ritzdorf 27 Jun '11

27 Jun '11

>-----Original Message----- >From: mpi3-fortran-bounces(a)lists.mpi-forum.org [mailto:mpi3-fortran- >bounces(a)lists.mpi-forum.org] On Behalf Of Bill Long >Sent: Saturday, June 25, 2011 11:33 AM >To: Martin Schulz >Cc: MPI3 Tools; MPI-3 Fortran working group >Subject: Re: [MPI3 Fortran] MPI function symbol naming convention for tools > > > >On 6/24/11 11:54 AM, Martin Schulz wrote: > >> >> This is probably my lack of knowledge in Fortran compilers, but >> is this all even possible with regular compilers: I would assume >> that you can use an MPI 3.0 implementation with Craig's proposal >> (case A) with an older F77 or F90 compiler, right? If so, one would >> use "use mpi" or "mpif.h", i.e., case A.1. Can you do the name >> mapping from mpi_send to mpi_send_f - I thought this was a new >> feature from F08? >> > >If you still have an old f77 compiler on you system (from decades ago), >it will not be adequate. If you have a current version of a Fortran >compiler available, you are in much better shape. The meaning of >"Fortran" changes over time, and the compilers progress accordingly, >with some time delay. > >The name mapping of a call to MPI_send into a call to mpi_send_f is >accomplished with generic interfaces. These were part of Fortran 90 (20 >year old technology now) - F08 is not required for this. Other details >of the interfaces do require more recent standards, however. > > Craig's proposal would require at least Fortran 2003. Otherwise, the compiler may still generate MPI_SEND_F, mpi_send_f, mpi_send_f_ or mpi_send_f__. Hubert

1 0