So what's the plan here? Is MPICH-3.3 going to return to the expected behavior? William Gropp <[email protected]> writes:
I agree. This is a perverse interpretation. While I understand the optimization, the nonblocking routines should return an active request, not a null request. (The real optimization is probably in not creating the request, rather than freeing it; while requests should be managed in such a way that creation is cheap, its likely that defensive coding will initialize the request, which can be non-trivial. Still, this doesn’t seem worth the surprise to the user.)
Bill
William Gropp Director, Parallel Computing Institute Thomas M. Siebel Chair in Computer Science Chief Scientist, NCSA University of Illinois Urbana-Champaign
On Dec 7, 2015, at 9:29 AM, Jeff Squyres (jsquyres) <[email protected]> wrote:
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 <[email protected]> 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 <[email protected]> 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 [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss
-- Jeff Hammond [email protected] http://jeffhammond.github.io/ _______________________________________________ discuss mailing list [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss
-- Jeff Squyres [email protected] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
_______________________________________________ discuss mailing list [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss
_______________________________________________ discuss mailing list [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss
_______________________________________________ discuss mailing list [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss