Re: [Mpi3-rma] RMA chapter for quick review
Bill: I like your wording below that use "The programmer". Bronis On Sat, 12 Mar 2011, William Gropp wrote:
On Mar 11, 2011, at 11:43 AM, Bronis R. de Supinski wrote:
Rajeev:
Re:
An updated version of the RMA chapter is attached to this mail and on the wiki. We would like to make it available to the Forum by tomorrow afternoon in order to meet the two-week window for the first reading at the March meeting. If you have a chance, please take a look at it and let us know your comments before tomorrow afternoon.
I went through section 11.1 and found ticket 0 type changes. I don't know when I will have time to finish so if I hit something more significant I will just have to apologize.
Anyway, using [p#, l#] notation:
[1, 20]: fix split infinitive: to access or update => to access or to update
Done
[1, 21-23]: I would like to remove the personification of the processes in "However, processes may not know which data in their own memory need to be accessed or updated by remote processes, and may not even know the identity of these processes." Processes do not "know"; however, I have not thought of good alternative wording yet. Perhaps: "However, a process may not necessarily be able to compute what data in its local memory that remote processes need to access or even the identity of those processes."
This really refers to the programmer, so I've proposed an alternative:
However, the programmer may not be able to easily determine which data in a process may need to be accessed or to be updated by operations executed by a different process, and may not even know which processes may perform such updates.
[1, 26]: Clarify antecedent: This may => This distribution may
Done
[1, 27]: Fix split infinitives and dangling preposition:
to periodically poll for potential communication requests to receive and act upon. =>
to poll for potential communication requests to receive and upon which to act periodically.
Torsten already fixed
[1, 35-38]: In the list: "MPI_PUT (remote write), MPI_GET (remote read), [and] MPI_ACCUMULATE (remote update), MPI_GET_ACCUMULATE, MPI_FETCH_AND_OP (remote read and update), MPI_COMPARE_AND_SWAP (remote atomic swap operations), MPI_RPUT, MPI_RGET, MPI_RACCUMULATE and MPI_RGET_ACCUMULATE"; it is odd that a subset of the operations have parenthetical expressions that indicate the nature of the functionality. Either all operations should be followed with a parenthetical explanation or none of them. The right solution is probably to reformat into a list with each item being the group of operations that provide functionality of the same nature (e.g., I am guessing that MPI_GET and MPI_RGET are both remote read operations). Initially I thought the ones that are not followed by a parenthetical expression were being grouped with the following one that has the parenthetical expression (so MPI_GET_ACCUMULATE is a remote read and update operation). However, the list ends with several operations with no following parenthetical expression. Anyway, the implicit grouping is unclear. Making it explicit would be better. It would also simplify how the following sentence ("When a reference is made to �accumulate� operations in this chapter, it refers to the following operations: MPI_ACCUMULATE, MPI_GET_ACCUMULATE, MPI_FETCH_AND_OP, MPI_COMPARE_AND_SWAP, MPI_RACCUMULATE and MPI_RGET_ACCUMULATE.") simpler.
[1, 44-45] Use active voice: correct ordering of memory accesses has to be imposed by the user, using synchronization calls; => the user must impose correct ordering of memory accesses through synchronization calls;
Done by Torsten
[2, 8] Change: "operations, communication coprocessors, etc." to "operations, and communication coprocessors." The clause begins with "such as" so the "etc." is redundant (not to mention caused the omission of the period that should end the sentence).
Done
[2, 12] Use active voice: "However, support for asynchronous communication agents in software (handlers, threads, etc.) might be needed, for certain RMA functions, in a distributed memory environment." => "However, certain RMA functions might need support for asynchronous communication agents in software (handlers, threads, etc.) in a distributed memory environment."
Done
Bronis
In particular: - We fixed some issues with the rules on pg 47 and 48. Please take a look at those rules in their entirety. - pg 3, ln 43, has been updated to specify that default value for the accumulate_ops key is same_op_no_op.
Thanks, Rajeev
<ATT00001.txt>
William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign
participants (1)
-
Bronis R. de Supinski