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 <[email protected]> Date: August 27, 2011 6:29:04 PM PDT To: MPI3 Tools <[email protected]> Subject: Re: [Mpi3-tools] Changes to the MPI_T*_ document Reply-To: Martin Schulz <[email protected]>
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/...
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, [email protected], http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA
________________________________________________________________________ Martin Schulz, [email protected], http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA