[mpich-discuss] Behavioral change for MPI_Ibarrier(MPI_COMM_SELF, &r) in mpich-3.2

[Jed Brown]

"Jeff Squyres (jsquyres)" <jsquyres at cisco.com> writes:
> In short: yes, this is a micro-optimization.  But:
>
> a) it kinda falls in the "violates the law of least astonishment" category
> b) is deallocating a free listed request that expensive?
> c) if you have to explain this every time, are you really optimizing anything?

Agreed on the above points.  I just think that if returning
MPI_REQUEST_NULL is valid, it needs to be explicitly allowed by the
standard.  My preference is to not allow it because it can make logic
simpler and make memory leaks easier to debug.

> d) it's a single process case -- it's already damn fast. Do you really need to optimize it further?  :-)

This is more delicate because having a fast serial path is important to
avoid code duplication when certain base cases are performance sensitive
(or when running one-process jobs).  This can arise even for tightly
coupled problems at large scale, e.g., in the "coarse" levels of various
fast algorithms.

In this particular circumstance, I think you'd be hard-pressed to find a
use case where the overhead is detectable, and it's arguably less code
complexity to short-circuit the whole operation in the serial case than
to add an extra flag variable to be able to accommodate the possibility
that MPI_REQUEST_NULL is returned.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.mpich.org/pipermail/discuss/attachments/20151207/6ebc69e0/attachment.sig>
-------------- next part --------------
_______________________________________________
discuss mailing list     discuss at mpich.org
To manage subscription options or unsubscribe:
https://lists.mpich.org/mailman/listinfo/discuss