[Mpi3-rma] MPI-3 UNIFIED model clarification
Underwood, Keith D
keith.d.underwood at intel.com
Fri Aug 2 20:27:41 CDT 2013
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?
> -----Original Message-----
> From: Pavan Balaji [mailto:balaji at mcs.anl.gov]
> Sent: Friday, August 02, 2013 6:10 PM
> To: Underwood, Keith D
> Cc: Jed Brown; mpi3-rma at lists.mpi-forum.org
> Subject: Re: [Mpi3-rma] MPI-3 UNIFIED model clarification
> On 08/02/2013 04:45 PM, Underwood, Keith D wrote:
> >>> At one point, them using their own memory fences was accepted as
> >>> part of it, because it provides " the performance and "safety" of
> >>> threads, localized to a window". Those same people have to use
> >>> memory fences for threads to work right too.
> >> Then what were you trying to say here:
> >>>>> Oh, I think we want it to say that they are identical. I believe
> >>>>> that is the only way to let the user actually use it.
> >> "identical" means located at the same memory address, but the user is
> >> responsible for memory ordering if they don't use MPI_Win_sync?
> > Yes - identical means "landing in the same physical memory and kept
> > coherent". The entire discussion about memory ordering is about cores
> > doing aggressive reordering of instructions across boundaries that are
> > unfriendly to multithreaded coding. The place where we actually have
> > a problem in the spec may be the ordering definition; however, I don't
> > think we have a problem. Delivering in order is still necessary for
> > some use cases and it is not the fault of the API that a core has
> > reordered loads. It is the job of the user to deal with the fact that
> > their core reorders those loads - just like they would have to in
> > multithreaded programming.
> It is OK to say that the user can use platform-specific techniques outside of
> MPI, but we need an MPI mechanism to do that as well. I think we are
> arguing that MPI_Win_sync should be that mechanism. That way, a program
> written for SEPARATE will stay correct for UNIFIED as well.
> -- Pavan
> Pavan Balaji
More information about the mpiwg-rma