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_Win win_with_unordered_accumulates; MPI_Request req1, req2; MPI_Accumulate(target=1,win=win_with_unordered_accumulates); MPI_Iwin_flush(target=1,win=win_with_unordered_accumulates,request=req1); MPI_Accumulate(win=win_with_unordered_accumulates); MPI_Iwin_flush(target=1,win=win_with_unordered_accumulates,request=req2); MPI_Waitall(requests={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 Accumulate 2. Thanks, Jeff On Sat, Jun 15, 2013 at 11:24 AM, Barrett, Brian W <[email protected]> wrote:

On 6/15/13 10:47 AM, "Jim Dinan" <[email protected]> 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

-- Brian W. Barrett Scalable System Software Group Sandia National Laboratories

_______________________________________________ mpi3-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma

-- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute [email protected] / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond ALCF docs: http://www.alcf.anl.gov/user-guides