<!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.3268" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN 
class=352495606-06052008>Dear Dick,</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN 
class=352495606-06052008></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT><SPAN class=352495606-06052008><FONT 
face=Arial><FONT color=#0000ff><FONT size=2>Thanks. <SPAN 
class=352495606-06052008><FONT face=Arial color=#0000ff size=2>What about 
passing more verbose information to and from an MPI implementation? Say, eager 
threshold value, if it's meaningful? There are many less controversial examples, 
for example, to let the caller know how many processes are placed 
onto the node, etc. Simple assertions won't work in this case.</FONT>
<DIV dir=ltr align=left></SPAN><SPAN class=352495606-06052008><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN><FONT face=Arial color=#0000ff size=2><SPAN 
class=352495606-06052008></SPAN></FONT> </DIV><SPAN 
class=352495606-06052008>Back to assertions. I thought we might consider 
MPI_Initialized_subset(*flag,required,*provided) or something. Setting 
"required" to 0 would return the set of provided assertions in "provided". 
Setting "required" to something else will also set the "flag" to true or false, 
depending on whether there's a match.</SPAN></FONT></FONT></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN 
class=352495606-06052008></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN 
class=352495606-06052008>The special 
MPI_Init_subset(*argc,***argv,required,*provided) would complement 
this.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2></FONT> </DIV>
<DIV dir=ltr align=left></SPAN></FONT><SPAN class=352495606-06052008><FONT 
face=Arial color=#0000ff size=2>Regarding 32 bits, let's count (I'm taking the 
joint list from the subset proposal that includes your earlier 
points):</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=352495606-06052008><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=352495606-06052008><FONT face=Arial 
color=#0000ff size=2>0,1,2,3        - 
MPI_THREAD_SINGLE, FUNNELED, SERIALIZED, MULTIPLE </FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=352495606-06052008><FONT face=Arial 
color=#0000ff size=2>0x00000004 - No dynamic process support</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=352495606-06052008><FONT face=Arial 
color=#0000ff size=2>0x00000008 - No file I/O</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=352495606-06052008><FONT face=Arial 
color=#0000ff size=2>0x00000010 - No one-sided ops</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=352495606-06052008><FONT face=Arial 
color=#0000ff size=2>0x00000020 - No communicator & group 
management</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=352495606-06052008><FONT face=Arial 
color=#0000ff size=2>0x00000040 - No non-blocking 
communication</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=352495606-06052008><FONT face=Arial 
color=#0000ff size=2>0x00000080 - No message 
cancellation</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=352495606-06052008><FONT face=Arial 
color=#0000ff size=2>0x00000100 - P</FONT></SPAN><SPAN 
class=352495606-06052008><FONT face=Arial color=#0000ff size=2><SPAN 
class=352495606-06052008><FONT face=Arial color=#0000ff size=2>ersistent ops on 
both sides</FONT></SPAN></FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=352495606-06052008><FONT face=Arial 
color=#0000ff size=2><SPAN class=352495606-06052008>0x00000200 - No 
h</SPAN>eterogeneity</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=352495606-06052008><FONT face=Arial 
color=#0000ff size=2>0x00000400 - No derived datatypes (especially those with 
holes)</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=352495606-06052008><FONT face=Arial 
color=#0000ff size=2>0x00000800 - No MPI_ANY_SOURCE</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=352495606-06052008><FONT face=Arial 
color=#0000ff size=2>0x00001000 - No message tagging</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=352495606-06052008><FONT face=Arial 
color=#0000ff size=2>0x00002000 - No reduction order</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=352495606-06052008><FONT face=Arial 
color=#0000ff size=2>0x00004000 - No eager buffering</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=352495606-06052008><FONT face=Arial 
color=#0000ff size=2>0x00008000 - No </FONT></SPAN><SPAN 
class=352495606-06052008><FONT face=Arial color=#0000ff size=2>mixed request 
types in wait/test</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=352495606-06052008><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=352495606-06052008><FONT face=Arial 
color=#0000ff size=2>We have 16 bits left. Note that there may be some 
predefined masks for well defined combinations of the above (e.g., MPI-1 = no 
dynamic processes, no file I/O, no threads, etc.).</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=352495606-06052008><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN 
class=352495606-06052008>Best regards.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN 
class=352495606-06052008></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN 
class=352495606-06052008>Alexander</SPAN></FONT></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 
Treumann<BR><B>Sent:</B> Monday, May 05, 2008 11:53 PM<BR><B>To:</B> MPI 
2.2<BR><B>Subject:</B> [Mpi-22] MPI_INIT assertions<BR></FONT><BR></DIV>
<DIV></DIV>
<P>I changed the subject to be meaningful - it had been "Re: [Mpi-22] mpi-22 
Digest, Vol 2, Issue 7"<BR><BR>I do think this proposal is within the scope of 
the MPI 2.2 rules so I am pleased to hear this is being considered.<BR><BR>I am 
100% convinced that a query function should be part of this proposal, probably 
with 2 query flavors. One flavor of the query would respond with the set of 
assertions the application MPI_INIT_xxx call had provided and another would 
respond with the set of assertions the MPI implementation is actually 
exploiting. <BR><BR>One library author may decide he will use if/else logic 
based on how the MPI implementation will behave. The application may assert 
MPI_NO_yyy but if the MPI implementation does not exploit MPI_NO_yyy then the 
library can still use the code that depends on yyy. Another library author may 
depend unconditionally on yyy. On an MPI implementation that does not exploit 
MPI_NO_yyy he may want to issue a warning that assertion MPI_NO_yyy is 
non-portable but let the job run. On one that does exploit MPI_NO_yyy he would 
abort the job. Or, he may decide to simply abort any job that asserts MPI_NO_yyy 
to avoid having the library suddenly quit working when the customer upgrades to 
an MPI implementation that does exploit MPI_NO_yyy.<BR><BR>I think 32 assertions 
is probably more than enough<BR><BR>Even a handful of defined assertions can 
raise testing costs. For simple cases like MPI_NO_ANY_SOURCE it is easy for a 
user to judge whether a piece of code is OK but if we begin to add subtle or 
narrow semantic assertions it gets harder. Some library providers will be 
tempted to say "I cannot proof read and test my code to a degree that will allow 
me to accept 28 specific assertions and forbid 4. I will simply forbid every 
subtle assertion I cannot afford to test." <BR><BR>I predict that for large 
applications developed by teams and for community open source efforts the design 
leads will consider requiring that all parts be written to live within a few 
carefully chosen assertions. The design leads will not want to provide a list of 
26 subtle or narrow assertions and require that everyone respect all 26 in the 
code they contribute. <BR><BR>Many distinct assertions also could become a big 
test cost for MPI implementors and customers who must qualify an MPI 
implementation before trusting their business to it. If there were 64 or more 
assertions, how would a tester decide what combinations of assertions must be 
tested and then create suitable test cases?<BR><BR>Dick<TT><BR></TT><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><TT>mpi-22-bounces@lists.mpi-forum.org wrote on 
05/05/2008 01:28:06 PM:<BR><BR>> Dear Dick,</TT><BR><TT>> 
 </TT><BR><TT>> Thank you. We can actually introduce what you propose, 
possibly with<BR>> a query function to make it still easier to live with, as 
early as <BR>> in MPI 2.2, as a subset precursor. Judging by the discussion 
in <BR>> Chicago, subsets may not need much more than that in the end, 
<BR>> possibly with a little more flags and semantics added in 
MPI-3.</TT><BR><TT>>  </TT><BR><TT>> The reservation against 32- (or 
for that matter, 64-) bit limitation<BR>> is the only one I have at the 
moment. Not being able to attach <BR>> assertions to communicators, etc. may 
be missed by some advanced <BR>> programmers, but here we need to be 
pragmatic: who will ever want to<BR>> go that deep?</TT><BR><TT>> 
 </TT><BR><TT>> Best regards.</TT><BR><TT>>  </TT><BR><TT>> 
Alexander</TT><BR><TT>> <BR>> From: mpi-22-bounces@lists.mpi-forum.org [<A 
href="mailto:mpi-22-">mailto:mpi-22-</A><BR>> bounces@lists.mpi-forum.org] On 
Behalf Of Richard Treumann<BR>> Sent: Monday, May 05, 2008 7:18 PM<BR>> 
To: MPI 2.2<BR>> Subject: Re: [Mpi-22] mpi-22 Digest, Vol 2, Issue 
7<BR></TT><BR><TT>> Hi Alexander <BR>> <BR>> I have no objection to 
citing my "assertions" proposal in the <BR>> subsetting discussions. I do 
want to keep it clear that this <BR>> proposal is intended to be as simple as 
practical to implement, exploit and<BR>> live with.<BR>> <BR>> "Live 
with" applies to 3rd party library authors or anyone else who <BR>> must 
write MPI code but does not know and control the structure of <BR>> the 
entire application. That guy must "live with" the decisions made<BR>> by 
whoever coded the MPI_INIT piece. "Live with" also applies to <BR>> whoever 
must test or certify a specific MPI implementation.<BR>> <BR>> Thanks - 
Dick <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>> [image 
removed] "Supalov, Alexander" <alexander.supalov@intel.com><BR>> 
<BR></TT><BR><TT>> <BR>> "Supalov, Alexander" 
<alexander.supalov@intel.com> <BR>> Sent by: 
mpi-22-bounces@lists.mpi-forum.org </TT><BR><TT>> 04/26/2008 04:03 AM 
</TT><BR><TT>> <BR>> Please respond to<BR>> "MPI 2.2" 
<mpi-22@lists.mpi-forum.org></TT><BR><TT>> <BR>> [image removed] 
</TT><BR><TT>> To</TT><BR><TT>> <BR>> [image removed] <BR>> "MPI 
2.2" <mpi-22@lists.mpi-forum.org></TT><BR><TT>> <BR>> [image 
removed] </TT><BR><TT>> cc</TT><BR><TT>> <BR>> [image removed] 
</TT><BR><TT>> <BR>> [image removed] </TT><BR><TT>> 
Subject</TT><BR><TT>> <BR>> [image removed] <BR>> Re: [Mpi-22] mpi-22 
Digest, Vol 2, Issue 7</TT><BR><TT>> <BR>> [image removed] 
</TT><BR><TT>> <BR>> [image removed] </TT><BR><TT>> <BR>> <BR>> 
Dear Dick,<BR>> <BR>> Thank you. Would you mind if I cite your proposal in 
the subsets <BR>> discussion? Yours looks like a good alternative to the 
thinking of <BR>> some of us that subsets might be very rich and mutable, and 
to <BR>> Jeff's proposal on hints I've already cited there with his 
permission.<BR>> <BR>> Best regards.<BR>> <BR>> Alexander<BR>> 
<BR>> From: mpi-22-bounces@lists.mpi-forum.org [<A 
href="mailto:mpi-22-">mailto:mpi-22-</A><BR>> bounces@lists.mpi-forum.org] On 
Behalf Of Richard Treumann<BR>> Sent: Thursday, April 24, 2008 6:16 
PM<BR>> To: MPI 2.2<BR>> Subject: Re: [Mpi-22] mpi-22 Digest, Vol 2, Issue 
7</TT><BR><TT>> 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>> mpi-22-bounces@lists.mpi-forum.org wrote on 04/24/2008 11:33:42 
AM:<BR>> <BR>> > Hi,<BR>> > <BR>> > Note that this is an 
argument for making the assertions optional: those<BR>> > who don't care 
don't have to use them. Those who care should use them<BR>> > correctly or 
else. As usual.<BR>> > <BR>> > Best regards.<BR>> > <BR>> 
> Alexander <BR>> > <BR>> <BR>> Hi Alexander <BR>> <BR>> 
The assertions are optional in this proposal.  If this is added to <BR>> 
the MPI standard the minimal impacts (day one impacts) are:<BR>> <BR>> 
==<BR>> To application writers (none) - MPI_INIT and MPI_INIT_THREAD still 
<BR>> work. MPI_INIT_THREAD_xxx can be<BR>> passed 0 (zero) as the 
assertions bit vector.<BR>> <BR>> To MPI Implementors (small) - subroutine 
MPI_INIT_THREAD_xxx can be <BR>> a clone of MPI_INIT_THREAD under the covers. 
If the Forum decides <BR>> the query function is for asking what assertions 
are being honored, <BR>> the implementation can just return "none" to every 
query. If there <BR>> is also a query for what assertions have been made then 
there are a <BR>> few more lines of code the implementor must write to 
preserve the <BR>> value so it can be returned(maybe 10 lines)<BR>> 
<BR>> Writers of opaque libraries (small) - call the query function at 
<BR>> library init time and if any assertions are found, issue an error 
<BR>> message and kill the job. This is awkward for a library that wants 
<BR>> to support every MPI whether it has implemented the new query function 
or not.<BR>> ==<BR>> <BR>> As MPI implementations begin to take 
advantage of assertions there <BR>> is more work for the MPI implementor and 
the library author must <BR>> begin to think about whether his customer will 
be upset if the <BR>> library simply outlaws all assertions. <BR>> 
<BR>> The library author will never be wrong if he simply forbids <BR>> 
assertions forever. If they become valuable he will feel the <BR>> pressure 
to work it out. <BR>> <BR>> The MPI implementor will never be wrong if he 
adds the API but <BR>> simply ignores assertions forever. If they become 
valuable he will <BR>> feel the pressure to honor some at least. 
</TT><BR><TT>> 
---------------------------------------------------------------------<BR>> 
Intel GmbH<BR>> Dornacher Strasse 1<BR>> 85622 Feldkirchen/Muenchen 
Germany<BR>> Sitz der Gesellschaft: Feldkirchen bei Muenchen<BR>> 
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer<BR>> 
Registergericht: Muenchen HRB 47456 Ust.-IdNr.<BR>> VAT Registration No.: 
DE129385895<BR>> Citibank Frankfurt (BLZ 502 109 00) 600119052<BR>> 
<BR>> This e-mail and any attachments may contain confidential material 
for<BR>> the sole use of the intended recipient(s). Any review or 
distribution<BR>> by others is strictly prohibited. If you are not the 
intended<BR>> recipient, please contact the sender and delete all 
copies.<BR>> _______________________________________________<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></TT><BR><TT>> 
---------------------------------------------------------------------<BR>> 
Intel GmbH<BR>> Dornacher Strasse 1<BR>> 85622 Feldkirchen/Muenchen 
Germany<BR>> Sitz der Gesellschaft: Feldkirchen bei Muenchen<BR>> 
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer<BR>> 
Registergericht: Muenchen HRB 47456 Ust.-IdNr.<BR>> VAT Registration No.: 
DE129385895<BR>> Citibank Frankfurt (BLZ 502 109 00) 600119052<BR>> 
<BR>> This e-mail and any attachments may contain confidential material 
for<BR>> the sole use of the intended recipient(s). Any review or 
distribution<BR>> by others is strictly prohibited. If you are not the 
intended<BR>> recipient, please contact the sender and delete all 
copies.<BR>> _______________________________________________<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></TT></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>