[Mpi3-rma] MPI-3 UNIFIED model clarification
Underwood, Keith D
keith.d.underwood at intel.com
Mon Jul 29 22:58:46 CDT 2013
> On 07/29/2013 10:48 PM, Underwood, Keith D wrote:
> >> On 07/29/2013 10:18 PM, Underwood, Keith D wrote:
> >>> 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.
> >>
> >> Why is reordering not permitted for two unrelated memory loads?
> >> AFAIK, ARM allows that.
> >
> > I'm talking about a load of the data written for the MPI_Recv getting
> > hoisted across MPI_Recv. There is no guarantee of anything in that
> > MPI_Recv actually touching the data being received. There is no
> > guarantee of anything telling the microarchitecture that you are doing
> > an illegal hoist across that receive.
>
> No, we are obviously not talking about data reordering for dependent data.
> In the example I gave, the recv of some other data is essentially a flag for me
> to tell that the origin has flushed some data to the target. Here's the
> example again:
>
> P0:
> Win_lock_all
> Put(a, P1)
> Flush
> MPI_Send(P1, flag)
>
> P1:
> Win_lock_all
> MPI_Recv(P0, flag)
> read a
>
Can you point to the line in there that tells the architecture that the read of A is not touched by MPI_Recv? Let's say the data movement for MPI_Recv is done by a NIC or done by another core. How can the microarchitecture tell the difference?
More information about the mpiwg-rma
mailing list