[Mpi3-rma] [EXTERNAL] Re: MPI-3 UNIFIED model clarification

Barrett, Brian W bwbarre at sandia.gov
Sun Aug 4 17:56:00 CDT 2013


On 8/2/13 7:29 PM, "Pavan Balaji" <balaji at mcs.anl.gov<mailto:balaji at mcs.anl.gov>> wrote:

On 08/02/2013 08:27 PM, Underwood, Keith D wrote:
That was specifically *not* the point of unified.  The point of
unified was that "if the platform can support it, the user can get
something better".  Remember all those conversations about
synchronization using hands waving across the machine room?  Unless
you guys want to go get rid of UNIFIED?  There really isn't a point
to unified if you have to call MPI_Win_sync, is there?

Yes, I remember that discussion.  However, what I took away from that
discussion was that the user *could* do something outside of MPI, not
*must*, to ensure correct behavior.

If that was not the intention, then there needs to be a memory model
where that's the case.

I took away from our discussions that very few platforms would be able to support unified today, because of these ordering concerns.

However, there's a couple things to note:

1) there have been platforms where UNIFIED would work (and, arguably, x86_64 still provides the required ordering to make UNIFIED work
2) Just because we hang NICs off the dumbest interface possible (PCIe) today does not mean we will continue to do so.  A NIC sitting off the right parts of the processor could, with the right design, provide UNIFIED even on a processor with aggressive reordering by being properly integrated into the reorder engine.

So, I guess I really don't see a problem with what we have today.  As soon as you require a target side WIN_SYNC, there's no point in using Unified; the user and the implementation can live quite happily with SEPARATE.  And, I believe, make SEPARATE go fast on platforms that only need a memory barrier to ensure target side ordering, rather than a complicated cache protocol.

Brian

--
  Brian W. Barrett
  Scalable System Software Group
  Sandia National Laboratories
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-rma/attachments/20130804/4130194c/attachment-0001.html>


More information about the mpiwg-rma mailing list