[Mpi3-rma] Updated MPI-3 RMA proposal 1
wgropp at illinois.edu
Mon Jun 21 00:05:05 CDT 2010
I agree with Rajeev. And I think we strayed somewhat from the
The goal for the MPI RMA was to make enlarge the set of applications
that could be efficiently implemented with a one-sided model. The
current model *is* a good one for *some* applications; the complaints
about it are often because it doesn't fit some other application. The
RMA extensions for MPI-3, in my mind, needed to address *some*, not
all, of the important application areas that the current model does
not handle. It is interesting to consider whether a reasonable
functional implementation of, say, UPC, could be implemented with it,
but I do not see the MPI RMA as supplying the universal implementation
layer for other programming models.
Making MPI RMA suitable for implementing all other parallel
programming models will require more than I think we want to do - look
at the short word and aligned move routines in GASNET as an example.
You don't need these functionally, but you may need them for
That's why we asked for *application* use cases - those would drive
the design. We have a few but we haven't focused on them as much as I
think we should. What I wanted in proposal 1 was a set of operations,
each of which (a) was consistent with the others and (b) was clearly
driven by some *application* need (where an application in this case
is *not* implementing another programming model). This very well may
have required some options to deal with things like selecting
different ordering and overlapping update semantics, though that could
be very coarse grained.
Note that in this interpretation, proposal 1 is not a "bare minimum";
rather, it is a consensus collection of consistent extensions that
enlarge the space of applications that can be efficiently coded using
MPI-3 one-sided. It will leave some useful features out and some
programming models should focus on interoperability with MPI rather
than having MPI-3 RMA provide the specific features that they need.
It is fine if there is something important that can't be done with
MPI-3 RMA, as long as there are other important things that can be
done with it.
On Jun 20, 2010, at 6:03 PM, Rajeev Thakur wrote:
> Are you refering to Accumulate_get :-)? Maybe it should be in Proposal
> Maybe we also need a "journal of development" as in MPI-2 :-).
> But, seriously, we need to present a united front at least in proposal
> 1. Otherwise the Forum will have no confidence in us.
>> -----Original Message-----
>> From: mpi3-rma-bounces at lists.mpi-forum.org
>> [mailto:mpi3-rma-bounces at lists.mpi-forum.org] On Behalf Of
>> Pavan Balaji
>> Sent: Sunday, June 20, 2010 5:57 PM
>> To: MPI 3.0 Remote Memory Access working group
>> Subject: Re: [Mpi3-rma] Updated MPI-3 RMA proposal 1
>> On 06/20/2010 05:48 PM, Rajeev Thakur wrote:
>>> Proposal 1: This is what the RMA experts agree is the bare minimum
>>> needed to fix what is considered broken in MPI-2 RMA.
>> I don't agree that whatever is there in proposal 1 is the
>> "bare minimum". Maybe this policy should be reworded as:
>> *all* members of the working group should agree that this is needed.
>> This makes both proposal 1 and proposal 2 contain random
>> pieces of unrelated features, though.
>> -- Pavan
>> Pavan Balaji
>> mpi3-rma mailing list
>> mpi3-rma at lists.mpi-forum.org
> mpi3-rma mailing list
> mpi3-rma at lists.mpi-forum.org
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