<!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><SPAN class=703555818-06052008><FONT face=Arial
color=#0000ff size=2>Dear Dick,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=703555818-06052008><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=703555818-06052008><FONT face=Arial
color=#0000ff size=2>Thank you, I think I start feeling the difference
between the assertions and the hints. To be completely sure,
where would you put the soft spawning info key: is this an assertion
or a hint? What about other standardized info elements that materially influence
the program execution or may even predetermine its success or failure (like
wdir)? More generally, will the difference between assertions and hints justify
the use of two different mechanisms to pass the data across the MPI boundary?
</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=703555818-06052008><FONT face=Arial
color=#0000ff size=2></FONT></SPAN><SPAN class=703555818-06052008><FONT
face=Arial color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=703555818-06052008><FONT face=Arial color=#0000ff size=2>Here's
I think what we can save by dropping certain MPI features:
</FONT></SPAN></DIV>
<DIV><SPAN class=703555818-06052008>
<UL>
<LI>Dynamic process support: less overhead in the progress engine, easier
global rank handling.
<LI>File I/O: smaller requests, easier wait/test functions.
<LI>One-sided ops: no passive target w/o MPI calls - no extra progress thread.
<LI>Communicator & group management: better memory footprint.
<LI>Non-blocking communication: easier ordering, simplified request handling.
<LI>Heterogeneity: better memory footprint, easier data handling.
<LI>Derived datatypes (especially those with holes): better memory footprint.
<LI>Message tagging: better support for stable dataflow exchanges, smaller
packets. </LI></UL></SPAN></DIV>
<DIV><SPAN class=703555818-06052008><FONT face=Arial color=#0000ff size=2>Best
regards.</FONT></SPAN></DIV>
<DIV><SPAN class=703555818-06052008><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=703555818-06052008><FONT face=Arial color=#0000ff
size=2>Alexander</FONT></SPAN></DIV>
<DIV dir=ltr align=left><BR></DIV>
<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> Tuesday, May 06, 2008 5:21 PM<BR><B>To:</B> MPI
2.2<BR><B>Subject:</B> Re: [Mpi-22] MPI_INIT assertions<BR></FONT><BR></DIV>
<DIV></DIV>
<P>In my view, each assertion we define in the standard should be justified by a
good explanation of how it allows an MPI implementation to be more efficient and
what cost/risk it adds In effect, a cost/benefit analysis. No plausible
rationale - no assertion.<BR><BR>An assertion is a statement about the
application. It is not a request for libmpi to "provide something". In my
proposal, an application that correctly uses some assertion must still be
written to work on an MPI implementation that ignores that assertion. An
application that incorrectly uses some assertion can fail or give wrong answers.
You can picture an assertion as the application author granting libmpi
permission to "NOT provide something" at the MPI implementors
discretion.<BR><BR>In MPI 2 we maintained a careful distinction between hints
and assertions. The MPI implementation is not allowed to give wrong results or
error messages when an application provides an incorrect hint. If an application
could provide a hint that it would not use MPI_CANCEL on a particular
communicator and then called MPI_CANCEL, it would be OK for libmpi to use a
really slow CANCEL protocol but not OK for it to issue a fatal error or ignore
the CANCEL. That means that the freedom to "exploit" a hint in libmpi is very
limited and less care is required of the user in providing hints. Much of what
is being proposed should be treated as hints and could use a different and
extensible mechanism. We can consider extending the MPI_Info usage in MPI-3 to
address information passing that is hint-like. <BR><BR>The MPI standard intends
applications to be platform agnostic and source level portable and we should not
break that. An assertions interface for making statements about the application
will not limit this kind of portability. If there are no MPI_CANCEL calls today,
there are no MPI_CANCEL calls after recompilation for a new platform. If we add
features for platform tuning (like how many tasks per node or eager threshhold)
we could damage portability.<BR><BR>In my first outline, I threw in MPI-IO and
MPI-1SC without any rationale for how they are useful. You added: "No
communicator & group management", "No non-blocking communication", "No
message tagging" and "No derived datatypes". It is not clear to me they are all
useful so a decent rationale would be needed for each. That makes 6 bits that
may be free. <BR><BR>The thread support level parameter in MPI_INIT_THREAD is a
request to the MPI library to provide some level of thread support and I
question how cleanly that maps into the "assertions" model. The assertions model
may only require one bit for "MPI_NO_THREAD_CONTENTION". That frees 3 more of
the bits you suggest are already taken. If we conclude that all 4 thread support
options are really useful it may be best to add the assertions flag to
MPI_INIT_THREAD and keep the thread support controls as they are. Even the
MPI_NO_THREAD_CONTENTION bit frees up then. My original thought was that we
would add a new function that adds a parameter to MPI_INIT_THREAD.<BR><BR>I am
convinced that the number of assertions defined by the MPI standard should be
<B>very limited</B> because each brings some risk and complicates life for
library writers. If we end up with as many as 32 assertions I will apologize for
having offered the idea in the first place and probably advocate a no vote. If
MPI 2.2 provided only MPI_NO_EAGER_THROTTLE, MPI_NO_SEND_CANCEL,
MPI_NO_REQUEST_MIX, MPI_NO_ANY_SOURCE and MPI_NO_REDUCTION_ORDER I would be
content and debate about adding more could wait for MPI 3.0. The assertion that
the application does not try to match persistent send/recv with nonpersistent
recv/send would be a nice 2.2 bonus. That accounts for 6 bits.<BR><BR>The query
function could be something as simple as:<BR><BR>MPI_Query_assertions(int
*stated, int *exploited)<BR><BR>The author of libfred could code in his
Init_fred routine:<BR><BR><TT> int stated_by_app,
exploited_by_lib;</TT><BR><TT> MPI_Query_assertions(
&stated_by_app, &exploited_by_lib)</TT><BR><TT> if
(exploited_by_lib & MPI_NO_SEND_CANCEL) </TT><BR><TT>
fatal_error("Assertion MPI_NO_SEND_CANCEL is not compatable with Fred
Lib")</TT><BR><TT> else if (stated_by_app &
MPI_NO_SEND_CANCEL)</TT><BR><TT> warn("Assertion
MPI_NO_SEND_CANCEL is not compatable with Fred Lib. It is not exploited by your
MPI but your application will not port to an MPI that does exploit
MPI_NO_SEND_CANCEL");</TT><BR><BR>If Fred is really cautious he can code
<BR><TT>If (stated_by_app != 0) fatal_error("Fred does not like
assertions")</TT><BR>and see if anybody asks for some assertion to be tolerated
in the next release of FredLib.<BR><BR>You mention "No eager buffering" which is
different than what I proposed and is not logically an "assertion". MPI
applications should not depend semantically on eager buffering today and the
standard is clear that a MPI implementation which has no eager buffering can
still be 100% compliant. The standard requires that IF an MPI implementation
provides an eager protocol as a performance enhancement, it must also provide a
safety feature which can be expensive. Many (perhaps most) applications can
benefit from an eager protocol but do not need the safety feature because the
application is self regulating. These applications could assert: "I do not
require the safety feature." which would allow them the benefit of eager
protocol without the costs of the safety feature.<BR><BR>I can see a rationale
for some kind of hints related to eager protocol buffer space and threshhold.
There are many other kinds of granular "hint" support that may be useful but all
that should be kept distinct from this proposal (In my opinion).<BR><BR>Regards
- 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><BR><TT>mpi-22-bounces@lists.mpi-forum.org wrote on 05/06/2008
07:26:03 AM:<BR><BR>> Dear Dick,</TT><BR><TT>> </TT><BR><TT>>
Thanks. What about passing more verbose information to and from an <BR>> MPI
implementation? Say, eager threshold value, if it's meaningful? <BR>> There
are many less controversial examples, for example, to let the <BR>> caller
know how many processes are placed onto the node, etc. Simple<BR>> assertions
won't work in this case. </TT><BR><TT>> </TT><BR><TT>> Back to
assertions. I thought we might consider <BR>>
MPI_Initialized_subset(*flag,required,*provided) or something. <BR>> Setting
"required" to 0 would return the set of provided assertions <BR>> in
"provided". Setting "required" to something else will also set <BR>> the
"flag" to true or false, depending on whether there's a match.</TT><BR><TT>>
</TT><BR><TT>> The special
MPI_Init_subset(*argc,***argv,required,*provided) would <BR>> complement
this.</TT><BR><TT>> </TT><BR><TT>> Regarding 32 bits, let's count
(I'm taking the joint list from the <BR>> subset proposal that includes your
earlier points):</TT><BR><TT>> </TT><BR><TT>> 0,1,2,3
- MPI_THREAD_SINGLE, FUNNELED, SERIALIZED, MULTIPLE
</TT><BR><TT>> 0x00000004 - No dynamic process support</TT><BR><TT>>
0x00000008 - No file I/O</TT><BR><TT>> 0x00000010 - No one-sided
ops</TT><BR><TT>> 0x00000020 - No communicator & group
management</TT><BR><TT>> 0x00000040 - No non-blocking
communication</TT><BR><TT>> 0x00000080 - No message
cancellation</TT><BR><TT>> 0x00000100 - Persistent ops on both
sides</TT><BR><TT>> 0x00000200 - No heterogeneity</TT><BR><TT>> 0x00000400
- No derived datatypes (especially those with holes)</TT><BR><TT>> 0x00000800
- No MPI_ANY_SOURCE</TT><BR><TT>> 0x00001000 - No message
tagging</TT><BR><TT>> 0x00002000 - No reduction order</TT><BR><TT>>
0x00004000 - No eager buffering</TT><BR><TT>> 0x00008000 - No mixed request
types in wait/test</TT><BR><TT>> </TT><BR><TT>> We have 16 bits
left. Note that there may be some predefined masks <BR>> for well defined
combinations of the above (e.g., MPI-1 = no dynamic<BR>> processes, no file
I/O, no threads, etc.).</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 11:53 PM<BR>>
To: MPI 2.2<BR>> Subject: [Mpi-22] MPI_INIT assertions<BR></TT><BR><TT>> I
changed the subject to be meaningful - it had been "Re: [Mpi-22] <BR>> 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<BR>> I am pleased to hear this is being
considered.<BR>> <BR>> I am 100% convinced that a query function should be
part of this <BR>> proposal, probably with 2 query flavors. One flavor of the
query <BR>> would respond with the set of assertions the application <BR>>
MPI_INIT_xxx call had provided and another would respond with the <BR>> 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<BR>> the
MPI implementation will behave. The application may assert <BR>> MPI_NO_yyy
but if the MPI implementation does not exploit MPI_NO_yyy<BR>> then the
library can still use the code that depends on yyy. Another<BR>> library
author may depend unconditionally on yyy. On an MPI <BR>> implementation that
does not exploit MPI_NO_yyy he may want to issue<BR>> a warning that
assertion MPI_NO_yyy is non-portable but let the job <BR>> run. On one that
does exploit MPI_NO_yyy he would abort the job. Or,<BR>> he may decide to
simply abort any job that asserts MPI_NO_yyy to <BR>> avoid having the
library suddenly quit working when the customer <BR>> 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 <BR>> simple cases like
MPI_NO_ANY_SOURCE it is easy for a user to judge <BR>> whether a piece of
code is OK but if we begin to add subtle or <BR>> narrow semantic assertions
it gets harder. Some library providers <BR>> will be tempted to say "I cannot
proof read and test my code to a <BR>> degree that will allow me to accept 28
specific assertions and <BR>> forbid 4. I will simply forbid every subtle
assertion I cannot <BR>> afford to test." <BR>> <BR>> I predict that
for large applications developed by teams and for <BR>> community open source
efforts the design leads will consider <BR>> requiring that all parts be
written to live within a few carefully <BR>> chosen assertions. The design
leads will not want to provide a list <BR>> of 26 subtle or narrow assertions
and require that everyone respect <BR>> all 26 in the code they contribute.
<BR>> <BR>> Many distinct assertions also could become a big test cost for
MPI <BR>> implementors and customers who must qualify an MPI implementation
<BR>> before trusting their business to it. If there were 64 or more <BR>>
assertions, how would a tester decide what combinations of <BR>> assertions
must be tested and then create suitable test cases?<BR>> <BR>>
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>>
<BR>> mpi-22-bounces@lists.mpi-forum.org wrote on 05/05/2008 01:28:06
PM:<BR>> <BR>> > Dear Dick,<BR>> > <BR>> > 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.<BR>> > <BR>>
> 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?<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:
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>> <BR>> > 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>>
<BR>> > <BR>> > "Supalov, Alexander"
<alexander.supalov@intel.com> <BR>> > Sent by:
mpi-22-bounces@lists.mpi-forum.org <BR>> > 04/26/2008 04:03 AM <BR>>
> <BR>> > Please respond to<BR>> > "MPI 2.2"
<mpi-22@lists.mpi-forum.org><BR>> > <BR>> > [image removed]
<BR>> > To<BR>> > <BR>> > [image removed] <BR>> > "MPI
2.2" <mpi-22@lists.mpi-forum.org><BR>> > <BR>> > [image
removed] <BR>> > cc<BR>> > <BR>> > [image removed] <BR>>
> <BR>> > [image removed] <BR>> > Subject<BR>> > <BR>>
> [image removed] <BR>> > Re: [Mpi-22] mpi-22 Digest, Vol 2, Issue
7<BR>> > <BR>> > [image removed] <BR>> > <BR>> > [image
removed] <BR>> > <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<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>> >
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 <BR>>
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.
<BR>> >
---------------------------------------------------------------------<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><TT><A
href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22</A></TT><TT><BR>>
>
---------------------------------------------------------------------<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><TT><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>> </TT><TT><A
href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22</A></TT><TT><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>