[Mpi3-rma] mpi3-rma post from bradc at cray.com requires approval

[Underwood, Keith D]

> If unordered is an optional assert, no one will optimize for it since
> any implementor gets unordered for free with ordered.

This argument is a red herring.  I see 3 realistic scenarios:

1) In some cases, unordered will either be a free implementation. i.e. you just use the network natively, because the network is unordered.

2) In other cases, unordered won't enable any performance advantage for that system.  i.e. the network is ordered, so nobody will implement unordered no matter what the default is.

3) In still other cases, the network will be broken for the usage model and won't really perform anyway.  I've been talking with Vinod about the forwarding implementation for ARMCI, and that is exactly why he created that implementation:  the network was broken for the usage model.

So, I don't see any scenario in which the default actually matters to the quality of implementation.

Keith
 
> If ordered is the default, let's forget about unordered altogether.
> It will save those who wanted unordered the frustration of finding
> this feature to be worthless down the road.
> 
> MPI RMA implementations have a history of failing to deliver
> performance, so let us not add unordered to the list of features that
> fail to live up to their potential.
> 
> Jeff
> 
> On Sat, Jun 5, 2010 at 9:42 AM, Pavan Balaji <balaji at mcs.anl.gov>
> wrote:
> >
> > On 05/30/2010 11:27 AM, Underwood, Keith D wrote:
> >>
> >> You are right, I should have chosen my words more carefully.  I
> believe we
> >> tossed ordering on MPI_Put when we tossed atomicity.
> >> I don't think we ever got to the discussion of what ordering would
> be for
> >> the atomics.  And, this is where life gets weird.  I'm not positive
> that you
> >> need ordering for atomics, except that they are the MPI_Puts you
> would
> >> actually use when you needed ordering.  So...  I will go back to...
> all UPC
> >> needs is ordering from one source to one target address.  I see
> three
> >> options:
> >>
> >> 1) Just define accumulates/get_accumulates to have the ordering that
> UPC
> >> needs
> >> 2) Default to the UPC ordering and allow an assert to relax that
> >> restriction.  This would be consistent with how the current one-
> sided
> >> operations handle locks
> >> 3) Add some other call to handle ordering, but we wouldn't want some
> call
> >> that you had to call with EVERY put or anything...  After all, all
> we need
> >> is relatively minimal ordering.
> >
> > There's an option (4) similar to (2):
> >
> > 4) Default to unordered, and allow an assert to add ordering.
> >
> > I believe we decided to use either (2) or (4) in the last meeting,
> but
> > didn't finalize on which one.
> >
> > To me, (2) seems more logical since MPI's semantics have typically
> been: use
> > a conservative approach by default (ordered in this case), and allow
> the
> > application to assert that it can use a more relaxed mode as a
> performance
> > optimization (unordered).
> >
> >  -- Pavan
> >
> > --
> > Pavan Balaji
> > http://www.mcs.anl.gov/~balaji
> > _______________________________________________
> > mpi3-rma mailing list
> > mpi3-rma at lists.mpi-forum.org
> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
> >
> 
> 
> 
> --
> Jeff Hammond
> Argonne Leadership Computing Facility
> jhammond at mcs.anl.gov / (630) 252-5381
> http://www.linkedin.com/in/jeffhammond