[Mpi-22] mpi-22 Digest, Vol 2, Issue 7

[Supalov, Alexander]

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.