[Mpi3-rma] MPI-3 UNIFIED model clarification
Underwood, Keith D
keith.d.underwood at intel.com
Mon Jul 29 22:18:54 CDT 2013
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
More information about the mpiwg-rma
mailing list