[Mpi3-rma] MPI-3 UNIFIED model clarification
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
> 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