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

[Jeff Squyres (jsquyres)]

I understand the optimization here, but I think Jed does have a point: it is weird.

Further, MPI-3.1 5.1.2 p196:38-39 states:

    "A nonblocking call initiates a collective operation, which must be completed in a separate completion call."

Arguably, this does not directly state that you need to return a valid request from any of the NBCs.  But it's a reasonable interpretation to believe that it should.

Further, Jed is right that this might be a micro-optimization (i.e., avoiding the creation or deallocation of a request), but it doesn't help much unless the app also does an associated "if" to test and see if the request==MPI_REQUEST_NULL and therefore doesn't call TEST*/WAIT* (i.e., that would be a further micro-optimization -- which probably isn't negated by the app's "if" because TEST*/WAIT* have to do the same "if" for REQUEST_NULL).

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

(To be clear: I don't really care; I just bring up these points to highlight the other side of the story)


> On Dec 7, 2015, at 6:39 AM, Jeff Hammond <jeff.science at gmail.com> wrote:
> 
> Completed requests are set to MPI_REQUEST_NULL.  Since MPI_Ibarrier (and MPI_Barrier) is a no-op for a communicator of size 1, it is trivially complete and it would seem that MPICH is optimizing away the unnecessary request object here.
> 
> Why don't you use MPI_Test instead of direct comparison?
> 
> Jeff
> 
> On Sun, Dec 6, 2015 at 10:04 PM, Jed Brown <jed at jedbrown.org> wrote:
> In MPICH 3.2, MPI_Ibarrier(MPI_COMM_SELF,&r) returns r ==
> MPI_REQUEST_NULL.  This is also the case for other communicators of size
> 1.  Previous versions of MPICH and also all versions of Open MPI return
> a valid request not equal to MPI_REQUEST_NULL.  This bit me because it
> was natural to compare to MPI_REQUEST_NULL in a conditional for an
> Ibarrier/Issend/Iprobe algorithm.  It can be worked around with a
> slightly more complicate conditional, but is this change intentional?
> 
>   The call returns a request handle, which must be passed to a
>   completion call.
>   -- MPI-3 §5.12
> 
> This does not say "unless the communicator has size 1".
> 
> _______________________________________________
> 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


-- 
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