MPI Forum Meetings logo

MPI Forum: mpi-22 Mailing List Archives

all MPI Forum: mpi-22 mailing list

Subject: Re: [Mpi-22] MPI_INIT assertions
From: Richard Treumann (treumann_at_[hidden])
Date: 2008-05-16 08:18:43


Thank you Ashley -

This is exactly the distinction between assertions and hints and the
reason this narrow proposal advocates assertions and does not advocate
hints.

An MPI_NO_SEND_CANCEL hint still requires the MPI implementation to invest
whatever it takes, across the entire application life to do MPI_CANCEL
correctly.

An MPI_NO_SEND_CANCEL assertion allows the MPI implementation to forgo
those costs and just refuse to try to MPI_CANCEL if the application has an
MPI_CANCEL call.

The assertion does relax a semantic guarentee (I say relax rather than
change because "change" has broader implications but an assertion does
change semantics in a narrow and well defined way). An MPI Implementation
that is prepared to do MPI_CANCEL correctly has a different semantic than
one that will issue an error message if MPI_CANCEL is called.

As a footnote -
MPI 2 defined some hints and MPI 3 may define more hints. That is OK. There
are cases where a hint will allow an MPI implementation to give better
performance without changing its semantic. In a situation where a hint is
enough, the MPI standard should avoid defining an assertion.

           Dick

Dick Treumann - MPI Team/TCEM
IBM Systems & Technology Group
Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601
Tele (845) 433-7846 Fax (845) 433-8363

mpi-22-bounces_at_[hidden] wrote on 05/15/2008 05:59:51 PM:

<snip>
>
> To me I see little benefit in offering MPI_NO_SEND_CANCEL as a hint, all
> that does is say to the library that a cancel is unlikely to happen and
> we all know that anyway. As a cancel is still possible I see no
> opportunity for optimisation of any kind making itself possible, all the
> extra space in headers and longer code paths would still be needed
> anyway.
>
> As an assertion it would offer some scope for library writers to make
> simplifications leading to better performance, as a hint I can't see how
> it would change anything.
>
> Ashley,
>
> _______________________________________________
> mpi-22 mailing list
> mpi-22_at_[hidden]
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22