[mpich-discuss] MPI_Probe

[Jed Brown]

You might also consider MPI one-sided operations.

On Mon, Jan 9, 2012 at 11:37, Jie Chen <jiechen at mcs.anl.gov> wrote:

> Thank you very much for your kind reply. Let me describe my scenario. In
> my application each process needs data from every other processes and
> performs calculations. So a natural work flow, for process p0, is requests
> data from p1, does calculation; then requests data from p2, does
> calculation; so on and so forth. Even though the data are evenly
> distributed among processes, the work loads for each data are different. So
> other processes don't know when p0 requests data. Thus, a natural design is
> to let every process have 2 threads, while one thread is doing the normal
> calculations, the other is responsible for probing requests and
> sending/receiving data.
>
> What concerns me, is the efficacy of this design. Since probing costs CPU
> cycles, and since after one process sends the data request, and it has to
> wait the other process to receive the request and to send the data, there
> might be a lot overhead introduced in addition to the normal calculations.
> The MPI standard only defines what probing does, but it does not define how
> probing is implemented. So I guess it would be hard to estimate in advance
> how large the overhead is.
>
> On the other hand, knowing the overhead is beneficial, since I am at the
> stage of algorithmic design but not implementation. If I know that probing
> is problematic (which perhaps not), I would try to redo the algorithmic
> design and not allow things like "a process does not know when other
> processes request data from it" happen.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/mpich-discuss/attachments/20120109/a52414f7/attachment.htm>