[Mpi3-tools] Last Chance: Changes to the MPI_T*_ document

[Martin Schulz]

Hi all,

Any more comments on the changes to the MPI_T 
document? I plan on uploading it tomorrow
afternoon to make the two week deadline.

Thanks,

Martin



Begin forwarded message:

> From: Martin Schulz <schulzm at llnl.gov>
> Date: August 27, 2011 6:29:04 PM PDT
> To: MPI3 Tools <mpi3-tools at lists.mpi-forum.org>
> Subject: Re: [Mpi3-tools] Changes to the MPI_T*_ document
> Reply-To: Martin Schulz <schulzm at llnl.gov>
> 
> Hi all,
> 
> I created a new version of the MPI_T document based on
> the feedback from the MPI forum plus some additional
> comments. The new draft is at:
> 
> https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/wiki/MPI3Tools/mpit/mpi-report.21.pdf
> 
> Please take a look at it and see if any more changes are
> necessary. To meet the two week rule, we have until 9/8
> to post the document to the MPI forum.
> 
> I don't think we need another tools TelCon until then (but
> please speak up if you think we do or if there are any
> other topics to cover), but I still would like feedback
> on the questions that I sent around in the last email -
> so far I have only heard from Bronis; additional feedback
> would be helpful.
> 
> 
> A) Naming: MPI_T or a different name? 
> ==============================
> 
> I have changed all names to be MPI_T_<lowercase>, but
> I have not made any further name changes. Bronis's vote 
> was for keeping just the "T" and that would be the easiest and
> least disruptive to both the document and the existing
> prototype(s). Does anybody have a good idea or a
> strong opinion about this? 
> 
> 
> B) Types: which types to support?
> ==========================
> 
> The new document has the following list:
> MPI_INT
> MPI_UNSIGNED
> MPI_UNSIGNED_LONG
> MPI_UNSIGNED_LONG_LONG
> MPI_COUNT
> MPI_CHAR
> MPI_DOUBLE
> 
> With the following rationale included in the text:
> 
> The \MPI/ tool information interface relies mainly on unsigned
> datatypes for integer values since most variables are expected
> to represent counters or resource sizes. \const{MPI\_INT} is
> provided for additional flexibility and is expected to be used
> mainly for control variables. 
> 
> Providing all basic datatypes, in particular providing all signed
> and unsigned variants of integer types, would lead to a larger
> number of types, which tools need to interpret. This would
> cause unnecessary complexity in the implementation of tools
> based on the \MPI/ tool information interface.
> 
> 
> C) Signal safety
> =============
> 
> I liked Bronis's version of the text and included it in the document.
> I'll also start a separate email with Brian to get his feedback.
> 
> 
> If there are any other pending issues with this document, please
> let me know. I really hope we can make the next first reading the
> last reading, but for this it would be extremely helpful if more
> people would look over the document!
> 
> Thanks!
> 
> Martin
> 
> 
> 
> 
> On Aug 17, 2011, at 4:37 PM, Bronis R. de Supinski wrote:
> 
>> 
>> Martin:
>> 
>> Re:
>>> - Naming: People didn't like MPI_T_ and wanted something
>>> more expressive. MPI_Tool_ would be the obvious choice
>>> and that would be fine with me. Does anyone have a better
>>> suggestion? We can't spend more than four characters on
>>> it, though, or we will run into problems with the max. name
>>> size (even after shortening some names). Also, I would like
>>> this to be the final name change :).
>> 
>> I still feel that MPI_T is the best choice. No matter
>> what prefix you choose, someone will not like it.
>> 
>> [snip]
>> 
>>> - We had some lengthy discussion on the thread and async
>>> signal safety. Below is a suggestion for a rewrite - once I get
>>> some feedback from our group, I will forward this to Brian,
>>> since he had the most issues with the current wording.
>>> 
>>> \begin{implementors}
>>> Sampling based tools rely on the ability to call the MPI
>>> tool information interface, in particular routines to start, stop,
>>> read, write and reset performance variables, from any program
>>> context, including asynchronous contexts such as signal handlers.
>>> MPI implementations should strive, if possible in their particular
>> 
>> OK through the above.
>> 
>>> environment, to enable this behavior for all or a subset of the
>> 
>> Which "behavior"? You do not define any behavior above. You
>> define support for usage scenarios. Change to:
>> 
>> environment, to enable these usage scenarios for all or a subset of the
>> 
>>> routines mentioned above. If implementing only a subset, the
>>> read, write, and reset routines are typically the most critical
>> 
>>> for sampling based tools. If an MPI implementation
>>> is not able to provide such a behavior or if the behavior is only
>>> guaranteed under certain circumstances (e.g., for certain signals),
>>> this should be clearly documented, e.g., through the description
>>> return by {\mpifunc MPI\_T\_Get\_info}.
>> 
>> "such a"? UGH! Poor antecedent for "this". "return by"? Huh?
>> 
>> change to:
>> 
>> for sampling based tools. An MPI implementation should clearly
>> document any restrictions on the program contexts in which
>> the MPI tool information interface can be used. Restrictions
>> might include guaranteeing usage outside of all signals or
>> outside a specific set of signals. Any restrictions could be
>> documented, for example, through the description returned by
>> {\mpifunc MPI\_T\_Get\_info}.
>> 
>>> \end{implementors}
>> 
>> Bronis
>> 
> 
> ________________________________________________________________________
> Martin Schulz, schulzm at llnl.gov, http://people.llnl.gov/schulzm
> CASC @ Lawrence Livermore National Laboratory, Livermore, USA
> 
> 
> 

________________________________________________________________________
Martin Schulz, schulzm at llnl.gov, http://people.llnl.gov/schulzm
CASC @ Lawrence Livermore National Laboratory, Livermore, USA