Re: [mpiwg-tools] proposed text
Uploading the current text in this email. Comment away! Kathryn _________________________________________________________________ Kathryn Mohror, [email protected], http://scalability.llnl.gov/ Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA On 11/22/14, 4:08 PM, "Jeff Squyres (jsquyres)" <[email protected]> wrote:
Forgot to say: it is not necessary to say that n can be different in different processes. That is up to the specification of params for each function. We're only defining equivalent strings here.
Sent from my phone. No type good.
On Nov 22, 2014, at 5:04 PM, Kathryn Mohror <[email protected]> wrote:
Hi Jeff,
Thanks for the feedback!
I made all the changes and agree with them for the most part (new document attached). Comments inlined:
p9:40-p10:1 reads:
I'd change it to be:
MPI implementations behave as if they have an internal character array that is copied to the output character array supplied by the user. Such output strings are defined to be equivalent if their notional source internal character arrays are identical (up to and including the null terminator), even if the output string is truncated due to a small n length parameter.
"due to a small n length parameter." For some reason the word "small" seems odd to me here. Do we want it to be more formal, and specify that it's the input value of n that causes the truncation and that n could be different on different processes?
Nit picks =========
1. p7:23-26 reads:
I'd change the parenthetical to:
Variables and categories across connected processes with equivalent names are required to have the same meaning (***please see the definition of "equivalent" as related to strings in*** Section 14.3.3).
I'm assuming you didn't mean the *** literally but to draw attention to the change. Also, I'm not sure if Bronis will chime in to correct our punctuation here, but I believe because the parenthetical text forms a complete sentence we would need to treat it as such, i.e. With proper capitalization and punctuation. However, I don't know for sure, so if someone does, please speak up!
Thanks for the rest of your comments and the example of why we don't want to include enumerations.
Kathryn
3. p7:27-28 says:
For example, variables describing the number of packets sent on heterogeneous network devices should have different names to reflect their potentially different meanings.
I'd change it to be:
For example, variables describing the number of packets sent on ***different types of*** network devices should have different names to reflect their potentially different meanings.
I know that "heterogeneous" means "different types", but that word carries a different connotation here, IMHO -- "heterogeneity" is somewhat of a loaded word in HPC environments (e.g., it's usually applied to processors and brings up a slightly confusing context here -- so let's just avoid it).
Enumerations ============
Yes, enumerated values must *not* be defined as equivalent.
I have a concrete example why they should not be equivalent:
- Remember that I want to use enumerated values to contain information about the underlying network - The network interface used by MPI processes on server A has network address "A.B.C.D", but the NI used by MPI processes on server B has address "W.X.Y.Z".
On Nov 21, 2014, at 11:48 AM, Kathryn Mohror <[email protected]> wrote:
The updated version is attached. Please comment if you have a chance so we can get this done by Monday.
Thank you! Kathryn _________________________________________________________________ Kathryn Mohror, [email protected], http://scalability.llnl.gov/ Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA
On 11/21/14, 7:09 AM, "Kathryn Mohror" <[email protected]> wrote:
Thanks for the feedback Michael and Marc-Andre! I'll make the changes later this morning and send them out.
Kathryn _________________________________________________________________ Kathryn Mohror, [email protected], http://scalability.llnl.gov/ Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA
On 11/21/14, 2:38 AM, "Marc-Andre Hermanns" <[email protected]> wrote:
Hi all,
I have an issue with the new text. I'm not sure if I'm missing a point, but for me the equivalence text is redundant. I fail to see a difference between (page 9, lines 43ff)
Strings are equivalent if the MPI implementation behaves as if it has an identical character array in each MPI process for the string in question across connected processes. The contents of the returned string will be identical to that of the internal character array, but possibly truncated at any process that supplies an n value to the query routine that is smaller than the length of the internal character array.
I also think this covers all cases.
a) a string is equivalent to its internal "source" if it behaves as if being copies from it up the the given length.
b) two strings are equivalent when they behave as if the originate from an identical source.
and (page 10, lines 1ff)
Two strings are equivalent if the internal character array for each MPI process is identical by a character-by-character comparison, and in the output buffer, any arbitrary combination of length arguments result in the same string-prefix up to the smaller of the two lengths.
So I'll probably would remove the second part (although I still like the wording).
Any opinions on that?
I talked to Michael on this, and I also think the second part can be omitted.
The rest looks fine so far.
dito.
Cheers, Marc-Andre -- Marc-Andre Hermanns Jülich Aachen Research Alliance, High Performance Computing (JARA-HPC) German Research School for Simulation Sciences GmbH
Schinkelstrasse 2 52062 Aachen Germany
Phone: +49 241 80 99753 Fax: +49 241 80 6 99753 www.grs-sim.de/parallel email: [email protected]
_______________________________________________ mpiwg-tools mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools
<tools-3.pdf>_______________________________________________ mpiwg-tools mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools
-- Jeff Squyres [email protected] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
_______________________________________________ mpiwg-tools mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools
<tools-3.pdf> _______________________________________________ mpiwg-tools mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools
mpiwg-tools mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools
participants (1)
-
Kathryn Mohror