[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