[Mpi3-rma] RMA proposal 1 update

[Torsten Hoefler]

On Tue, May 25, 2010 at 09:53:17AM -0600, Underwood, Keith D wrote:
> > 1:34 - Need to add MPI_Get_accumulate
> 
> And compare and swap...
done, see my previous mail. 

> 1:41 - is there really an advantage to changing the wording there?
> What does that gain us other than a diversionary argument?
The statement is extremely weak "allows implementors to take advantage".
I think it doesn't do harm and points at one of the major theoretical
advantages.

> > 14:16 - Are derived datatypes allowed in MPI_Get_accumulate? If so, we
> > could as well allow a count argument here.
> 
> We generally need to decide what to do with datatypes there.  I
> thought we wanted to (at most liberal) use the ACCUMULATE language:
>
> Each datatype argument must be a predefined datatype or a derived
> datatype, where all basic components are of the same predefined
> datatype. Both datatype arguments must be constructed from the same
> predefined datatype. The operation op applies to elements of that
> predefined type. target_datatype must not specify overlapping entries,
> and the target buffer must fit in the target window.
Well, I believe we discussed that. I changed the wording to "predefined
datatype" for now. We might want to discuss this further (please put it
on the agenda).

> The question is then whether we allow more than one predefined
> datatype.  For any rational semantics with any hope of efficiency, I
> don't see how we can allow more than one element of a predefined
> datatype.  I.e. MPI_Get_accumulate allows two accesses to target the
> same memory location and defines operation interleaving.  I don't
> think the user is going to expect what they get if we allow more than
> one element.  E.g. multiple ops target one location... one of them
> gets applied first for the first item, a second one gets applied first
> for the second, a third one... etc.  
Yes, I can see both sides of the argument though (but tend to a single
element). 

> 16:47-17:1 - I don't like the mnemonics for IDENTICAL and SMALLER.
> Why not the traditional equal and less? 
I have no strong preference -- changed it.

> We are going to need updates to the memory model description for
> Get_accumulate.  Specifically, the return+op has to be performed
> atomically.  That is, you cannot return one value, have another
> accumulate or get_accumulate applied, and then apply your op.  
Agreed, I added a single sentence which should capture it: "The
operation is executed atomically."

Thanks!

The new version is at the wiki.

All the Best,
  Torsten

-- 
 bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ -----
Torsten Hoefler         | Research Associate
Blue Waters Directorate | University of Illinois
1205 W Clark Street     | Urbana, IL, 61801
NCSA Building           | +01 (217) 244-7736