[Mpi3-rma] MPI-3 UNIFIED model clarification

Pavan Balaji balaji at mcs.anl.gov
Sat Aug 3 11:44:58 CDT 2013


While that statement is true in general, some of us thought that those 
"some places" included all cache-coherent architectures, and not just 
x86-like architectures.  Clearly that was not what *all* of the WG thought.

Basically, the situation right now is that other cache coherent 
architectures that require a memory barrier on the target side cannot 
support UNIFIED at all (at least, not without considerable overhead). 
This means that other use cases of UNIFIED, such as concurrently 
accessing nonoverlapping portions of memory through load/store and 
PUT/GET, are not available to users of such architectures either (even 
though the hardware is perfectly capable of providing this ability).

In short --

SEPARATE is too general.  It doesn't take advantage of some hardware 
features provided by cache-coherent hardware.

UNIFIED is too specific.  It is too hard for non-x86 architectures to 
provide.

  -- Pavan

On 08/02/2013 09:56 PM, Underwood, Keith D wrote:
> The point of UNIFIED was that we add a more useful model that worked in *some* places.
>
>> -----Original Message-----
>> From: Pavan Balaji [mailto:balaji at mcs.anl.gov]
>> Sent: Friday, August 02, 2013 7:30 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 08:27 PM, Underwood, Keith D wrote:
>>> 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?
>>
>> Yes, I remember that discussion.  However, what I took away from that
>> discussion was that the user *could* do something outside of MPI, not
>> *must*, to ensure correct behavior.
>>
>> If that was not the intention, then there needs to be a memory model where
>> that's the case.
>>
>>    -- Pavan
>>
>> --
>> Pavan Balaji
>> http://www.mcs.anl.gov/~balaji

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



More information about the mpiwg-rma mailing list