On 07/29/2013 05:30 PM, Jed Brown wrote:

"Sur, Sayantan" <[email protected]> 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. -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji