[Mpi3-rma] RMA chapter for quick review
Bronis R. de Supinski
bronis at llnl.gov
Sat Mar 12 10:48:53 CST 2011
I like your wording below that use "The programmer".
On Sat, 12 Mar 2011, William Gropp wrote:
> On Mar 11, 2011, at 11:43 AM, Bronis R. de Supinski wrote:
>>> 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
>> [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
>> [1, 27]: Fix split infinitives and dangling preposition:
>> to periodically poll for potential communication requests to receive
>> 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
>> [and] MPI_ACCUMULATE (remote update), MPI_GET_ACCUMULATE,
>> (remote read and update), MPI_COMPARE_AND_SWAP (remote atomic swap
>> operations), MPI_RPUT, MPI_RGET, MPI_RACCUMULATE and
>> it is odd that a subset of the operations have parenthetical
>> 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
>> 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
>> made to “accumulate” operations in this chapter, it refers to the
>> following operations: MPI_ACCUMULATE, MPI_GET_ACCUMULATE,
>> MPI_COMPARE_AND_SWAP, MPI_RACCUMULATE and MPI_RGET_ACCUMULATE.")
>> [1, 44-45] Use active voice: correct ordering of memory accesses has
>> be imposed by the user, using synchronization calls; => the user must
>> impose correct ordering of memory accesses through synchronization
> 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).
>> [2, 12] Use active voice: "However, support for asynchronous
>> agents in software (handlers, threads, etc.) might be needed, for
>> RMA functions, in a distributed memory environment." => "However,
>> RMA functions might need support for asynchronous communication
>> agents in
>> software (handlers, threads, etc.) in a distributed memory
>>> 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.
> 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
More information about the mpiwg-rma