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

[Mpi3-tools] Moving next MPI tools WG TelCon to 5/11
by Martin Schulz 30 Apr '09

30 Apr '09

Hi all, For our next TelCon we decided to look into the implementation aspects and problems of the MPI state interface proposed by Sun. Unfortunately, the main developer for this is not available on Monday 5/4. Also, I have a conflict on 5/18. Hence, I am suggesting to move this topic and the next MPI tools TelCon to 5/11 (same time, same number). I hope this doesn't cause a larger problems for anyone. If someone would like to propose a different/new topic for next week instead, that would be fine as well, but please speak up soon, so that everybody knows this in advance. If not, we'll speak on 5/11. 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 handles interface
by Ashley Pittman 21 Apr '09

21 Apr '09

On Tue, 2009-04-21 at 09:41 -0400, Jeff Squyres wrote: > On Apr 21, 2009, at 5:56 AM, Ashley Pittman wrote: > In addition to John's reply... > > The suggestion was made on the call yesterday Ah, I wondered why no-body was on-line at 4pm today :( I got thrown by the reminder email arriving yesterday! Ashley Pittman.

1 0

Re: [Mpi3-tools] MPI handles interface
by Jeff Squyres 21 Apr '09

21 Apr '09

On Apr 21, 2009, at 5:56 AM, Ashley Pittman wrote: > > Could I get some comments on the group as to the general style of > what > > I did? > > The general style looks OK to me, without digging too far however I'm > concerned about the idea of the DLL allocating memory and then having > the debugger free it, this seems like a recipe for disaster to me. > In addition to John's reply... The suggestion was made on the call yesterday to [effectively] convert the (image, image_info, process, process_info, c_comm) tuple into an opaque handle that is then queried by the individual functions. Hence, instead of passing that big tuple to each of the query functions (and therefore potentially having the DLL re-lookup the data in each query function), have the DLL do all the lookups at once, possibly store it in a DLL-internal One Big Struct, and then return an opaque handle to it to the debugger. The debugger then uses that handle for the individual query functions, which then become quite simple in the DLL (i.e., copy from the handle to the OUT params). The debugger eventually invokes a function to free the handle. I haven't made these modifications yet, but I will. -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi3-tools] MPI handles interface
by John DelSignore 21 Apr '09

21 Apr '09

Ashley Pittman wrote: > On Thu, 2009-04-16 at 17:31 -0400, Jeff Squyres wrote: >> What about enums -- will those be problematic? I tended to prefer >> enums in most places (vs. #define's) because a debugger can show those >> value names (when debugging this software itself -- not necessarily >> when in general use by a debugger for an MPI job). If enums are going >> to be problematic, I can switch to #defines -- but it would be nice >> not to, if possible. > > For reference the original code uses enums. > >> The communicator "query" functions that I created start around line 649: >> >> http://www.open-mpi.org/hg/hgwebdir.cgi/jsquyres/mpi3-tools-handles/file/4c… >> >> Could I get some comments on the group as to the general style of what >> I did? > > The general style looks OK to me, without digging too far however I'm > concerned about the idea of the DLL allocating memory and then having > the debugger free it, this seems like a recipe for disaster to me. I don't think this is a problem. In the existing message queue interface, "malloc" and "free" are callback functions that the debugger passes to the DLL. The DLL shouldn't call malloc or free directly. Instead, when the DLL need to alloc storage, it calls the malloc callback function which calls back into the debugger, and the debugger can implement the call back however it likes: C malloc, C++ new[], etc. When it comes time for the debugger to deallocate the block, it should use the matching function: C free, C++ delete[], etc. In practice, it all works out just fine. Cheers, John D. > I should be in the TelCon later all being well. > > Ashley Pittman. > > _______________________________________________ > 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 interface
by Ashley Pittman 21 Apr '09

21 Apr '09

On Thu, 2009-04-16 at 17:31 -0400, Jeff Squyres wrote: > What about enums -- will those be problematic? I tended to prefer > enums in most places (vs. #define's) because a debugger can show those > value names (when debugging this software itself -- not necessarily > when in general use by a debugger for an MPI job). If enums are going > to be problematic, I can switch to #defines -- but it would be nice > not to, if possible. For reference the original code uses enums. > The communicator "query" functions that I created start around line 649: > > http://www.open-mpi.org/hg/hgwebdir.cgi/jsquyres/mpi3-tools-handles/file/4c… > > Could I get some comments on the group as to the general style of what > I did? The general style looks OK to me, without digging too far however I'm concerned about the idea of the DLL allocating memory and then having the debugger free it, this seems like a recipe for disaster to me. I should be in the TelCon later all being well. Ashley Pittman.

1 0

Re: [Mpi3-tools] Reminder: TelCon tomorrow morning
by Kiril Dichev 20 Apr '09

20 Apr '09

Hi guys, my name ist Kiril Dichev, I work in HLRS (Stuttgart, Germany). I will join the telco. I am currently investigating the profiling interface PERUSE in Open MPI. I am interested to hear about the state and/or performance information API. Regards, Kiril -- Dipl.-Inf. Kiril Dichev Tel.: +49 711 685 60492 E-mail: dichev(a)hlrs.de High Performance Computing Center Stuttgart (HLRS) Universität Stuttgart 70550 Stuttgart Germany

1 0

[Mpi3-tools] Reminder: TelCon tomorrow morning
by Martin Schulz 20 Apr '09

20 Apr '09

Hi all, Just as a reminder - we are having our biweekly MPI tools WG TelCon tomorrow/Monday at 8am PT, 11am ET, 4pm UK, 5pm MST. The dial-in number is: > 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 # Agenda: - Quick recap of the outcome from the meeting on 4/7/09 - Ability for people not present during this meeting to comment - Short discussion on whether to include PMI (Process Management Interface) in this WG - Majority of the time: state and/or performance information API Cheers, 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 handles interface
by Jeff Squyres 17 Apr '09

17 Apr '09

On Apr 16, 2009, at 7:30 PM, Bronis R. de Supinski wrote: > Hmm. My expectation was there would be query functions > for individual fields, a la MPI_Get_count. I guess I > don't have a strong feeling about it -- when you want > only one field, you will pay a somewhat significant > cost with your approach but your approach will be an > even bigger win when you want all of them. It may be > harder for an implementation to add fields with your > approach, I don't know... > I could certainly make an accessor function for *each* field. But instead I grouped them into "related" fields. E.g., if you're going to ask for the how many dimensions there are in the cartesian topology, you're probably also going to want to the array of the dimension lengths as well (at least, that's what I assumed). This got me down to 6 query functions instead of 21, which, all things being equal, I figured was a good thing. I certainly could make them a bit more fined-grained -- for example, the initial function (_query_basic()) is returning a bunch of basic information that isn't really grouped together: - communicator name - bit flags - this proc's rank - size - fortran handle - c++ handle If people feel strongly, I'm happy to make 21 query functions. Whateveah. :-) As for adding implementation-specific fields, I don't think this proposal addresses that at all. If Microsoft wants to make a proposal about adding vendor-specific fields, I'd love to see it. :-) -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi3-tools] MPI handles interface
by Bronis R. de Supinski 16 Apr '09

16 Apr '09

Jeff: Hmm. My expectation was there would be query functions for individual fields, a la MPI_Get_count. I guess I don't have a strong feeling about it -- when you want only one field, you will pay a somewhat significant cost with your approach but your approach will be an even bigger win when you want all of them. It may be harder for an implementation to add fields with your approach, I don't know... Bronis On Thu, 16 Apr 2009, Jeff Squyres wrote: > I took a first shot at removing the One Big Struct-ness (OBS) of the > MPI handles proposal: I removed the OBS from communicators and > replaced it with several "query" functions. A few structs still > remain -- those that are all pointers, for example, or those that will > likely otherwise not be problematic (e.g., not have holes). > > I only updated the communicators section in the header file; I did not > yet update the other 3 handle types that were prototyped (MPI_Status, > MPI_Request, MPI_Errhandler). I also did not yet update the > implementation to match, so it won't compile. I wanted to get some > feedback from the group before continuing. > > What about enums -- will those be problematic? I tended to prefer > enums in most places (vs. #define's) because a debugger can show those > value names (when debugging this software itself -- not necessarily > when in general use by a debugger for an MPI job). If enums are going > to be problematic, I can switch to #defines -- but it would be nice > not to, if possible. > > The communicator "query" functions that I created start around line 649: > > http:// www. open-mpi.org/hg/hgwebdir.cgi/jsquyres/mpi3-tools-handles/file/4c5c1e7c0ef1/… > > Could I get some comments on the group as to the general style of what > I did? > > If the web interface is too klunky for you, you can clone the repo > with Mercurial: > > hg clone http:// www. open-mpi.org/hg/hgwebdir.cgi/jsquyres/mpi3-tools-handles > > The individual file to look at is ompi/debuggers/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 interface
by Jeff Squyres 16 Apr '09

16 Apr '09

I took a first shot at removing the One Big Struct-ness (OBS) of the MPI handles proposal: I removed the OBS from communicators and replaced it with several "query" functions. A few structs still remain -- those that are all pointers, for example, or those that will likely otherwise not be problematic (e.g., not have holes). I only updated the communicators section in the header file; I did not yet update the other 3 handle types that were prototyped (MPI_Status, MPI_Request, MPI_Errhandler). I also did not yet update the implementation to match, so it won't compile. I wanted to get some feedback from the group before continuing. What about enums -- will those be problematic? I tended to prefer enums in most places (vs. #define's) because a debugger can show those value names (when debugging this software itself -- not necessarily when in general use by a debugger for an MPI job). If enums are going to be problematic, I can switch to #defines -- but it would be nice not to, if possible. The communicator "query" functions that I created start around line 649: http://www.open-mpi.org/hg/hgwebdir.cgi/jsquyres/mpi3-tools-handles/file/4c… Could I get some comments on the group as to the general style of what I did? If the web interface is too klunky for you, you can clone the repo with Mercurial: hg clone http://www.open-mpi.org/hg/hgwebdir.cgi/jsquyres/mpi3-tools-handles The individual file to look at is ompi/debuggers/mpihandles_interface.h. -- Jeff Squyres Cisco Systems

1 0