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

[Jeff Hammond]

I created https://trac.mpich.org/projects/mpich/ticket/2319#ticket.  I set
the milestone to 3.2.3, although I expect someone who actually works on
MPICH will change this :-)

Jeff

On Fri, Dec 11, 2015 at 11:08 PM, Jed Brown <jed at jedbrown.org> wrote:

> So what's the plan here?  Is MPICH-3.3 going to return to the expected
> behavior?
>
> William Gropp <wgropp at illinois.edu> 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) <jsquyres at cisco.com>
> 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 <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
> >
> > _______________________________________________
> > discuss mailing list     discuss at mpich.org
> > To manage subscription options or unsubscribe:
> > https://lists.mpich.org/mailman/listinfo/discuss
>
> _______________________________________________
> 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpich.org/pipermail/discuss/attachments/20151212/f5f9db8b/attachment.html>
-------------- next part --------------
_______________________________________________
discuss mailing list     discuss at mpich.org
To manage subscription options or unsubscribe:
https://lists.mpich.org/mailman/listinfo/discuss