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 -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Quincey Koziol Sent: Thursday, April 24, 2008 1:14 PM To: mpi-22_at_[hidden] Subject: Re: [Mpi-22] mpi-22 Digest, Vol 2, Issue 7 Hi Dick, On Apr 23, 2008, at 11:00 AM, mpi-22-request_at_[hidden] wrote:
----------------------------------------------------------------------
Message: 1 Date: Tue, 22 Apr 2008 13:38:03 -0400 From: Richard Treumann <treumann_at_[hidden]> Subject: [Mpi-22] Another pre-preposal for MPI 2.2 or 3.0 To: "MPI 2.2" <mpi-22_at_[hidden]>, <mpi-forum_at_[hidden]> Message-ID: <OF677858D0.0B6096D2- ON85257433.005C5199-85257433.0060DE25_at_[hidden]> Content-Type: text/plain; charset="us-ascii"
I have a proposal for providing information to the MPI implementation at MPI_INIT time to allow certain optimizations within the run. This is not a "hints" mechanism because it does change the semantic rules for MPI in the job run. A correct "vanilla" MPI application could give different results or fail if faulty information is provided.
I am interested in what the Forum members think about this idea before I try to formalize it.
I will state up front that I am a skeptic about most of the MPI Subset goals I hear described. However, I think this is a form of subsetting I would support. I say "I think" because it is possible we will find serious complexities that would make me back away.. If this looks as straightforward as I expect, perhaps we could look at it for MPI 2.2. The most basic valid implementation of this is a small amount of work for an implementer. (Well within the scope of MPI 2.2 effort / policy)
I'm with you on being skeptical about the subsetting efforts and I'm also concerned about the proposal you have outlined. The reason I'm concerned about both ideas is that they both don't seem to take adequate account of how to handle third-party software libraries that use MPI calls. Even if the third-party library is open source, I don't think most users of those libraries are going to trace through the source code to make certain of what MPI features the library uses. (Plus those features can easily change over time). I suppose it's possible to ask third-party library providers to publish their "conformance" about which semantics can be relaxed, but I think that's going to be quite a burden for them. Quincey Koziol The HDF Group _______________________________________________ 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.