[mpich-discuss] How expensive is MPI_Win_create() compared to memcpy()?

[Jed Brown]

On Tue, Dec 27, 2011 at 21:27, Pavan Balaji <balaji at mcs.anl.gov> wrote:

> Hmm... On second thought, it might be possible to make it not synchronize
> by passing an info argument (though it's not implemented yet).  In this
> case, the base address and other information can be queried on-demand when
> the next PUT/GET/ACCUMULATE operation occurs.
>

Or in the next Win_post/Win_start sequence?


> When memory registration is involved, this will be even messier.  So I
> guess it's theoretically possible, though there's no plan to do it at
> present.  Also, from a portability perspective, you can never assume that
> there will not be synchronization (other MPI implementations might not
> respect this info argument).
>

I don't care about the semantics of synchronization (it always occurs
inside a collective interface anyway), it's just a question of performance.
If the operation always involves an MPI_Allgather() then it can't be used
in performance-sensitive places on a large machine (because the cost of a
scalar MPI_Allreduce() is already many times more than "halo exchange").


> In MPI-3, there's an option for dynamically attaching memory to windows.
>  That's probably the best option for you.  We are working on implementing
> it for our next major release (1.5).
>

I'd be happy to test it out in some of our use scenarios.


> The part I don't understand here is what benefit does wrapping an existing
> window object around new memory give you?  Why not create a new window
> object around your new memory?
>

Nothing in terms of semantics, but if it is less expensive to wrap new
memory than to create a new window, then we can do that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/mpich-discuss/attachments/20111227/373f73a1/attachment.htm>