<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div dir="ltr">I created <a href="https://trac.mpich.org/projects/mpich/ticket/2319#ticket">https://trac.mpich.org/projects/mpich/ticket/2319#ticket</a>.  I set the milestone to 3.2.3, although I expect someone who actually works on MPICH will change this :-)<br><br>Jeff</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 11, 2015 at 11:08 PM, Jed Brown <span dir="ltr"><<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So what's the plan here?  Is MPICH-3.3 going to return to the expected behavior?<br>
<div class="HOEnZb"><div class="h5"><br>
William Gropp <<a href="mailto:wgropp@illinois.edu">wgropp@illinois.edu</a>> writes:<br>
<br>
> 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.)<br>
><br>
> Bill<br>
><br>
> William Gropp<br>
> Director, Parallel Computing Institute<br>
> Thomas M. Siebel Chair in Computer Science<br>
> Chief Scientist, NCSA<br>
> University of Illinois Urbana-Champaign<br>
><br>
><br>
><br>
><br>
><br>
> On Dec 7, 2015, at 9:29 AM, Jeff Squyres (jsquyres) <<a href="mailto:jsquyres@cisco.com">jsquyres@cisco.com</a>> wrote:<br>
><br>
>> I understand the optimization here, but I think Jed does have a point: it is weird.<br>
>><br>
>> Further, MPI-3.1 5.1.2 p196:38-39 states:<br>
>><br>
>>    "A nonblocking call initiates a collective operation, which must be completed in a separate completion call."<br>
>><br>
>> 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.<br>
>><br>
>> 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).<br>
>><br>
>> In short: yes, this is a micro-optimization.  But:<br>
>><br>
>> a) it kinda falls in the "violates the law of least astonishment" category<br>
>> b) is deallocating a free listed request that expensive?<br>
>> c) if you have to explain this every time, are you really optimizing anything?<br>
>> d) it's a single process case -- it's already damn fast. Do you really need to optimize it further?  :-)<br>
>><br>
>> (To be clear: I don't really care; I just bring up these points to highlight the other side of the story)<br>
>><br>
>><br>
>>> On Dec 7, 2015, at 6:39 AM, Jeff Hammond <<a href="mailto:jeff.science@gmail.com">jeff.science@gmail.com</a>> wrote:<br>
>>><br>
>>> 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.<br>
>>><br>
>>> Why don't you use MPI_Test instead of direct comparison?<br>
>>><br>
>>> Jeff<br>
>>><br>
>>> On Sun, Dec 6, 2015 at 10:04 PM, Jed Brown <<a href="mailto:jed@jedbrown.org">jed@jedbrown.org</a>> wrote:<br>
>>> In MPICH 3.2, MPI_Ibarrier(MPI_COMM_SELF,&r) returns r ==<br>
>>> MPI_REQUEST_NULL.  This is also the case for other communicators of size<br>
>>> 1.  Previous versions of MPICH and also all versions of Open MPI return<br>
>>> a valid request not equal to MPI_REQUEST_NULL.  This bit me because it<br>
>>> was natural to compare to MPI_REQUEST_NULL in a conditional for an<br>
>>> Ibarrier/Issend/Iprobe algorithm.  It can be worked around with a<br>
>>> slightly more complicate conditional, but is this change intentional?<br>
>>><br>
>>>  The call returns a request handle, which must be passed to a<br>
>>>  completion call.<br>
>>>  -- MPI-3 §5.12<br>
>>><br>
>>> This does not say "unless the communicator has size 1".<br>
>>><br>
>>> _______________________________________________<br>
>>> discuss mailing list     <a href="mailto:discuss@mpich.org">discuss@mpich.org</a><br>
>>> To manage subscription options or unsubscribe:<br>
>>> <a href="https://lists.mpich.org/mailman/listinfo/discuss" rel="noreferrer" target="_blank">https://lists.mpich.org/mailman/listinfo/discuss</a><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> Jeff Hammond<br>
>>> <a href="mailto:jeff.science@gmail.com">jeff.science@gmail.com</a><br>
>>> <a href="http://jeffhammond.github.io/" rel="noreferrer" target="_blank">http://jeffhammond.github.io/</a><br>
>>> _______________________________________________<br>
>>> discuss mailing list     <a href="mailto:discuss@mpich.org">discuss@mpich.org</a><br>
>>> To manage subscription options or unsubscribe:<br>
>>> <a href="https://lists.mpich.org/mailman/listinfo/discuss" rel="noreferrer" target="_blank">https://lists.mpich.org/mailman/listinfo/discuss</a><br>
>><br>
>><br>
>> --<br>
>> Jeff Squyres<br>
>> <a href="mailto:jsquyres@cisco.com">jsquyres@cisco.com</a><br>
>> For corporate legal information go to: <a href="http://www.cisco.com/web/about/doing_business/legal/cri/" rel="noreferrer" target="_blank">http://www.cisco.com/web/about/doing_business/legal/cri/</a><br>
>><br>
>> _______________________________________________<br>
>> discuss mailing list     <a href="mailto:discuss@mpich.org">discuss@mpich.org</a><br>
>> To manage subscription options or unsubscribe:<br>
>> <a href="https://lists.mpich.org/mailman/listinfo/discuss" rel="noreferrer" target="_blank">https://lists.mpich.org/mailman/listinfo/discuss</a><br>
><br>
> _______________________________________________<br>
> discuss mailing list     <a href="mailto:discuss@mpich.org">discuss@mpich.org</a><br>
> To manage subscription options or unsubscribe:<br>
> <a href="https://lists.mpich.org/mailman/listinfo/discuss" rel="noreferrer" target="_blank">https://lists.mpich.org/mailman/listinfo/discuss</a><br>
</div></div><br>_______________________________________________<br>
discuss mailing list     <a href="mailto:discuss@mpich.org">discuss@mpich.org</a><br>
To manage subscription options or unsubscribe:<br>
<a href="https://lists.mpich.org/mailman/listinfo/discuss" rel="noreferrer" target="_blank">https://lists.mpich.org/mailman/listinfo/discuss</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Jeff Hammond<br><a href="mailto:jeff.science@gmail.com" target="_blank">jeff.science@gmail.com</a><br><a href="http://jeffhammond.github.io/" target="_blank">http://jeffhammond.github.io/</a></div>
</div>