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) <jsquy...@cisco.com> 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 <bal...@anl.gov> 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) <jsquy...@cisco.com> >>> wrote: >>> >>> Yes. I think the blog post gives 10 excellent reasons why. :-) >>> >>> >>>> On Apr 3, 2015, at 2:40 AM, Lei Shi <lei...@ku.edu> 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-evil >>>> >>>> Is it true or not? Thanks! >>>> >>>> Sincerely Yours, >>>> >>>> Lei Shi >>>> --------- >>>> >>>> _______________________________________________ >>>> users mailing list >>>> us...@open-mpi.org >>>> 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 >>> jsquy...@cisco.com >>> For corporate legal information go to: >>> http://www.cisco.com/web/about/doing_business/legal/cri/ >>> >>> _______________________________________________ >>> discuss mailing list disc...@mpich.org >>> To manage subscription options or unsubscribe: >>> https://lists.mpich.org/mailman/listinfo/discuss >> >> -- >> Pavan Balaji ✉️ >> http://www.mcs.anl.gov/~balaji >> >> _______________________________________________ >> discuss mailing list disc...@mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss > > > -- > Jeff Squyres > jsquy...@cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > discuss mailing list disc...@mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss -- Jeff Hammond jeff.scie...@gmail.com http://jeffhammond.github.io/
