[Mpi3-rma] [EXTERNAL] Re: request-based ops
jhammond at alcf.anl.gov
Sat Jun 15 12:42:18 CDT 2013
Related to this, I was wondering about the semantics of IWIN_FLUSH
when ordering was disabled for a window (i.e. accumulate_ordering="").
If I do the following, can I make any assumptions about the ordering
of the two accumulates?
MPI_Request req1, req2;
The Waitall is not required to act on the requests in order, right?
Thus is req2 is completed first, then it flushes both Accumulates
simultaneously, hence does not ordering them. The completion of req1
is then trivial and have no effect on ordering Accumulate 1 before
On Sat, Jun 15, 2013 at 11:24 AM, Barrett, Brian W <bwbarre at sandia.gov> wrote:
> On 6/15/13 10:47 AM, "Jim Dinan" <james.dinan at gmail.com> wrote:
> Can you elaborate on the source of performance loss from operations between
> Iflush and its completion?
> With the current semantics of flush, a valid implementation is a counter of
> number of operations started, another of operations completed, wait until
> they're equal. On an unordered channel (and acks are usually on an
> unordered channel), this mode won't work and you either have to have
> multiple counters or start tracking events in some per-event way, neither of
> which are going to be as performant.
> Brian W. Barrett
> Scalable System Software Group
> Sandia National Laboratories
> mpi3-rma mailing list
> mpi3-rma at lists.mpi-forum.org
Argonne Leadership Computing Facility
University of Chicago Computation Institute
jhammond at alcf.anl.gov / (630) 252-5381
ALCF docs: http://www.alcf.anl.gov/user-guides
More information about the mpiwg-rma