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/
