On May 13, 2005, at 11:52 AM, Stephan Mertens wrote:
> Thanks for your explanations, Jeff. I learned a lot.
>
> It would be interesting to learn more about how LAM ensures
> progress from within other function calls. For example,
> do MPI_Isend and MPI_Bsend (and their relatives) push
> other (= different recipients) pending messages as well?
Yes. In general, most MPI communications functions trip the entire p2p
progress engine. But not always. See below.
> And do blocking functions push "more" than non-blocking?
I'm not sure I understand this question...?
> And what about "mega blockers" like MPI_Barrier and other
> collective Operations?
Yes and no. Several of LAM's coll modules are simply layered on top of
point-to-point operations (i.e., MPI_Send, etc.). So they naturally
tend to trigger the entire p2p progression engine.
However, there are at least 2 cases that only do limited progress:
1. The shmem coll module uses native shared memory for collectives --
not p2p functions. Hence, the p2p progress engine is not invoked at
all. This helps shmem collective performance (quite a bit, actually).
2. If you do a vanilla MPI_SEND or MPI_RECV and there is nothing else
pending (i.e., no outstanding requests at all), depending on the rpi
module, it may do a "fast" send or receive, in which case it basically
only progresses that individual send or receive. So it may ignore
other requests in an attempt to decrease the latency of that one
MPI_SEND or MPI_RECV (works quite well for a large class of apps that
only use blocking SEND And RECV). In this case, as implied, the
general p2p progress engine is not tripped at all.
Make sense?
--
{+} Jeff Squyres
{+} jsquyres_at_[hidden]
{+} http://www.lam-mpi.org/
|
