While we are tilting at windmills, can we also discuss the evils of MPI_Cancel for MPI_Send, everything about MPI_Alltoallw, how MPI_Reduce_scatter is named wrong, and any number of other pet peeves that people have about MPI-3? :-D The MPI standard contains many useful functions and at least a handful of stupid ones. This is remarkably similar to other outputs of the design-by-committee process and can be observed in OpenMP 4.0, C++14, Fortran 2008, and probably every other standardized parallel programming interface in use today. Fortunately, judicious parallel programmers know that less is more and generally focus on using the useful functions effectively, while ignoring the less useful ones, and it's usually not hard to tell the difference. Jeff PS I used MPI_Bsend once and found it superior to the alternative of MPI_Isend+MPI_Request_free for sending fire-and-forget acks, because it forced the implementation to do what I wanted and the performance improved as a result. On Fri, Apr 3, 2015 at 8:34 AM, Jeff Squyres (jsquyres) <[email protected]> wrote:

Fair enough.

My main point should probably be summarized as: MPI_BSEND isn't worth it; there are other, less-confusing, generally-more-optimized alternatives.

...

On Apr 3, 2015, at 11:20 AM, Balaji, Pavan <[email protected]> wrote:

Jeff,

Your blog post seems to confuse what implementations currently do with what Bsend is capable of. If users really wanted it (e.g., a big customer asked for it), every implementation will optimize the crap out of it. The problem is that every few users really care for it, so there's not been a good incentive for implementations to optimize it.

Coming to the technical aspects, bsend doesn't require copying into the user buffer, if you have internal buffer resources. It only guarantees that Bsend will not block if enough user buffer space is available. If you are blocking for progress anyway, I'm not sure the extra copy would matter too much -- it matters some, of course, but likely not to the extent of a full copy cost. Also, the semantics it provides are different -- guaranteed nonblocking nature when there's buffer space available. It's like saying Ssend is not as efficient as send. That's true, but those are different semantics.

Having said that, I do agree with some of the shortcomings you pointed out -- specifically, you can only attach one buffer. I'd add to the list with one more shortcoming: It's not communicator safe. That is, if I attach a buffer, some other library I linked with might chew up my buffer space. So the nonblocking guarantee is kind of bogus at that point.

-- Pavan

...

On Apr 3, 2015, at 5:30 AM, Jeff Squyres (jsquyres) <[email protected]> wrote:

Yes. I think the blog post gives 10 excellent reasons why. :-)

...

On Apr 3, 2015, at 2:40 AM, Lei Shi <[email protected]> wrote:

Hello,

I want to use buffered sends. Read a blog said it is evil, http://blogs.cisco.com/performance/top-10-reasons-why-buffered-sends-are-evi...

Is it true or not? Thanks!

Sincerely Yours,

Lei Shi ---------

_______________________________________________ users mailing list [email protected] Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users Link to this post: http://www.open-mpi.org/community/lists/users/2015/04/26597.php

-- Jeff Squyres [email protected] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

_______________________________________________ discuss mailing list [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

-- Pavan Balaji ✉️ http://www.mcs.anl.gov/~balaji

_______________________________________________ discuss mailing list [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

-- Jeff Squyres [email protected] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

_______________________________________________ discuss mailing list [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

-- Jeff Hammond [email protected] http://jeffhammond.github.io/ _______________________________________________ discuss mailing list [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss