[Mpi-22] mpi-22 Digest, Vol 2, Issue 7
Supalov, Alexander
alexander.supalov at [hidden]
Mon May 5 12:28:06 CDT 2008
Dear Dick,
Thank you. We can actually introduce what you propose, possibly with a
query function to make it still easier to live with, as early as in MPI
2.2, as a subset precursor. Judging by the discussion in Chicago,
subsets may not need much more than that in the end, possibly with a
little more flags and semantics added in MPI-3.
The reservation against 32- (or for that matter, 64-) bit limitation is
the only one I have at the moment. Not being able to attach assertions
to communicators, etc. may be missed by some advanced programmers, but
here we need to be pragmatic: who will ever want to go that deep?
Best regards.
Alexander
________________________________
From: mpi-22-bounces_at_[hidden]
[mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Richard
Treumann
Sent: Monday, May 05, 2008 7:18 PM
To: MPI 2.2
Subject: Re: [Mpi-22] mpi-22 Digest, Vol 2, Issue 7
Hi Alexander
I have no objection to citing my "assertions" proposal in the subsetting
discussions. I do want to keep it clear that this proposal is intended
to be as simple as practical to implement, exploit and live with.
"Live with" applies to 3rd party library authors or anyone else who must
write MPI code but does not know and control the structure of the entire
application. That guy must "live with" the decisions made by whoever
coded the MPI_INIT piece. "Live with" also applies to whoever must test
or certify a specific MPI implementation.
Thanks - Dick
Dick Treumann - MPI Team/TCEM
IBM Systems & Technology Group
Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601
Tele (845) 433-7846 Fax (845) 433-8363
"Supalov, Alexander" <alexander.supalov_at_[hidden]>
"Supalov, Alexander"
<alexander.supalov_at_[hidden]>
Sent by:
mpi-22-bounces_at_[hidden]
04/26/2008 04:03 AM
Please respond to
"MPI 2.2" <mpi-22_at_[hidden]>
To
"MPI 2.2" <mpi-22_at_[hidden]>
cc
Subject
Re: [Mpi-22] mpi-22 Digest, Vol 2, Issue 7
Dear Dick,
Thank you. Would you mind if I cite your proposal in the subsets
discussion? Yours looks like a good alternative to the thinking of some
of us that subsets might be very rich and mutable, and to Jeff's
proposal on hints I've already cited there with his permission.
Best regards.
Alexander
________________________________
From: mpi-22-bounces_at_[hidden] [
mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Richard Treumann
Sent: Thursday, April 24, 2008 6:16 PM
To: MPI 2.2
Subject: Re: [Mpi-22] mpi-22 Digest, Vol 2, Issue 7
Dick Treumann - MPI Team/TCEM
IBM Systems & Technology Group
Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601
Tele (845) 433-7846 Fax (845) 433-8363
mpi-22-bounces_at_[hidden] wrote on 04/24/2008 11:33:42 AM:
> Hi,
>
> Note that this is an argument for making the assertions optional:
those
> who don't care don't have to use them. Those who care should use them
> correctly or else. As usual.
>
> Best regards.
>
> Alexander
>
Hi Alexander
The assertions are optional in this proposal. If this is added to the
MPI standard the minimal impacts (day one impacts) are:
==
To application writers (none) - MPI_INIT and MPI_INIT_THREAD still work.
MPI_INIT_THREAD_xxx can be
passed 0 (zero) as the assertions bit vector.
To MPI Implementors (small) - subroutine MPI_INIT_THREAD_xxx can be a
clone of MPI_INIT_THREAD under the covers. If the Forum decides the
query function is for asking what assertions are being honored, the
implementation can just return "none" to every query. If there is also a
query for what assertions have been made then there are a few more lines
of code the implementor must write to preserve the value so it can be
returned(maybe 10 lines)
Writers of opaque libraries (small) - call the query function at library
init time and if any assertions are found, issue an error message and
kill the job. This is awkward for a library that wants to support every
MPI whether it has implemented the new query function or not.
==
As MPI implementations begin to take advantage of assertions there is
more work for the MPI implementor and the library author must begin to
think about whether his customer will be upset if the library simply
outlaws all assertions.
The library author will never be wrong if he simply forbids assertions
forever. If they become valuable he will feel the pressure to work it
out.
The MPI implementor will never be wrong if he adds the API but simply
ignores assertions forever. If they become valuable he will feel the
pressure to honor some at least.
---------------------------------------------------------------------
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.
_______________________________________________
mpi-22 mailing list
mpi-22_at_[hidden]
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22
---------------------------------------------------------------------
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.
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi-22/attachments/20080505/9ca13d72/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: application/octet-stream
Size: 230 bytes
Desc: not available
URL: <http://lists.mpi-forum.org/pipermail/mpi-22/attachments/20080505/9ca13d72/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: application/octet-stream
Size: 45 bytes
Desc: not available
URL: <http://lists.mpi-forum.org/pipermail/mpi-22/attachments/20080505/9ca13d72/attachment-0001.obj>
More information about the Mpi-22
mailing list