[mpiwg-rma] FW: [Mpi3-rma] [EXTERNAL] Re: MPI-3 UNIFIED model updates

[Jeff Hammond]

I agree with Keith. Losing SHMEM as a client of MPI-3 is not worth
symmetry or other esoteric properties.

It's entirely reasonable to say the standard leaves no-sync unified as
undefined = implementation-defined. This would not be the first time.

Jeff

Sent from my iPhone

On Aug 27, 2013, at 7:16 AM, Pavan Balaji <balaji at mcs.anl.gov> wrote:

>
> On 08/27/2013 08:56 AM, Underwood, Keith D wrote:
>>> On 08/27/2013 07:15 AM, Underwood, Keith D wrote:
>>>>>> I prefer option #1 -- that a window synchronization (e.g. Win_sync)
>>>>>> can be used to order load/store operations with respect to actions
>>>>>> performed by other processes in the target's window.  If no ordering
>>>>>> is enforced, the MPI standard does not define what is seen by load
>>>>>> operations at the target process.  As a rationale, the local process'
>>>>>> view of the window may not be consistent with the window because of
>>>>>> performance optimizations or the consistency model of the underlying
>>>>>> architecture.  This would allow e.g. SHMEM implementations to still
>>>>>> use MPI-3 RMA, but they would have to rely on a behavior that is
>>>>>> defined by the architecture/implementation, as they currently do.
>>>>
>>>> My statement:  this seems to be what SHMEM does - except they don't
>>>> provide the equivalent of Win_sync.  If we are going to hack on the
>>>> text, I would prefer that we be *very* careful in our wording.
>>>> Specifically, we need to make it very clear that the SHMEM approach is
>>>> *legal*, but the burden is on the user to do potentially
>>>> implementation specific things to make it work right.
>>>
>>> Hmm.  OK.  Just so there's no confusion, by "SHMEM approach", you are
>>> saying that the application can use its own platform-specific memory
>>> consistency calls and avoid using WIN_SYNC, correct?
>>
>> Yes.  WIN_SYNC will do that for them, but they can do everything
>> without calling WIN_SYNC as long as they call the right
>> platform-specific things and the platform-specific approach might be
>> faster/lower overhead.
>
> OK.  I'm not disagreeing with this option, but I just want to point out that this will essentially discard MPI implementations that would implement UNIFIED in software (e.g., by trapping store operations). That's probably not a big deal, but from a pure CS perspective, it's not symmetric.
>
> Thoughts from others?
>
> -- Pavan
>
> --
> Pavan Balaji
> http://www.mcs.anl.gov/~balaji
> _______________________________________________
> mpiwg-rma mailing list
> mpiwg-rma at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma