<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.3314" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=325031217-20062008><FONT face=Arial
color=#0000ff size=2>Thanks. If you look into Dick's proposal, you'll find just
a handful of assertions. A 32-bit int is not large enough for hundreds of
assertions anyway.</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>
mpi3-subsetting-bounces@lists.mpi-forum.org
[mailto:mpi3-subsetting-bounces@lists.mpi-forum.org] <B>On Behalf Of </B>Martin
Schulz<BR><B>Sent:</B> Friday, June 20, 2008 7:11 PM<BR><B>To:</B> MPI 3.0
Sub-setting working group<BR><B>Subject:</B> Re: [Mpi3-subsetting] MPI
subsetting: charting the way forward atatelecon next week?<BR></FONT><BR></DIV>
<DIV></DIV>At 09:58 AM 6/20/2008, Supalov, Alexander wrote:<BR>
<BLOCKQUOTE class=cite cite="" type="cite">Content-class:
urn:content-classes:message<BR>Content-Type:
multipart/alternative;<BR><X-TAB> </X-TAB>
boundary="----_=_NextPart_001_01C8D2F6.CE1CA5E4"<BR><BR><FONT
face="Arial, Helvetica" color=#0000ff size=2>Hi,<BR></FONT> <BR><FONT
face="Arial, Helvetica" color=#0000ff size=2>Ignoring an assertion should be
perfectly legal.</FONT></BLOCKQUOTE><BR>I fully agree, ignoring should always be
OK, which ensures<BR>the portability of any application using
assertions.<BR><BR>However, I do see Rich's point - how useful are
assertions<BR>if we have hundreds of them and each just works on a
particular<BR>MPI implementation (or even version)? Also, if these
constants<BR>are really implementation specific, does it make sense to
have<BR>them in the MPI standard? Each vender will want their own set<BR>(and
rightfully so) and the burden is then on the programmer to<BR>know all of the
different options and understand the subtle<BR>differences (and we have to
document them all in the standard).<BR><BR>Perhaps we should just define broad
groups of assertions and <BR>define those in the standard. The user can then
query for all <BR>available assertions in that group for a particular
implementation. <BR>This would have to coupled with an ability to uniquely
identify <BR>certain MPI implementations at runtime. Also, this does
not<BR>solve the problem for the end-user of how to select the
correct<BR>assertion.<BR><BR>Martin<BR><BR><BR>Martin<BR><BR><BR><BR>
<BLOCKQUOTE class=cite cite="" type="cite"><BR><FONT face="Arial, Helvetica"
color=#0000ff size=2>Best regards.<BR></FONT> <BR><FONT
face="Arial, Helvetica" color=#0000ff size=2>Alexander<BR></FONT><BR>
<HR>
<FONT face=Tahoma size=2><B>From:</B>
mpi3-subsetting-bounces@lists.mpi-forum.org [<A
href="mailto:mpi3-subsetting-bounces@lists.mpi-forum.org" eudora="autourl">
mailto:mpi3-subsetting-bounces@lists.mpi-forum.org</A>] <B>On Behalf Of
</B>Richard Graham<BR><B>Sent:</B> Friday, June 20, 2008 6:53 PM<BR><B>To:</B>
MPI 3.0 Sub-setting working group<BR><B>Subject:</B> Re: [Mpi3-subsetting] MPI
subsetting: charting the way forward atatelecon next week?<BR></FONT><BR><FONT
face=Verdana>I think we need to be careful here when it comes to assertions,
and think hard about how<BR> you want to handle these in a
standard. In some of the implementations I am familiar with<BR> a
no-eager-throttle key word would be useless – it is vey implementation
specific. I suppose<BR> this is a big problem with trying to add
implementation specific keywords to a standard.<BR> It is a given that
this will also cause trouble when trying to come up with an ABI,
unless<BR> one has a large set of defined constants, and are willing to
have these be no-ops in<BR> certain
implementations.<BR><BR>Rich<BR><BR><BR>On 6/20/08 9:56 AM, "Richard Treumann"
<treumann@us.ibm.com> wrote:<BR><BR></FONT>
<DL>
<DD>Hi Alexander<BR><BR>
<DD>Comments imbedded below.<BR><BR>
<DD>I have no objections to someone providing a rationale for assertions
related to MPI-IO and MPI_1sided. If the rationale is sound I have no
objection to putting them in the proposal. <BR><BR>
<DD>I feel the proposal should be evaluated by the following
algorithm.<BR><BR>
<DD>If (this concept is one that seems plausible) {<BR>
<DD> for each proposed assertion {<BR>
<DD> if (rationale not solid) <BR>
<DD> discard<BR>
<DD> if (deal breaker downside) <BR>
<DD> discard<BR>
<DD> }<BR>
<DD>if ((concept makes sense) & (set of worthwhile assertions is not
empty))<BR>
<DD> make this part of MPI 2.2<BR><BR>
<DD>I do not see much reason to get every assertion that eventually gains
traction into MPI 2.2. MPI 3.0 is soon enough for any that do not make
the MPI 2.2 cut. I do not want to see the concept fall because some
particular assertion is controversial. <BR><BR>
<DD>I consider <FONT face=Verdana size=5>MPI_NO_EAGER_THROTTLE </FONT><FONT
face=Verdana>to be the single most valuable assertion for MPI 2.2 because it
is needed to allow MPI to scale to the levels we are already seeing.<BR>
<DD><BR><BR>
<DD>Dick Treumann - MPI
Team/TCEM
<BR>
<DD>IBM Systems & Technology Group<BR>
<DD>Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601<BR>
<DD>Tele (845) 433-7846 Fax
(845) 433-8363<BR><BR><BR></FONT>
<DD><FONT size=2>mpi3-subsetting-bounces@lists.mpi-forum.org wrote on
06/20/2008 02:58:41 AM:<BR><BR>
<DD>> Dear Dick,<BR>
<DD>> <BR>
<DD>> A couple of suggestions re your proposal:<BR>
<DD>> <BR>
<DD>> - If ASSERTIONS is put at the end of the MPI_INIT_ASSERTED argument
<BR>
<DD>> list, in C++ one can declare the last argument as having a zero
<BR>
<DD>> default value, and skip it if necessary. This might help with <BR>
<DD>> deprecation of the earlier MPI_INIT_* calls.<BR></FONT><FONT
face=Verdana><BR></FONT>
<DD><FONT size=2>I have no objection. It seems reasonable to let C++ default
the <BR>
<DD>assertions parameter to "none"<BR></FONT><FONT face=Verdana><BR></FONT>
<DD><FONT size=2>> - In non-Cray parts of the world, an MPI_INT followed
by MPI_FLOAT <BR>
<DD>> is likely to be a 4-byte int followed by a 4-byte float. This <BR>
<DD>> sometimes depends on the compiler settings in effect,
too.<BR></FONT><FONT face=Verdana><BR></FONT>
<DD><FONT size=2>My rationale is not specific to any particular
architecture. <BR>
<DD>Some MPI datatypes are made entirely <BR>
<DD>from the same base type. Some are mixtures of types. If libmpi knows
<BR>
<DD>at the moment a datatype is committed that the send side and receive<BR>
<DD>side will always use the same internal representions then it does not
<BR>
<DD>need to keep track of the fact that one instance of
{MPI_INT,MPI_FLOAT}<BR>
<DD>has two distinct parts. The send side can gather and ship 8 bytes <BR>
<DD>and the receive side can scatter the 8 bytes. If one side might use
4<BR>
<DD>byte integers while the other side uses 8 byte integers then at <BR>
<DD>least one side will need to know there is a conversion to be done for
<BR>
<DD>the MPI_INT part. If an MPI job does a spawn or join that links to a<BR>
<DD>different architecture after the datatype has been committed, and<BR>
<DD>the MPI_Type_commit has discarded the details, it is too late to get
<BR>
<DD>them back. On the other hand, if it is known there will never be
a<BR>
<DD>different architecture added to the job, the extra information can
be<BR>
<DD>safely discarded.<BR></FONT><FONT face=Verdana><BR></FONT>
<DD><FONT size=2>> - I don't think MPI_NO_THREAD_CONTENTION is really
necessary. The <BR>
<DD>> original thread level settings, in particular, the use of anything
<BR>
<DD>> but MPI_THREAD_MULTIPLE, seem to capture the semantics that you
proposed.<BR></FONT><FONT face=Verdana><BR></FONT>
<DD><FONT size=2>This one is kind of tricky and I also am not sure what it
would mean. If<BR>
<DD>we find a clear value we can keep it and if not we can remove
it.<BR></FONT><FONT face=Verdana><BR></FONT>
<DD><FONT size=2>> - I can't fully follow the motivation for
MPI_NO_ANY_SOURCE <BR>
<DD>> deprioritization. AFAIK, a rendezvous exchange usually starts with
a<BR>
<DD>> ready-to-send packet that contains the size of the message. In this
<BR>
<DD>> case the receiving side will normally reply with a ready-to-receive
<BR>
<DD>> regardless of the buffer space available, and flag
MPI_ERR_TRUNCATED<BR>
<DD>> on message arrival if necessary. In this case, neither <BR>
<DD>> MPI_ANY_SOURCE not MPI_NO_ANY_SOURCE seem to get into
way.<BR></FONT><FONT face=Verdana><BR></FONT>
<DD><FONT size=2>My point is that MPI_NO_ANY_SOURCE might allow this round
trip <BR>
<DD>protocol to be replaced by a 1/2 rendezvous protocol. If it is known<BR>
<DD>that MPI_ANY_SOURCE will not be used then the receive side can send<BR>
<DD>an "envelop and ready for data" packet to the send side. As long as <BR>
<DD>the send side knows it will receive the "envelop and ready for data"
<BR>
<DD>packet when the receive is posted, it does not need to do the first
1/2<BR>
<DD>of the rendezvous. The message matching can be done at the send
side.<BR></FONT><FONT face=Verdana><BR></FONT>
<DD><FONT size=2>A send for which the receive was preposted has a <BR>
<DD>good chance of finding the "envelop and ready for data" sitting in <BR>
<DD>an early queue and the large send can avoid any rendezvous delay.<BR>
<DD>Data begins to flow immediately vs waiting for a round trip of a <BR>
<DD>full rendezvous. In many cases we cut the delay in half and best <BR>
<DD>case we eliminate rendezvous delay completely. If the receive side <BR>
<DD>is late in posting the receive we still save a packet traversal but<BR>
<DD>do not save any time.<BR></FONT><FONT face=Verdana><BR></FONT>
<DD><FONT size=2>If there may be an MPI_ANY_SOURCE then this does not work
because the<BR>
<DD>receive side that has an MPI_ANY_SOURCE cannot guess which sender to
<BR>
<DD>notify so the sender cannot count on getting a 1/2 rendezvous <BR>
<DD>notification for a message that should match the MPI_ANY_SOURCE <BR>
<DD>receive.<BR></FONT><FONT face=Verdana><BR></FONT>
<DD><FONT size=2>The problem that made me lower the priority is that many
MPIs use an<BR>
<DD>eager protocol for small messages and a rendezvous protocol for
large<BR>
<DD>messages. If the send side and receive side have the same size
buffer<BR>
<DD>then both sides can reach the same conclusion: eager vs 1/2
rendezvous.<BR>
<DD>If both decide on eager, the receive side will not send an<BR>
<DD>"envelop and ready for data" packet and the send side will not look <BR>
<DD>for one. If both sides decide on 1/2 rendezvous then the receive
side<BR>
<DD>will send an "envelop and ready for data" packet and the send side
will<BR>
<DD>look for and consume the notice. If the send side is for an 8 byte
<BR>
<DD>message and the receive uses a "big enough" receive buffer of 64KB <BR>
<DD>then the two sides will probably not be able to reach the same <BR>
<DD>conclusion about the protocol. The receive side will ship off an<BR>
<DD>"envelop and ready for data" packet that the send side will not <BR>
<DD>know what to do with.<BR>
<DD><BR></FONT><FONT face=Verdana><BR></FONT>
<DD><FONT size=2>> <BR>
<DD>> Best regards.<BR>
<DD>> <BR>
<DD>> Alexander<BR>
<DD>> <BR>
<DD>> From: Supalov, Alexander <BR>
<DD>> Sent: Friday, June 20, 2008 8:29 AM<BR>
<DD>> To: 'MPI 3.0 Sub-setting working group'<BR>
<DD>> Subject: RE: [Mpi3-subsetting] MPI subsetting: charting the way
<BR>
<DD>> forward at atelecon next week?<BR></FONT><FONT
face=Verdana><BR></FONT>
<DD><FONT size=2>> Dear Dick,<BR>
<DD>> <BR>
<DD>> Thank you. I remember we exchanged a couple of emails about the
<BR>
<DD>> possible extensions to the set of assertions, like one-sided and
<BR>
<DD>> I/O, and in my recollection, almost reached an agreement that this
<BR>
<DD>> can improve performance and possibly memory footprint, as well as
be<BR>
<DD>> expressed thru assertions. Do you still feel favorable about
this?<BR>
<DD>> <BR>
<DD>> Best regards.<BR>
<DD>> <BR>
<DD>> Alexander<BR>
<DD>> <BR><BR></FONT><FONT face=Verdana><BR><BR></FONT>
<DD><FONT size=2>_______________________________________________<BR>
<DD>mpi3-subsetting mailing list<BR>
<DD>mpi3-subsetting@lists.mpi-forum.org<BR>
<DD><A
href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-subsetting">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-subsetting</A><BR></FONT><BR></DD></DL><FONT
size=2><BR></FONT><BR><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><BR>_______________________________________________<BR>mpi3-subsetting
mailing list<BR>mpi3-subsetting@lists.mpi-forum.org<A
href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-subsetting"
eudora="autourl">
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-subsetting</A>
</BLOCKQUOTE><X-SIGSEP>
<P></X-SIGSEP>_______________________________________________________________________<BR>Martin
Schulz, schulzm@llnl.gov, <A href="http://people.llnl.gov/schulz6"
eudora="autourl">http://people.llnl.gov/schulz6<BR></A>CASC @ Lawrence Livermore
National Laboratory, Livermore, USA </P><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>