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

Re: [Mpi3-tools] MPI handles hg moved
by Chen, Chih-Ping 11 Jun '09

11 Jun '09

Jeff, The comment from line 751 to line 760 is obsolete, given that mpidbg_comm_query_basic now rightfully returns the comm_type bitmask. -Chih-Ping >-----Original Message----- >From: mpi3-tools-bounces(a)lists.mpi-forum.org >[mailto:[email protected]] On Behalf Of >Jeff Squyres >Sent: Thursday, June 11, 2009 8:11 AM >To: mpi3-tools(a)lists.mpi-forum.org >Subject: [Mpi3-tools] MPI handles hg moved > >I have moved the MPI handles mercurial repository to a different >location. The interface header file is now located here: > > >http://bitbucket.org/jsquyres/mpi3-tools-handles/src/tip/ompi/d >ebuggers/mpihandles_interface.h > >-- >Jeff Squyres >Cisco Systems > >_______________________________________________ >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] MPI handles hg moved
by Jeff Squyres 11 Jun '09

11 Jun '09

I have moved the MPI handles mercurial repository to a different location. The interface header file is now located here: http://bitbucket.org/jsquyres/mpi3-tools-handles/src/tip/ompi/debuggers/mpi… -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi3-tools] Meeting/TelCon tomorrow 6/10/09
by Ashley Pittman 10 Jun '09

10 Jun '09

On Tue, 2009-06-09 at 10:56 -0700, Martin Schulz wrote: > The agenda so far is: > - Brief report back by Pavan on the PMI discussion > - Continued discussion on the MPI state interface proposal > - Discussion lead by Jeff on the updated MPI handle interface > > Please let me know if you want to bring up any other topic. Could I request some time to introduce and discuss my proposed collective extensions. http://padb.pittman.org.uk/extensions.html Ashley, -- Ashley Pittman, Bath, UK. Padb - A parallel job inspection tool for cluster computing http://padb.pittman.org.uk

1 0

[Mpi3-tools] Link for latest file
by Jeff Squyres 10 Jun '09

10 Jun '09

For discussion on the call today: http://www.open-mpi.org/hg/hgwebdir.cgi/jsquyres/mpi3-tools-handles/file/ti… -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi3-tools] Meeting/TelCon tomorrow 6/10/09
by Geoffrey R. Paulsen 09 Jun '09

09 Jun '09

I'm sorry, my scheduler has changed. I will be unable to attend this conference (even remotely). Geoff Paulsen HP-MPI Regarding Martin Schulz's message: > Hi all, > > As mentioned before, we are having an MPI 3 tools WG meeting tomorrow > morning as part of the MPI Forum face to face meeting. The plan is to > start at 9am PDT and we have a time slot until 11:30am, although we > don't have to use the whole time. > > Here is the dial-in information: > > Toll Free Dial In Number for Offsite Participants: 866-914-3976 > International Access/Caller Paid Dial In Number: 925-424-8105 > Dial In Number for LLNL Onsite Participants: 4-8105 > Access Security Code: 860609 # > > The agenda so far is: > - Brief report back by Pavan on the PMI discussion > - Continued discussion on the MPI state interface proposal > - Discussion lead by Jeff on the updated MPI handle interface > > Please let me know if you want to bring up any other topic. > > Thanks, > > Martin > > > > _______________________________________________________________________ > Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulz6 > 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] Meeting/TelCon tomorrow 6/10/09
by Martin Schulz 09 Jun '09

09 Jun '09

Hi all, As mentioned before, we are having an MPI 3 tools WG meeting tomorrow morning as part of the MPI Forum face to face meeting. The plan is to start at 9am PDT and we have a time slot until 11:30am, although we don't have to use the whole time. Here is the dial-in information: Toll Free Dial In Number for Offsite Participants: 866-914-3976 International Access/Caller Paid Dial In Number: 925-424-8105 Dial In Number for LLNL Onsite Participants: 4-8105 Access Security Code: 860609 # The agenda so far is: - Brief report back by Pavan on the PMI discussion - Continued discussion on the MPI state interface proposal - Discussion lead by Jeff on the updated MPI handle interface Please let me know if you want to bring up any other topic. Thanks, Martin _______________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulz6 CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0

Re: [Mpi3-tools] MPI Forum/face-to-face meeting details?
by Martin Schulz 08 Jun '09

08 Jun '09

Hi all, Sorry for the late response - I was out of email contact last week and just got back online this morning. In the meantime, Rich has rescheduled the WG meetings to Wednesday morning - from 9am to 11:30am PDT. I hope that this earlier time slot will allow more people to participate. I asked for a phone line so that people can dial in, but I didn't get confirmation for this, yet. I will check on this once I get there and if this is available (which I hope) than I will send out another email with the dial-in information. Martin At 08:46 AM 6/8/2009, Marty Itzkowitz wrote: >Well? When is the tools face-to-face meeting? > > Thanks, > Marty > >On 6/1/09 8:47 AM, Jeff Squyres wrote: >>Martin -- >> >>Can you send out the meeting details for next week so that people >>know how/where to meet, and how to dial in? >> >>Thanks! >_______________________________________________ >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/schulz6 CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0

Re: [Mpi3-tools] MPI Forum/face-to-face meeting details?
by Marty Itzkowitz 08 Jun '09

08 Jun '09

Well? When is the tools face-to-face meeting? Thanks, Marty On 6/1/09 8:47 AM, Jeff Squyres wrote: > Martin -- > > Can you send out the meeting details for next week so that people know > how/where to meet, and how to dial in? > > Thanks! >

1 0

Re: [Mpi3-tools] MPI handles debugging interface
by David Lecomber 03 Jun '09

03 Jun '09

Hi John and all, FWIW, all tools folks will do is just dlsym() lookups for the function, casting them to what we expect them to be, and calling them. So, only so long as the tool implementor has the same version of the header file as the library had, do we have type safety - hence extensions to existing functions and structs must be ruled out, extensions can only come via new functions and new structs. Can we be sure, in defining something strictly, that we've thought of everything? Ashley mentioned an extra byte count field, which is just one example we missed last year in defining an interface. The OMPI guys have a few extra fields at the end of a struct in the old MPI debug interface -- knowing that no-one else is using those. I guess what I had in mind was more a "Properties" style approach, you ask the debug interface what properties are supported, it gives you a list back, and you call a single function to get their (single) values - eg. communicator_get_attribute(foo). That'd give a debugger the ability to say "this communicator has attribute 'foo', I haven't a clue what it means, but I'm telling you it has value 'bar'" -- for any MPI added extension from day one. Overkill probably, but I just wanted to check opinions. Regards David On Wed, 2009-06-03 at 09:40 -0400, John DelSignore wrote: > IMHO, type safety is extremely important and any solution that is not type safe is a non-starter. > > Cheers, John D. > > > Jeff Squyres wrote: > > In chatting with David Lecomber while we're working on revising the MPI3 > > handle debugging interface per the recent discussions in this group > > (moving away from the One Big Struct approach), David asked a me a > > question that I thought might be appropriate for the larger group. > > > > Why use a bunch of individual query functions when we could have a > > single, much more general form that is more easily extensible? The > > query function would essentially be driven by an enum indicating the > > specific request, and the OUT arguments could be varargs. Perhaps > > something like this: > > > > ===== > > int mpidbg_comm_query_element(mpidbg_comm_handle_t handle, > > enum mpidbg_comm_query_element_t element, > > ...); > > ===== > > > > Here's a sample use case: > > > > ===== > > /* initial query to allow the DLL to bundle up *all* the data into a > > handle */ > > mpidbg_comm_query(image, image_info, ..., mpi_communicator, &handle); > > > > /* Query the "basic" communicator info from the handle */ > > mpidbg_comm_query_element(handle, MPIDBG_COMM_QUERY_BASIC, &flags, > > &rank, &size, ...etc.); > > > > /* Query the communicator process info from the handle */ > > mpidbg_comm_query_element(handle, MPIDBG_COMM_QUERY_PROCS, > > &num_local_procs, &local_procs, > > &num_remote_procs, &remote_procs); > > ===== > > > > +++ Advantage: this one function can be extended simply by adding new > > enum values, possibly in an MPI implementation-specific way (e.g., have > > some non-standard / value-add functions) > > > > --- Disadvantage: lose compiler type safety checking when > > building/debugging tools that use this interface. > > > > I don't have strong feelings either way. I think I'm marginally in > > favor of individual functions just because it gives type safety for > > tools authors. But I could be convinced to go the enum/varargs route if > > people feel strongly. > > > > Comments? > > > > --Jeff Squyres > > Cisco Systems > > > > _______________________________________________ > > 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

1 0

Re: [Mpi3-tools] MPI handles debugging interface
by John DelSignore 03 Jun '09

03 Jun '09

IMHO, type safety is extremely important and any solution that is not type safe is a non-starter. Cheers, John D. Jeff Squyres wrote: > In chatting with David Lecomber while we're working on revising the MPI3 > handle debugging interface per the recent discussions in this group > (moving away from the One Big Struct approach), David asked a me a > question that I thought might be appropriate for the larger group. > > Why use a bunch of individual query functions when we could have a > single, much more general form that is more easily extensible? The > query function would essentially be driven by an enum indicating the > specific request, and the OUT arguments could be varargs. Perhaps > something like this: > > ===== > int mpidbg_comm_query_element(mpidbg_comm_handle_t handle, > enum mpidbg_comm_query_element_t element, > ...); > ===== > > Here's a sample use case: > > ===== > /* initial query to allow the DLL to bundle up *all* the data into a > handle */ > mpidbg_comm_query(image, image_info, ..., mpi_communicator, &handle); > > /* Query the "basic" communicator info from the handle */ > mpidbg_comm_query_element(handle, MPIDBG_COMM_QUERY_BASIC, &flags, > &rank, &size, ...etc.); > > /* Query the communicator process info from the handle */ > mpidbg_comm_query_element(handle, MPIDBG_COMM_QUERY_PROCS, > &num_local_procs, &local_procs, > &num_remote_procs, &remote_procs); > ===== > > +++ Advantage: this one function can be extended simply by adding new > enum values, possibly in an MPI implementation-specific way (e.g., have > some non-standard / value-add functions) > > --- Disadvantage: lose compiler type safety checking when > building/debugging tools that use this interface. > > I don't have strong feelings either way. I think I'm marginally in > favor of individual functions just because it gives type safety for > tools authors. But I could be convinced to go the enum/varargs route if > people feel strongly. > > Comments? > > --Jeff Squyres > Cisco Systems > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > >

1 0