Newsgroups: comp.parallel.mpi
From: raja@rsn.hp.com (Raja Daoud)
Subject: Re: MPI_RECV
Organization: Hewlett-Packard Co.
Date: 9 Jul 1998 02:04:17 -0500
Message-ID: <6o1q1h$lu6@tbag.rsn.hp.com>

>In my opinion, and as you say, the
>best thing to try is to define a buffer and use buffered communications so
>avoiding the buffer problem.

If you are referring to MPI_Bsend, on most systems it would still run
into the same internal buffering limitations, and most probably hurt
performance.

Typically the buffer given to MPI_Buffer_attach is not directly accessible
to the receiving process (it's not in shared memory or other "special"
memory).  So at best, MPI_Bsend is equivalent to an MPI_Send that happens
not to block.  In the more typical case (the only case for some MPIs),
it adds an extra bcopy from the message buffer to the attached buffer.
As a rule-of-thumb, it is recommended you avoid MPI_Bsend.

The original poster's problem seems to be a fast sender using up the
shared memory pool.  A high-quality MPI would throttle the sender and
not require the application to add another protocol layer.  A high-
quality application wouldn't abuse buffering and trigger the throttling
since that hurts performance.

A plea to application developers: don't use MPI_Bsend or MPI_Ibsend.
If your application is ever used as a benchmark, vendors' engineers will
spend time removing these calls and trying to convince you to integrate
their modifications back into your source.  Let's keep it simple and
avoid this extra work all around.  :-)  Thanks.

--Raja

-=-
Raja Daoud				Hewlett-Packard Co.
raja@rsn.hp.com				http://www.hp.com/go/mpi