[mpich-discuss] [OMPI users] Buffered sends are evil?

[Jeff Hammond]

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)
<jsquyres at 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 <balaji at 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) <jsquyres at cisco.com> wrote:
>>>
>>> Yes.  I think the blog post gives 10 excellent reasons why.  :-)
>>>
>>>
>>>> On Apr 3, 2015, at 2:40 AM, Lei Shi <leishi at 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
>>>> users at 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
>>> jsquyres at cisco.com
>>> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
>>>
>>> _______________________________________________
>>> discuss mailing list     discuss at 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     discuss at mpich.org
>> To manage subscription options or unsubscribe:
>> https://lists.mpich.org/mailman/listinfo/discuss
>
>
> --
> Jeff Squyres
> jsquyres at cisco.com
> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
>
> _______________________________________________
> discuss mailing list     discuss at mpich.org
> To manage subscription options or unsubscribe:
> https://lists.mpich.org/mailman/listinfo/discuss



-- 
Jeff Hammond
jeff.science at gmail.com
http://jeffhammond.github.io/
_______________________________________________
discuss mailing list     discuss at mpich.org
To manage subscription options or unsubscribe:
https://lists.mpich.org/mailman/listinfo/discuss