[mpiwg-rma] FW: [Mpi3-rma] [EXTERNAL] Re: MPI-3 UNIFIED model updates
balaji at mcs.anl.gov
Tue Aug 27 13:44:03 CDT 2013
Did you see Jim's email? He raised a good point that even with
OpenSHMEM this is undefined. You need to use a function call to make it
have defined behavior. So is it still true that OpenSHMEM cannot be
implemented on top of MPI?
On 08/27/2013 01:38 PM, Underwood, Keith D wrote:
> Yes, I want it to be defined. I don’t think that version of defined is
> a problem. The definition just has to happen in terms of what is in
> memory and say “an implementation might reorder your loads in fun and
> exciting ways” ;-) This is pretty close to just saying the public and
> private window are the same.
> Undefined in the way MPI phrases it allows a unified where it is
> impossible to use it without the MPI_WIN_SYNC. That isn’t ok.
> *From:*mpiwg-rma [mailto:mpiwg-rma-bounces at lists.mpi-forum.org] *On
> Behalf Of *Jeff Hammond
> *Sent:* Tuesday, August 27, 2013 2:31 PM
> *To:* Pavan Balaji
> *Cc:* MPI Forum
> *Subject:* Re: [mpiwg-rma] FW: [Mpi3-rma] [EXTERNAL] Re: MPI-3 UNIFIED
> model updates
> Keith's definition is not a definition in the sense of MPI semantics
> being "defined". What he is proposing is to be pedantic about the fact
> that the user may want to rely upon implementation-defined behavior to
> realize the best performance or to avoid changing existing SHMEM code.
> The MPI standard isn't defining something if it's not explicitly defined
> in the standard. Therefore, it must be called "undefined". If you or
> Keith want to call this "defined" behavior, then I'm going to insist
> that it be defined in the usual sense, which means the text of the
> standard will enumerate the behavior of MPI in an
> architecture-independent way.
> On Tue, Aug 27, 2013 at 11:19 AM, Pavan Balaji <balaji at mcs.anl.gov
> <mailto:balaji at mcs.anl.gov>> wrote:
> On 08/27/2013 12:57 PM, Jeff Hammond wrote:
> The MPI standard will not define by what mechanism the SHMEM
> implementation will establish the necessary consistency. This is what I
> mean by undefined = implementation-defined. I do not think that Keith
> is proposing to enumerate all processor memory models and the
> appropriate fences required to achieve the affect of win_sync but at
> lower cost. Thus, it is the implementation - or perhaps more
> accurately, the platform on which the implementation resides - that will
> define these semantics.
> Here's what I understood from Keith --
> He wants a statement in the standard that says the application can do
> platform-specific memory consistency to synchronize the public and
> private windows in UNIFIED.
> I do agree that that's a very flimsy statement and doesn't really mean
> much. But I'm calling it a definition, while I think you are saying
> that it's pretty much undefined.
> I like leaving it totally undefined better than the above "definition".
> -- Pavan
> Pavan Balaji
> Jeff Hammond
> jeff.science at gmail.com <mailto:jeff.science at gmail.com>
More information about the mpiwg-rma