<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Re: [Mpi-22] MPI_INIT assertions</TITLE>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<STYLE type=text/css><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></STYLE>
<META content="MSHTML 6.00.2900.3268" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=288470117-15052008><FONT face=Arial
color=#0000ff size=2>Hi,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=288470117-15052008><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=288470117-15052008><FONT face=Arial
color=#0000ff size=2>I bet some setting changes (like eager protocol threshold)
may need to be global, or at least include all processes involved in a loosely
synchronous, i.e., collective manner. Is this a part of the hints proposal?
If not, changes to the settings effective on one side won't be visible on the
other side. Enter chaos.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=288470117-15052008><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=288470117-15052008><FONT face=Arial
color=#0000ff size=2>Best regards.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=288470117-15052008><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=288470117-15052008><FONT face=Arial
color=#0000ff size=2>Alexander</FONT></SPAN></DIV><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> mpi-22-bounces@lists.mpi-forum.org
[mailto:mpi-22-bounces@lists.mpi-forum.org] <B>On Behalf Of </B>Terry
Jones<BR><B>Sent:</B> Thursday, May 15, 2008 6:58 PM<BR><B>To:</B> MPI
2.2<BR><B>Subject:</B> Re: [Mpi-22] MPI_INIT assertions<BR></FONT><BR></DIV>
<DIV></DIV>
<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 cite="" type="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 width="95%" SIZE=3>
</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 cite="" type="cite"><TT><FONT size=-1><BR></FONT></TT></BLOCKQUOTE>
<BLOCKQUOTE cite=""
type="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><pre>---------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
</pre></BODY></HTML>