>
> I agree with Bill that performance portability is an issue. That is, the
> MPI standard itself doesn't really provide any guarantees here about what is
> fastest. Perhaps polling this mailing list will be helpful, but if you are
> looking for "the fastest" solution regardless of which MPI imp
David Zhang wrote:
Blocking send/recv, as the name suggest, stop processing
your master and slave code until the data is received on the slave side.
Just to clarify...
If you use point-to-point send and receive calls, you can make the
block/nonblock decision independently on the send and rece
pi.org] On Behalf
Of Toon Knapen
Sent: Monday, January 31, 2011 5:05 AM
To: Open MPI Users
Subject: Re: [OMPI users] maximising bandwidth
So when you say you want your master to send "as fast as possible", I suppose
you meant get back to running your code as soon as possible. In that
>
>
> So when you say you want your master to send "as fast as possible", I
> suppose you meant get back to running your code as soon as possible. In
> that case you would want nonblocking. However when you say you want the
> slaves to receive data faster, it seems you're implying the actual data
Blocking send/recv, as the name suggest, stop processing your master and
slave code until the data is received on the slave side.
Nonblocking send/recv wouldn't stop, instead you must check the status on
the slave side to see if data has been sent. Nonblocking is faster on the
master side because
Hi all,
If I have a master-process that needs to send a chunk of (different)
data to each of my N slave processes as fast as possible, would I
receive the chunk in each of the slaves faster if the master would
launch N threads each doing a blocking send or would it be better to
launch N nonbl
