<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: [Mpi-22] MPI_INIT
assertions</title></head><body>
<div><br></div>
<div>If we are to allow an extensible mechanism for Assertions, then I
like the idea of a "Hints/Info" like interface where one may
query to find out what the implementation supports. However, an
Assertions version would need to be clearly distinct from Hints to
adequately convey that Assertions *may change the semantic rules*
(which Hints do not).</div>
<div><br></div>
<div>An Extensible Assertions interface would presumably allow for
many optimizations by relaxing semantics that are unneeded by the
application. However, for Assertions the application must be aware
because they can change the outcome of the application. I mentioned
read-ahead as an example. Asserting a read-ahead of a given size would
permit different results for files opened Read+Write on a file system
that provides strong consistency semantics.</div>
<div><br></div>
<div>I believe Extensible Assertions would be utilized by applications
because as application teams currently move from platform to platform
they make themselves aware of environment variable tunables and use
such tunables. I would like to see applications dynamically change
these tunables during a run to accommodate different application
phases efficiently. Allowing such a mechanism to alter semantics gives
freedom for increased performance (albeit at the cost that the
application must be aware of what they are doing, and there is added
complexity for all involved).</div>
<div><br></div>
<div>I would also support Dick's original thought of a small,
pre-defined set of Assertions. This is a small step in the direction
of Extensible Assertions (with smaller opportunity for misuse and
'easier to swallow' adoption), and could be designed with an interface
that would later permit Extensible Assertions. But I would keep the
interface sufficiently distinct from Hints to avoid confusion.</div>
<div><br></div>
<div>Regards,</div>
<div> Terry</div>
<div><br></div>
<div><br></div>
<div>At 11:25 AM -0400 5/15/08, Richard Graham wrote:</div>
<blockquote type="cite" cite><font face="Verdana">We should be careful
about making a change in MPI 2.2, knowing that we will likely turn
around again<br>
in MPI 3.0 and change things again. If we are talking
about changing the interface in 2.2, and<br>
then extending the assertions/hints in 3.0, this seems fine, but
if we may want to change the<br>
interface yet again in 3.0, we should rethink things.<br>
I will add that if we are going to add some sort of "info"
argument to 'MPI_Init()', we should deprecate<br>
MPI_Init() and MPI_Init_thread(), and include the threading
specification in the "info" object.<br>
Finally, before we decide on how to pass hints/assertions (if we do)
to MPI_Init(), we should<br>
define a consistent way across the standard for passing
information between the application and<br>
the library, as this is not the only instance where this is
useful, and a uniform way of doing this<br>
makes things much easier on users.<br>
<br>
Rich<br>
<br>
<br>
On 5/14/08 9:14 AM, "Richard Treumann"
<treumann@us.ibm.com> wrote:</font><br>
<font face="Verdana"></font>
<blockquote><font face="Verdana">MPI_Init time assertions must be few
and each must be valuable or the concept will fall like a house of
cards.<br>
<br>
There is nothing in my proposal for MPI_Init time assertions that<b>
rules out</b> providing other mechanisms in MPI 3 for giving guidance
to the MPI implementation. In MPI 3 we can consider more hints
and we can add the abiility to give stronger direction to MPI or
provide it on a more granular basis -<b> If it makes sense</b>. These
extra mechanisms are far to complex to consider as part of MPI
2.2.<br>
<br>
I would not use the phrase that Dries does when he says
"</font><tt><font size="-1">Assertions are bad</font></tt><font
face="Verdana">" but I agree with the the sentiment behind his
statement. I think there should be a very small number of assertions
defined in the standard and for each there should be a good rationale.
For MPI 2.2 there should be a great rationale because we can
come back in MPI 3 and add more assertions if we miss some important
ones. It is much harder to remove one that turns out to be real
trouble.<br>
<br>
Each assertion the the MPI Standard defines has the potential to break
some piece of code that is valid MPI but that depends on semantic the
assertion says is optional. The author of the routine that calls
MPI_Init has the power to declare assertions and the authors of other
parts of an applicaton must either live within the rules or explicitly
shield against them. </font></blockquote>
<blockquote><font face="Verdana"><br>
For project teams that develop complete applications, the decision to
use an assertion belongs to the team, team leader or architect.
If it is decided that an application will use a specific
assertion it is the team lead who must make sure all developers
understand the decision and write appropriate code. All testing
will be done with the assertion in place.<br>
<br>
For third part libraries, the only option is to either forbid all
assertions or explicitly pick some to allow. If there are 4
potential assertions, it is not very hard to decide for each one -
"Will the library tolerate it?". If there are 50
assertions, library authors will seldom allow them all and will be
more tempted to just say "No assertions allowed" because
making judgements about each of 50 is too difficult.<br>
<br>
For Community developed code where people contribute source but are
not under direct control of an architect or team lead, reviewing each
submission for compliance with one or two assertions may be acceptable
but reviewing for 50 each time somebody contributes new code is
not.<br>
<br>
<br>
<br>
Dick Treumann - MPI Team/TCEM
<br>
IBM Systems & Technology Group<br>
Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601<br>
Tele (845) 433-7846
Fax (845) 433-8363<br>
<br>
<br>
</font><tt><font size="-1">mpi-22-bounces@lists.mpi-forum.org wrote on
05/14/2008 07:21:41 AM:<br>
<br>
> * Terry Jones <trj@llnl.gov> [2008-05-13 15:19:07]:<br>
><br>
> > You can also imagine other possibilities to provide helpful
context. For<br>
> > instance, perhaps the user could provide Assertions that
would help MPI IO<br>
> > with read-ahead prefetching or write-behind, or even
meta-data operations<br>
> > (e.g., later I will be creating one file per MPI task).<br>
><br>
> Things like read-ahead or write-behind clearly shouldn't be
assertions but<br>
> hints. (And, probably 'one file per MPI task' too -- if this is
still going to<br>
> be needed in 2 years)<br>
><br>
> MPI already has hints that can capture some of the things
mentioned<br>
> above.<br>
><br>
> access_style: (read_once, write_once, read_mostly, write_mostly,
sequential,<br>
> reverse_sequential, and random)<br>
> sequential -> this can easily be used
to turn on read-ahead<br>
>
<span
></span> IF THE MPI LIBRARY
decides this is useful<br>
><br>
> Assertions are bad -- they break compatibility -- and should only
be<br>
> tolerated if they provide real benefits and if the same cannot be
obtained<br>
> through existing mechanisms (hints, ...).<br>
><br>
> In the examples mentioned, this is not the case.<br>
><br>
> Dries<br>
><br>
> [attachment "attia6gr.dat" deleted by Richard<br>
> Treumann/Poughkeepsie/IBM]
_______________________________________________<br>
> mpi-22 mailing list<br>
> mpi-22@lists.mpi-forum.org<br>
></font></tt> <a
href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22"><tt><font
size="-1">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22</font
></tt></a><br>
<tt><font size="-1"></font></tt></blockquote>
<blockquote>
<hr size="3" width="95%"></blockquote>
<blockquote><tt><font
size="-1">_______________________________________________<br>
mpi-22 mailing list<br>
mpi-22@lists.mpi-forum.org<br>
</font></tt><a
href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22"><tt><font
size="-1">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22</font
></tt></a><br>
</blockquote>
</blockquote>
<blockquote type="cite" cite><tt><font
size="-1"><br></font></tt></blockquote>
<blockquote type="cite" cite><br>
_______________________________________________<br>
mpi-22 mailing list<br>
mpi-22@lists.mpi-forum.org<br>
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22</blockquote>
<div><br></div>
</body>
</html>