[Mpi3-rma] MPI-3 UNIFIED model clarification

[Underwood, Keith D]

So, to clarify, we think that the architecture is going to hoist a load across the MPI_Recv?  And, if an architecture has a risk of that, we think that a memory barrier is a high overhead operation to add to an MPI_Recv?  

Realistically speaking, on a coherent architecture, there are two MPI_Recv operations:

1) The shared memory version - aka the one that requires a memory barrier anyway
2) The one using PCIExpress.  The ordering model on PCIExpress (if used right) in combination with a correct Flush on P0 is going to make sure the data for the receive is delivered after the data for the MPI_Recv.  And, um, technically, if loads can be hoisted across the MPI_Recv, then the MPI_Recv semantics are incorrect and you have to have a memory barrier in MPI_Recv.

I am pretty sure we are chasing a non-issue.

Keith

> -----Original Message-----
> From: mpi3-rma-bounces at lists.mpi-forum.org [mailto:mpi3-rma-
> bounces at lists.mpi-forum.org] On Behalf Of Pavan Balaji
> Sent: Monday, July 29, 2013 8:58 PM
> To: Sur, Sayantan
> Cc: mpi3-rma at lists.mpi-forum.org
> Subject: Re: [Mpi3-rma] MPI-3 UNIFIED model clarification
> 
> 
> On 07/29/2013 07:16 PM, Sur, Sayantan wrote:
> > Sorry, but had to chuckle. This is something we voted in a year and a
> > half ago, and we found out that we cannot implement it portably and
> > already hate it so much that we want to deprecate it. Maybe we should
> > wait a little while longer, and then we will want to bring back
> > UNIFIED again.
> 
> Well, not quite.  If you see the first email in this chain, I mentioned that there
> was a misunderstanding in the WG.  Some people thought that UNIFIED
> meant what the current standard states, and some people thought that it
> meant what I'm suggesting for KIND_OF_UNIFIED.  So, in some sense, we
> voted on something not all of us wanted.
> 
> Also, just so someone doesn't use my statement out-of-context, I said that
> we can deprecate UNIFIED, assuming that there is another model like
> KIND_OF_UNIFIED.
> 
> Finally, I'm not in favor of deprecating UNIFIED.  I just picked that as the
> preferred option compared to changing its semantics.
> 
>   -- 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