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

Re: [Mpi3-tools] Agenda for next TelCon, Monday 2/21
by Marc-André Hermanns 21 Feb '11

21 Feb '11

Hi all, On 19.02.2011, at 02:30, Martin Schulz wrote: > - Naming: people wanted us to move into the MPI namespace > - Which prefix should we use? > - How do we distinguish the semantics? Following the Wikipedia entry to C99 I looked up the PDF document of the C standard, and there on page 20 on the bottom (section 5.2.4.1) it states: http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf "The implementation shall be able to translate and execute at least one program that contains at least one instance of every one of the following limits […] - 31 significant initial characters in an external identifier (each universal character name specifying a short identifier of 0000FFFF or less is considered 6 characters, each universal character name specifying a short identifier of 00010000 or more is considered 10 characters, and each extended source character is considered the same number of characters as the corresponding universal character name, if any) …" Aside from comment in parentheses, which I admit I don't understand, I think it says that to guarantee compiler support, we have to stick to the 30/31 character limit already stated in the MPI 2.2 standard, right? Cheers, Marc-Andre PS: I also checked the draft of C1x with the same results, so I guess they don't plan to change it. -- Marc-Andre Hermanns German Research School for Simulation Sciences GmbH c/o Laboratory for Parallel Programming 52056 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. | Dr. Norbert Drewes

1 0

[Mpi3-tools] Agenda for next TelCon, Monday 2/21
by Martin Schulz 18 Feb '11

18 Feb '11

Hi all, Sorry for the late notice - our next MPI-3 Tools TelCon is scheduled for next Monday 2/21 at the usual time 8am PST, 11m EST, 5pm MEZ. I know that this is a holiday for some of you (including us at LLNL), but moving it would probably cause more problems than it would help and I didn't want to cancel since we only have a few weeks before we have to have the MPIT document ready for a first reading. If you can't make it, please feel free to send comments to the email list, for the rest Jeff has setup a Webex as usual: https://cisco.webex.com/ciscosales/j.php?ED=160088522&UID=0&PW=NMzcyMGEyNjN… Password: tools The information is also on the Wiki. The main point on the agenda is to go over the feedback on the MPIT draft from the last forum meeting and to discuss how to proceed. The open issues are (as far as I can see): - Naming: people wanted us to move into the MPI namespace - Which prefix should we use? - How do we distinguish the semantics? - Types: people didn't like a separate type system - Can we use the MPI type systems? - Can we address this otherwise? - Threading: what are the implications on threading? - Do we need to specify thread support? - What is the impact on sessions? - What are the semantics of MPIT_Init if called before MPI_Init? - Do all processes have to call it and what does this mean? - How do we handle the case of an implementation that uses fork in MPI_Init to spawn rank processes? - Smaller issues - Inclusion of BOOLEAN in the type system and implications for C - How to handle variables that are strings? - Connection between timer variables and values from MPI_Wtime - Overlap/Distinction of MPI and MPIT return codes - How do we deal with 30 character limit on names? - Clarification on NULL buffer passed to routines returning strings If I missed anything, please add it to the list - also, any further feedback on the text would be great! The draft is on the tools Wiki and on ticket #266. Thanks! Martin ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0

[Mpi3-tools] another note on MPIT proposal text
by Jeff Squyres 08 Feb '11

08 Feb '11

Martin -- In flipping through MPI-2.2 today, looking at the various language-neutral bindings, I see that many of the 1-line description of arguments are followed by a parenthetical -- e.g., "(handle)" or "(logical)" or "(integer)". It strikes me that we should follow this same convention in the MPIT proposal. -- 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] Draft of the MPIT Specification for the Presentation at February MPI Forum
by Dave Goodell 03 Feb '11

03 Feb '11

[dropping mpi-forum@ to discuss the proposal] I've implemented a rough set of stubs for the MPIT interface in MPICH2 as "MPITX_*". I'm sure they'll undergo numerous changes before we actually get something that goes into the public version of MPICH2. However, now that I have them I tried to actually implement some of the simpler functionality, namely the control variable portion of the interface. Unfortunately I've run into some trouble while doing this. In particular, the datatype functionality doesn't quite match up with the way that you want to use the interface. For example, in MPICH2 we have four different types of controlvars (which we call parameters or params internally): integers, doubles, booleans, and strings. The first two are clearly handled by MPIT_INT and MPIT_DOUBLE. But the latter two present some problems. The MPIT interface doesn't provide a boolean, and it's not obvious what the ideal choice is as a substitute. MPIT_LOGICAL is specified by the current draft, but MPI_LOGICAL corresponds to *Fortran* LOGICAL, not any C type. We could add MPIT_C_BOOL corresponding to MPI_C_BOOL and C's _Bool type, but that effectively mandates partial C99 support. Really we want a type that means "pass an int here and it will be used for boolean values". Maybe call it MPIT_BOOLEAN? Strings are also slightly problematic. What's the right type here, MPIT_CHAR with a count greater than 1? That's awkward, since it basically mandates that the library use a fixed size buffer for any string controlvars. Why shouldn't the library be able to take a string argument and strdup() it? We would no longer mirror the MPI_Datatype types exactly, but IMO an MPIT_STRING would be a helpful addition. I think that this also further underscores the need for some example programs to help us with the API. -Dave On Jan 27, 2011, at 7:07 PM CST, Martin Schulz wrote: > Hi all, > > As probably many of you know, the MPI-3 WG on tools has > been (and is) working on an extension to MPI that allows > tools (as well as adaptive runtime systems or applications) > access to MPI internals. We have named this interface MPIT. > > The WG has converged on a draft for MPIT that we plan to > introduce into the MPI forum process for inclusion into MPI-3. > Following the new rules for MPI-3 standardization, I will be > presenting this draft at the next MPI forum meeting on Tuesday > afternoon. > > To help this discussion, the current version is attached to > this email. As part of this proposal, we also propose to > create an overarching chapter on tools, which includes > both the existing (unmodified) PMPI interface and the > new MPIT specification. This is reflected in the attached > draft document. > > I will upload it to the Tools WG Wiki as well as the MPI > SVN at the following URL (once the I can get back onto > the servers, which seem to be down at the moment): > > https://svn.mpi-forum.org/svn/mpi-forum-docs/trunk/working-groups/mpi-3/too… > > Let me know if you have any questions or comments > ahead of the presentation! > > Thanks, > > Martin > > <mpi-report.pdf> > > ________________________________________________________________________ > 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