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

Re: [Mpi3-tools] latest draft of mqs
by John DelSignore 21 May '13

21 May '13

Hi, Attached are my edits and comments on the MPI Message Queue document. Anh provided me with a Word document generated from the LaTex, so the formatting is funky in some places. I enabled change tracking in Word before making my edits, and I added many comments to the document in places where I think we have more work to do. Unfortunately, I think the changes might be somewhat extensive. The volume of edits and comments aside, I think Anh did a great job! The first draft of the document closely reflects the 10+ year-old description of the interface pretty well. Unfortunately, the original interface has some problem that we need to resolve, most critically, we have to resolve how to describe the concept of "mqs_image". We can talk about this during the next concall. Cheers, John D. Anh Vo wrote: > Hi all, > > As mentioned on the tool WG call today, Iï¿½m re-sending the latest draft. > Feedbacks are appreciated. Weï¿½ll send this one out to the wider audience > on Tuesday 5/21 to meet the requirement for first reading in June > > > > --Anh >

1 0

[Mpi3-tools] latest draft of mqs
by Anh Vo 16 May '13

16 May '13

Hi all, As mentioned on the tool WG call today, I'm re-sending the latest draft. Feedbacks are appreciated. We'll send this one out to the wider audience on Tuesday 5/21 to meet the requirement for first reading in June --Anh

1 0

[Mpi3-tools] Next telecon May 16
by Kathryn Mohror 15 May '13

15 May '13

Hi all, This is a reminder of our telecon tomorrow May 16 at 8:00 AM PDT, 11:00 AM EDT. As always, the link for joining the webex is on the wiki: https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Tools Agenda: - Feedback on current MQS draft - Handle introspection interface - New approach for the Fortran issue - Plans for next forum meeting Talk to you tomorrow! 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] My comments on the MQS draft
by Jeff Squyres (jsquyres) 02 May '13

02 May '13

option 1: separate docs (e.g., MPIR, MQS, DLL, ...etc.) option 2: single combined doc option 3: in the MPI spec itself So yes, we agreed to do a single external doc with MPIR, MQS, etc. On May 2, 2013, at 4:52 PM, Kathryn Mohror <kathryn(a)llnl.gov> wrote: > Hi Jeff, > > Here's what I have from my notes from the forum. The straw vote breakdown was: > > option 1: 5 > option 2: 15 > option 3: 2 > > I had to go back to your slides to remember what option 2 was! It was the single side document option. > > Kathryn > > On May 2, 2013, at 11:46 AM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > >> Anh -- >> >> Nicely done. Attached is a scan of my comments on the draft. We can chat about them on a phone call if they don't make sense... >> >> One big comment: didn't we agree at the last Forum meeting to have 1 big document with MPIR and MQS (and whatever else we dream up)? I can't find the notes from last meeting to remember what the Forum decided. If we did agree on one document: now that much of the MQS text has been written, perhaps it would make sense to combine these into a single doc...? >> >> -- >> Jeff Squyres >> jsquyres(a)cisco.com >> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ >> <2013_05_02_14_39_09-mqs-draft.pdf>_______________________________________________ >> 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 -- 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] My comments on the MQS draft
by Kathryn Mohror 02 May '13

02 May '13

Hi Jeff, Here's what I have from my notes from the forum. The straw vote breakdown was: option 1: 5 option 2: 15 option 3: 2 I had to go back to your slides to remember what option 2 was! It was the single side document option. Kathryn On May 2, 2013, at 11:46 AM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > Anh -- > > Nicely done. Attached is a scan of my comments on the draft. We can chat about them on a phone call if they don't make sense... > > One big comment: didn't we agree at the last Forum meeting to have 1 big document with MPIR and MQS (and whatever else we dream up)? I can't find the notes from last meeting to remember what the Forum decided. If we did agree on one document: now that much of the MQS text has been written, perhaps it would make sense to combine these into a single doc...? > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > <2013_05_02_14_39_09-mqs-draft.pdf>_______________________________________________ > 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

[Mpi3-tools] My comments on the MQS draft
by Jeff Squyres (jsquyres) 02 May '13

02 May '13

Anh -- Nicely done. Attached is a scan of my comments on the draft. We can chat about them on a phone call if they don't make sense... One big comment: didn't we agree at the last Forum meeting to have 1 big document with MPIR and MQS (and whatever else we dream up)? I can't find the notes from last meeting to remember what the Forum decided. If we did agree on one document: now that much of the MQS text has been written, perhaps it would make sense to combine these into a single doc...? -- 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] MPIT 3.1: look up by name
by Kathryn Mohror 02 May '13

02 May '13

Hi Bronis, all, We discussed this on the WG call today. I put the notes from the discussion on the wiki page. The gist of the conversation was that yes, it is a convenience function, but it may be worth having. The reason is that a tool can't simply iterate over the variables once and be done with it. The number of variables can increase at runtime, so a tool may have to iterate more than once. We settled on moving forward with a version of the routine that doesn't duplicate "get_info" but returns only the index and seeing how it plays out. Kathryn On May 2, 2013, at 6:19 AM, Bronis R. de Supinski <bronis(a)llnl.gov> wrote: > > I agree with Jeff that this request is a convenience function. > Not only do I think he is right about it not needing to be > performant and that an application could clearly do it > itself but any more efficient implementation could be replicated > at the application layer. For example, the tree-based approach > could be done with one pass over the list that builds the tree. > > On Thu, 2 May 2013, Jeff Squyres (jsquyres) wrote: > >> On May 1, 2013, at 1:06 AM, "Schulz, Martin" <schulzm(a)llnl.gov> wrote: >> >>>> Is this just a convenience function? >>> >>> An implementation could store all variables in a tree (or some other more efficient structure) eliminating the need for a loop in favor of a lower complexity lookup algorithm. How severe this problem is, is a different question. >> >> I don't think that efficiency is the issue here -- even for an MPI implementation with thousands of cvars, a loop over them would take microseconds, at most. More specifically: I was not under the impression that cvar access needed to be performant. >> >> I guess my point is that: regardless of mechanism, this functionality can definitely be implemented in the user application with the current MPIT APIs. Moving this functionality to *inside* MPIT is a convenience. >> >> I'm not saying this is a good or bad idea -- I'm just making sure we all understand what is being asked. :-) >> >>> If we want to go for such a function, I wonder, though, if we should return all the arguments from GET_INFO or just the index (that you can then use get the rest of the information). This would could both keep the document (we are mentioning the GET_INFO functions a lot) and the implementations (only one pair of routines with such complex prototypes) simpler. >>> >>> Martin >>> >>> >>>> >>>> >>>> On Apr 30, 2013, at 2:39 PM, Kathryn Mohror <kathryn(a)llnl.gov> wrote: >>>> >>>>> 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 >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> ________________________________________________________________________ >>> 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 >> >> >> -- >> 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 >> > _______________________________________________ > 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, May 2
by Kathryn Mohror 02 May '13

02 May '13

Hi all, I put notes on the wiki page from today's call. As always, feel free to let me know if I missed something or made an error. https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Tools/notes-2013-05-2 Kathryn On May 2, 2013, at 6:08 AM, Marc-Andre Hermanns <m.a.hermanns(a)grs-sim.de> wrote: > I will not be able to attend today, either. Sorry. > > Cheers, > Marc-Andre > > > On 01.05.13 20:54, John DelSignore wrote: >> Sorry, but I won't be able to make it tomorrow. I have a meeting conflict. >> >> Cheers, John D. >> >> >> Kathryn Mohror wrote: >>> Hi all, >>> >>> This is a reminder of our telecon tomorrow May 2 at 8:00 AM PDT, 11:00 >>> AM EDT. >>> >>> As always, the link for joining the webex is on the >>> wiki: https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Tools >>> >>> Agenda: >>> - What are our plans for the next forum meeting? >>> - MPI 3.1 items discussion >>> - Feedback on current MQS draft >>> >>> Kathryn >>> ______________________________________________________________ >>> Kathryn Mohror, kathryn(a)llnl.gov >>> <mailto:[email protected]>, 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 >> > > -- > 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 ______________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://people.llnl.gov/mohror1 CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA

1 0

Re: [Mpi3-tools] MPIT 3.1: look up by name
by Bronis R. de Supinski 02 May '13

02 May '13

I agree with Jeff that this request is a convenience function. Not only do I think he is right about it not needing to be performant and that an application could clearly do it itself but any more efficient implementation could be replicated at the application layer. For example, the tree-based approach could be done with one pass over the list that builds the tree. On Thu, 2 May 2013, Jeff Squyres (jsquyres) wrote: > On May 1, 2013, at 1:06 AM, "Schulz, Martin" <schulzm(a)llnl.gov> wrote: > >>> Is this just a convenience function? >> >> An implementation could store all variables in a tree (or some other more efficient structure) eliminating the need for a loop in favor of a lower complexity lookup algorithm. How severe this problem is, is a different question. > > I don't think that efficiency is the issue here -- even for an MPI implementation with thousands of cvars, a loop over them would take microseconds, at most. More specifically: I was not under the impression that cvar access needed to be performant. > > I guess my point is that: regardless of mechanism, this functionality can definitely be implemented in the user application with the current MPIT APIs. Moving this functionality to *inside* MPIT is a convenience. > > I'm not saying this is a good or bad idea -- I'm just making sure we all understand what is being asked. :-) > >> If we want to go for such a function, I wonder, though, if we should return all the arguments from GET_INFO or just the index (that you can then use get the rest of the information). This would could both keep the document (we are mentioning the GET_INFO functions a lot) and the implementations (only one pair of routines with such complex prototypes) simpler. >> >> Martin >> >> >>> >>> >>> On Apr 30, 2013, at 2:39 PM, Kathryn Mohror <kathryn(a)llnl.gov> wrote: >>> >>>> 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 >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> ________________________________________________________________________ >> 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 > > > -- > 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] MPIT 3.1: look up by name
by Jeff Squyres (jsquyres) 02 May '13

02 May '13

On May 1, 2013, at 1:06 AM, "Schulz, Martin" <schulzm(a)llnl.gov> wrote: >> Is this just a convenience function? > > An implementation could store all variables in a tree (or some other more efficient structure) eliminating the need for a loop in favor of a lower complexity lookup algorithm. How severe this problem is, is a different question. I don't think that efficiency is the issue here -- even for an MPI implementation with thousands of cvars, a loop over them would take microseconds, at most. More specifically: I was not under the impression that cvar access needed to be performant. I guess my point is that: regardless of mechanism, this functionality can definitely be implemented in the user application with the current MPIT APIs. Moving this functionality to *inside* MPIT is a convenience. I'm not saying this is a good or bad idea -- I'm just making sure we all understand what is being asked. :-) > If we want to go for such a function, I wonder, though, if we should return all the arguments from GET_INFO or just the index (that you can then use get the rest of the information). This would could both keep the document (we are mentioning the GET_INFO functions a lot) and the implementations (only one pair of routines with such complex prototypes) simpler. > > Martin > > >> >> >> On Apr 30, 2013, at 2:39 PM, Kathryn Mohror <kathryn(a)llnl.gov> wrote: >> >>> 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 >>> >>> >>> >>> >>> _______________________________________________ >>> 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 > > ________________________________________________________________________ > 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 -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0