[Mpi3-rma] MPI-3 UNIFIED model clarification

[Pavan Balaji]

On 07/29/2013 01:58 PM, Jeff Hammond wrote:
> I vehemently object to the definition of a new memory model that only
> works for x86 (actually a subset thereof since Intel SCC is x86 but
> not even cache-coherent), which is older than I am.  If we're going to
> make CPU-specific memory models for RMA, let's be fair and thorough
> and define ones that work for PPC, DEC Alpha, and any other CPU memory
> models that exist now or may in the future.
>
> WIN_SYNC is the right way to do this and requires no changes to the
> standard and affects a very small number of users.  How many people
> are writing MPI-3 RMA code that aren't on this list?

My position is that as long as there is a memory model that is usable by 
non-x86 architectures, that's sufficient.  If we say that, that's 
UNIFIED, I'm happy with that.  If we say that, that's not UNIFIED, but 
here's another memory model that does that, that'll work too.

However, note that the point of these memory models is to allow more 
capable hardware to give more guarantees to the user.  So, if some 
hardware is capable of doing more, I don't see any harm in exposing such 
a model to users.

> Note also that I don't even think UBER_SUPER_UNIFIED is practical.
> How does x86's memory model solve the problem of a multi-rail NIC
> where the Send-Recv happens on rail 0 and the Put+Flush happens on the
> other?  Are MPI implementers going to be required to serialize all
> communication through the NIC in order to support this model?

I don't think this is a problem for multi-rail NICs.  The flush already 
has to guarantee that the data is visible on the remote public memory, 
so it'll need to do the required synchronization.

  -- Pavan

-- 
Pavan Balaji
http://www.mcs.anl.gov/~balaji