[Mpi3-rma] MPI-3 UNIFIED model clarification

Sur, Sayantan sayantan.sur at intel.com
Mon Jul 29 19:16:41 CDT 2013


> On 07/29/2013 05:30 PM, Jed Brown wrote:
> > "Sur, Sayantan" <sayantan.sur at intel.com> writes:
> >> If we require apps working with UNIFIED model to call MPI_Win_sync,
> >> an one-sided PGAS language might be forced to call sync for any
> >> buffer that may have been touched remotely. Thereby potentially
> >> causing some performance degradation.
> >
> > They need a memory fence anyway on most architectures.
> >
> > What is the problem with creating a fast path for MPI_Win_sync with
> > UNIFIED?  Are we crying about 10 cycles (function call/fast path)
> > along with an explicit statement that (architecture-specific) memory
> > fences could be used directly if the caller wants that responsibility?
> 
> If a PGAS application is polling on a strict global variable, I'm not sure it would
> mind that overhead.
> 
> But the part that concerns me is not the overhead, but rather that requiring a
> WIN_SYNC now will force a nonbackward compatible change to the MPI-3
> standard.
> 
> Unlike Sayantan, I don't think UNIFIED is useful for applications.  But I also
> don't think something specified in the standard should be changed in such a
> subtle non-backward-compatible way.  If we really hate UNIFIED so much, it's
> better to deprecate it, rather than change its definition.

:-)

Sorry, but had to chuckle. This is something we voted in a year and a half ago, and we found out that we cannot implement it portably and already hate it so much that we want to deprecate it. Maybe we should wait a little while longer, and then we will want to bring back UNIFIED again.




More information about the mpiwg-rma mailing list