<!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">
<META content="MSHTML 6.00.2900.3268" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=937593115-15052008><FONT face=Arial
color=#0000ff size=2>Re. MPI_Info before MPI_Init: if special MPI initialized or
owned memory is used for implementing MPI_Info, getting it initialized ahead of
the MPI_Init may be tough. If bit flags are appropriate for assertions, I'd say
we should go with that, and possibly fold required threading support level into
them as well, as discussed earlier.</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> Supalov, Alexander <BR><B>Sent:</B>
Thursday, May 15, 2008 5:31 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 dir=ltr align=left><SPAN class=235332915-15052008><FONT face=Arial
color=#0000ff size=2>Hi,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=235332915-15052008><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=235332915-15052008><FONT face=Arial
color=#0000ff size=2>We can pretty well pass data back and forth via
MPI_COMM_WORLD attribute already now. This may be too late for assertions
proposed by Rick, but seems adequate for everything else, provided we can
describe how an implementation should react to the attribute setting action, and
what attributes it should attach to the MPI_COMM_WORLD by default. Same
with windows and files.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=235332915-15052008><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=235332915-15052008><FONT face=Arial
color=#0000ff size=2>Best regards.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=235332915-15052008><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=235332915-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>Richard
Graham<BR><B>Sent:</B> Thursday, May 15, 2008 5:26 PM<BR><B>To:</B> MPI
2.2<BR><B>Subject:</B> Re: [Mpi-22] MPI_INIT assertions<BR></FONT><BR></DIV>
<DIV></DIV><FONT face="Verdana, Helvetica, Arial"><SPAN
style="FONT-SIZE: 12px">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:<BR><BR></SPAN></FONT>
<BLOCKQUOTE><FONT face="Verdana, Helvetica, Arial"><SPAN
style="FONT-SIZE: 12px">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 "</SPAN></FONT><FONT size=2><FONT
face="Monaco, Courier New"><SPAN style="FONT-SIZE: 10px">Assertions are
bad</SPAN></FONT></FONT><FONT face="Verdana, Helvetica, Arial"><SPAN
style="FONT-SIZE: 12px">" 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. <BR><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></SPAN></FONT><FONT size=2><FONT
face="Monaco, Courier New"><SPAN
style="FONT-SIZE: 10px">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>>
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>> <A
href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22</A><BR></SPAN></FONT></FONT><FONT
face="Verdana, Helvetica, Arial"><SPAN style="FONT-SIZE: 12px"><BR>
<HR align=center width="95%" SIZE=3>
</SPAN></FONT><FONT size=2><FONT face="Monaco, Courier New"><SPAN
style="FONT-SIZE: 10px">_______________________________________________<BR>mpi-22
mailing list<BR>mpi-22@lists.mpi-forum.org<BR><A
href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22</A><BR></SPAN></FONT></FONT></BLOCKQUOTE><FONT
size=2><FONT face="Monaco, Courier New"><SPAN
style="FONT-SIZE: 10px"><BR></SPAN></FONT></FONT><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>