<!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>The Assertions idea has much to offer. The pre MPI_Init case
seems to be a clear winner, but can we generalize Assertions a little
more without too heavy a cost?</div>
<div><br></div>
<div>I would like to see Assertions extended to permit the application
developer to provide additional context *during* the application run.
Many MPI implementations have a whole laundry list of environment
variables, but long running applications can go through several phases
and a single value of a critically important environment variable may
not make much sense. Perhaps Assertions could be used to change these
type of tunables dynamically during the application.</div>
<div><br></div>
<div>You can also imagine other possibilities to provide helpful
context. For instance, perhaps the user could provide Assertions that
would help MPI IO with read-ahead prefetching or write-behind, or even
meta-data operations (e.g., later I will be creating one file per MPI
task).</div>
<div><br></div>
<div>Regards,</div>
<div> Terry</div>
<div><br></div>
<div><br></div>
<div><br></div>
<div><br></div>
<div>At 5:53 PM -0400 5/5/08, Richard Treumann wrote:</div>
<blockquote type="cite" cite>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,</tt></blockquote>
<blockquote type="cite" cite><tt>> 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 [</tt><a
href="mailto:mpi-22-"><tt>mailto:mpi-22-</tt></a><tt><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 [</tt><a
href="mailto:mpi-22-"><tt>mailto:mpi-22-</tt></a><tt><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</tt></blockquote>
<blockquote type="cite" cite><tt>> 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>
></tt> <a
href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22"><tt
>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22</tt></a><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>
></tt> <a
href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22"><tt
>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22</tt></a></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>