February 2009 - Mpi-22 - mailman3.cels.anl.gov

Re: [Mpi-22] #117: Define a new MPI_Count Datatype
by unknown＠example.com 12 Feb '09

12 Feb '09

Possibly. I guess we could add the typedef vs #define argument into an advice to implementors. I personally have reasons to believe that the #define way could simplify adoption of this new useful feature in the foreseeable future. The unsigned Pandora box better stays closed. Was just a fancy thought of mine. Let's go with the default signed long for now. I'll probably add a comment to this end during review. Thanks for putting together this comprehensive proposal! -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Narasimhan, Kannan Sent: Wednesday, February 11, 2009 8:09 PM To: MPI 2.2 Subject: Re: [Mpi-22] #117: Define a new MPI_Count Datatype Alexander, Isn't the representation of MPI_Count (#define vs typedef) a choice best left to each MPI implementation? At the standard level, we just mention that it is equivalent to an int in MPI 2.2. I pretty much modelled this after MPI_Offset and MPI_Aint. There has been no discussion so far MPI_Count being on long vs unsigned long in MPI 3.0. Thanx! Kannan -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Supalov, Alexander Sent: Wednesday, February 11, 2009 11:00 AM To: MPI 2.2 Subject: Re: [Mpi-22] #117: Define a new MPI_Count Datatype Yes. The #define and typedef ways can complement each other. The #define way will actually not change anything once the preprocessor is run - ints will literally be ints, etc. This would be the mildest way of introducing MPI_Count into the code. The typedef will make the code look different, at least syntactically. If it's set to int, it will be almost, but not quite like #define. It it's set to long,it will be what we want to have for 64-bit ints (provided we want signed counts, that is). By the way, has this signed vs unsigned been discussed in this context? -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Narasimhan, Kannan Sent: Wednesday, February 11, 2009 4:58 PM To: MPI 2.2 Subject: Re: [Mpi-22] #117: Define a new MPI_Count Datatype The current proposal has a typedef instead of #define. Are there any specific reasons for preferring the pre-processor macro approach? Thanx! Kannan -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Supalov, Alexander Sent: Wednesday, February 11, 2009 6:44 AM To: MPI 2.2 Subject: Re: [Mpi-22] #117: Define a new MPI_Count Datatype Hi, Thanks. I added an offline comment regarding the #define trick for MPI-2.2. Has this been addressed? Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Narasimhan, Kannan Sent: Wednesday, February 11, 2009 12:54 AM To: MPI 2.2 Subject: [Mpi-22] #117: Define a new MPI_Count Datatype I've updated Ticket #117 ( Define a new MPI_Count Datatype ) to address the issues raised at the MPI Forum Meeting. Is there any other concern that is not addressed in this ticket? Thanx! Kannan _______________________________________________ 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. _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 _______________________________________________ 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. _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 _______________________________________________ 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.

1 0

Preparing for the next MPI Forum meeting
by unknown＠example.com 11 Feb '09

11 Feb '09

I've moved all pending tickets for MPI 2.2 to Milestone "2009/4/6 Chicago". Over the next few weeks, please: 1) Consider carefully the proposals that have had their first reading or vote. We will vote on these. 2) For tickets requiring reviews or rework, these *must* be in state "reviewed" *before* the next Forum meeting. Any item that is not ready for a first reading at the *beginning* of the next meeting will not be considered for MPI 2.2 (we're out of time). They need to have a single, readable proposal. If you need guidance or a straw vote, please conduct that by email in advance of the meeting. 3) Make sure that any ticket that should be considered has the "2009/4/6 Chicago" milestone - there are two with "Future", numbers 48 and 50. There are 41 items on which we will vote. Please come prepared to vote on these items. If you feel strongly about an item (particularly negatively), please use the comment feature on the wiki to make your case. That will help streamline the discussions at the Forum meeting. Bill William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign

1 0

Re: [Mpi-22] #117: Define a new MPI_Count Datatype
by unknown＠example.com 11 Feb '09

11 Feb '09

Alexander, Isn't the representation of MPI_Count (#define vs typedef) a choice best left to each MPI implementation? At the standard level, we just mention that it is equivalent to an int in MPI 2.2. I pretty much modelled this after MPI_Offset and MPI_Aint. There has been no discussion so far MPI_Count being on long vs unsigned long in MPI 3.0. Thanx! Kannan -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Supalov, Alexander Sent: Wednesday, February 11, 2009 11:00 AM To: MPI 2.2 Subject: Re: [Mpi-22] #117: Define a new MPI_Count Datatype Yes. The #define and typedef ways can complement each other. The #define way will actually not change anything once the preprocessor is run - ints will literally be ints, etc. This would be the mildest way of introducing MPI_Count into the code. The typedef will make the code look different, at least syntactically. If it's set to int, it will be almost, but not quite like #define. It it's set to long,it will be what we want to have for 64-bit ints (provided we want signed counts, that is). By the way, has this signed vs unsigned been discussed in this context? -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Narasimhan, Kannan Sent: Wednesday, February 11, 2009 4:58 PM To: MPI 2.2 Subject: Re: [Mpi-22] #117: Define a new MPI_Count Datatype The current proposal has a typedef instead of #define. Are there any specific reasons for preferring the pre-processor macro approach? Thanx! Kannan -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Supalov, Alexander Sent: Wednesday, February 11, 2009 6:44 AM To: MPI 2.2 Subject: Re: [Mpi-22] #117: Define a new MPI_Count Datatype Hi, Thanks. I added an offline comment regarding the #define trick for MPI-2.2. Has this been addressed? Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Narasimhan, Kannan Sent: Wednesday, February 11, 2009 12:54 AM To: MPI 2.2 Subject: [Mpi-22] #117: Define a new MPI_Count Datatype I've updated Ticket #117 ( Define a new MPI_Count Datatype ) to address the issues raised at the MPI Forum Meeting. Is there any other concern that is not addressed in this ticket? Thanx! Kannan _______________________________________________ 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. _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 _______________________________________________ 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. _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22

1 0

Re: [Mpi-22] #117: Define a new MPI_Count Datatype
by unknown＠example.com 11 Feb '09

11 Feb '09

Yes. The #define and typedef ways can complement each other. The #define way will actually not change anything once the preprocessor is run - ints will literally be ints, etc. This would be the mildest way of introducing MPI_Count into the code. The typedef will make the code look different, at least syntactically. If it's set to int, it will be almost, but not quite like #define. It it's set to long,it will be what we want to have for 64-bit ints (provided we want signed counts, that is). By the way, has this signed vs unsigned been discussed in this context? -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Narasimhan, Kannan Sent: Wednesday, February 11, 2009 4:58 PM To: MPI 2.2 Subject: Re: [Mpi-22] #117: Define a new MPI_Count Datatype The current proposal has a typedef instead of #define. Are there any specific reasons for preferring the pre-processor macro approach? Thanx! Kannan -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Supalov, Alexander Sent: Wednesday, February 11, 2009 6:44 AM To: MPI 2.2 Subject: Re: [Mpi-22] #117: Define a new MPI_Count Datatype Hi, Thanks. I added an offline comment regarding the #define trick for MPI-2.2. Has this been addressed? Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Narasimhan, Kannan Sent: Wednesday, February 11, 2009 12:54 AM To: MPI 2.2 Subject: [Mpi-22] #117: Define a new MPI_Count Datatype I've updated Ticket #117 ( Define a new MPI_Count Datatype ) to address the issues raised at the MPI Forum Meeting. Is there any other concern that is not addressed in this ticket? Thanx! Kannan _______________________________________________ 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. _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 _______________________________________________ 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.

1 0

Re: [Mpi-22] #117: Define a new MPI_Count Datatype
by unknown＠example.com 11 Feb '09

11 Feb '09

The current proposal has a typedef instead of #define. Are there any specific reasons for preferring the pre-processor macro approach? Thanx! Kannan -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Supalov, Alexander Sent: Wednesday, February 11, 2009 6:44 AM To: MPI 2.2 Subject: Re: [Mpi-22] #117: Define a new MPI_Count Datatype Hi, Thanks. I added an offline comment regarding the #define trick for MPI-2.2. Has this been addressed? Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Narasimhan, Kannan Sent: Wednesday, February 11, 2009 12:54 AM To: MPI 2.2 Subject: [Mpi-22] #117: Define a new MPI_Count Datatype I've updated Ticket #117 ( Define a new MPI_Count Datatype ) to address the issues raised at the MPI Forum Meeting. Is there any other concern that is not addressed in this ticket? Thanx! Kannan _______________________________________________ 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. _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22

1 0

Re: [Mpi-22] #117: Define a new MPI_Count Datatype
by unknown＠example.com 11 Feb '09

11 Feb '09

Hi, Thanks. I added an offline comment regarding the #define trick for MPI-2.2. Has this been addressed? Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Narasimhan, Kannan Sent: Wednesday, February 11, 2009 12:54 AM To: MPI 2.2 Subject: [Mpi-22] #117: Define a new MPI_Count Datatype I've updated Ticket #117 ( Define a new MPI_Count Datatype ) to address the issues raised at the MPI Forum Meeting. Is there any other concern that is not addressed in this ticket? Thanx! Kannan _______________________________________________ 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.

1 0

#117: Define a new MPI_Count Datatype
by unknown＠example.com 10 Feb '09

10 Feb '09

I've updated Ticket #117 ( Define a new MPI_Count Datatype ) to address the issues raised at the MPI Forum Meeting. Is there any other concern that is not addressed in this ticket? Thanx! Kannan

1 0

Fwd: [MPI Forum] #2: MPI_TYPE_GET_ENVELOPE and MPI_TYPE_GET_CONTENTS ambiguities introduced in MPI-2.1
by unknown＠example.com 10 Feb '09

10 Feb '09

FYI -- this contentious ticket has been withdrawn. The reviewers and myself all missed a statement immediately preceding the language neutral bindings of MPI_TYPE_GET_CONTENTS that says: The actual arguments used in the creation call for a datatype can be obtained from the call: Hence, the current text is perfectly clear on what the behavior should be. Begin forwarded message: > From: "MPI Forum" <mpi-22_at_[hidden]> > Date: February 10, 2009 3:43:48 PM PST > Subject: Re: [MPI Forum] #2: MPI_TYPE_GET_ENVELOPE and > MPI_TYPE_GET_CONTENTS ambiguities introduced in MPI-2.1 > > #2: MPI_TYPE_GET_ENVELOPE and MPI_TYPE_GET_CONTENTS ambiguities > introduced in > MPI-2.1 > -------------------------------- > +------------------------------------------- > Reporter: jsquyres | Owner: jsquyres > Type: Text (only) changes | Status: closed > Priority: Waiting for reviews | Milestone: 2009/02/09 San Jose > Version: MPI 2.2 | Resolution: Withdrawn > Keywords: | > -------------------------------- > +------------------------------------------- > Changes (by jsquyres): > > * status: assigned => closed > * resolution: => Withdrawn > > > Old description: > >> == Description == >> >> Sep 8 2008 Straw Vote >> >> || return 0|| don't return 0 || Abstain || >> || 17 || 1 || 9 || >> >> MPI-2.1 introduced an ambiguity in the interpretation of what >> MPI_TYPE_GET_CONTENTS is supposed to return. Specifically: MPI-2.1 >> introduced that user-defined datatypes could be created with zero >> counts >> for datatypes. The ambiguity originates from two sections of text: >> >> * MPI-2.1: p78:18-20 >> Most datatype constructors have replication count or block length >> arguments. Allowed values are nonnegative integers. If the value is >> zero, >> no elements are generated in the type map and there is no effect on >> datatype bounds or extent. >> * MPI-2.1: p107:47-48 >> The datatypes returned in array_of_datatypes are handles to >> datatype >> objects that are equivalent to the datatypes used in the original >> construction call. >> >> If datatype constructors accept 0-count datatype arguments that are >> supposed to have "no elements are generated in the type map" and "no >> effect on datatype bounds or extent", should MPI_TYPE_GET_CONTENTS >> return >> those 0-count datatypes in array_of_datatypes? After all, >> MPI_TYPE_GET_CONTENTS says that array_of_datatypes is supposed to >> contain >> handles to datatype objects that are equivalent to the datatypes >> used in >> the original construction call (which used 0-count datatypes). >> >> A similar problem exists with MPI_TYPE_GET_ENVELOPE; does >> num_datatypes >> contain a count of all the zero-count datatypes specified in the >> constructor? >> >> == History == >> >> Ambiguity was accidentally introduced in MPI-2.1 (verified in July >> 2008 >> Forum meeting). >> >> == Proposed Solution == >> >> Change MPI-2.1 p107:47-48 from: >> >> The datatypes returned in array_of_datatypes are handles to datatype >> objects that are equivalent to the datatypes used in the original >> construction call. >> >> to >> >> The datatypes returned in array_of_datatypes are handles to datatype >> objects that are equivalent to the significant datatypes used in the >> original construction call (datatypes with zero count or zero >> blocklength >> are not considered significant). >> >> == Impact on Implementations == >> >> Implementations that return zero-count or zero-blocklength >> datatypes will >> need to be updated to not return them. >> >> == Impact on Applications / Users == >> >> Applications will need to recognize that zero-count/zero-blocklength >> datatypes will not be returned from MPI_TYPE_CONTENTS. This is not >> expected to be a burden because the the intended consumers of >> MPI_TYPE_CONTENTS are looking for the "significant" datatypes (vs. >> looking for insignificant datatypes that will just be discarded). >> >> == Alternative Solutions == >> >> * Change it so that MPI_TYPE_CONTENTS specifically returns zero- >> count/ >> zero-blocklength datatypes. This does not seem useful to the >> expected >> consumers of MPI_TYPE_CONTENTS. >> * Allow MPI implementations to either return the zero-count >> datatypes or >> not. From the user perspective, this is the same as requiring MPI >> implementations to return the zero-count datatypes because the >> application will need to check for zero-count datatypes in >> array_of_datatypes. >> >> == Entry for the Change Log == >> >> Section 4.1.13 on page 104. Remove ambiguity regarding zero-count >> datatypes with MPI_TYPE_GET_ENVELOPE and MPI_TYPE_GET_CONTENTS. > > New description: > > == Description == > > Sep 8 2008 Straw Vote > > || return 0|| don't return 0 || Abstain || > || 17 || 1 || 9 || > > MPI-2.1 introduced an ambiguity in the interpretation of what > MPI_TYPE_GET_CONTENTS is supposed to return. Specifically: MPI-2.1 > introduced that user-defined datatypes could be created with zero > counts > for datatypes. The ambiguity originates from two sections of text: > > * MPI-2.1: p78:18-20 > Most datatype constructors have replication count or block length > arguments. Allowed values are nonnegative integers. If the value is > zero, > no elements are generated in the type map and there is no effect on > datatype bounds or extent. > * MPI-2.1: p107:47-48 > The datatypes returned in array_of_datatypes are handles to > datatype > objects that are equivalent to the datatypes used in the original > construction call. > > If datatype constructors accept 0-count datatype arguments that are > supposed to have "no elements are generated in the type map" and "no > effect on datatype bounds or extent", should MPI_TYPE_GET_CONTENTS > return > those 0-count datatypes in array_of_datatypes? After all, > MPI_TYPE_GET_CONTENTS says that array_of_datatypes is supposed to > contain > handles to datatype objects that are equivalent to the datatypes > used in > the original construction call (which used 0-count datatypes). > > A similar problem exists with MPI_TYPE_GET_ENVELOPE; does > num_datatypes > contain a count of all the zero-count datatypes specified in the > constructor? > > == History == > > Ambiguity was accidentally introduced in MPI-2.1 (verified in July > 2008 > Forum meeting). > > == Proposed Solution == > > Change MPI-2.1 p107:47-48 from: > > The datatypes returned in array_of_datatypes are handles to datatype > objects that are equivalent to the datatypes used in the original > construction call. > > to > > The datatypes returned in array_of_datatypes are handles to the same > > handles to datatype objects that are identical to the datatypes used > in > the original construction call, including any zero-count datatypes > that > were specified in the original datatype constructor. > > == Impact on Implementations == > > Implementations may need to be updated to save a copy of the datatypes > passed to datatype constructor functions. > > == Impact on Applications / Users == > > Applications will need to handle zero-count datatypes in what they get > back from MPI_TYPE_CONTENTS. This is not expected to be a burden > because > the user created the datatype with a zero-count datatype anyway. > > == Alternative Solutions == > > * Change it so that MPI_TYPE_CONTENTS specifically excludes zero- > count > datatypes. This does not seem to be consistent. > * Allow MPI implementations to either return the zero-count > datatypes or > not. From the user perspective, this is the same as requiring MPI > implementations to return the zero-count datatypes because the > application > will need to check for zero-count datatypes in array_of_datatypes. > > == Entry for the Change Log == > > Section 4.1.13 on page 104. Remove ambiguity regarding zero-count > datatypes with MPI_TYPE_GET_ENVELOPE and MPI_TYPE_GET_CONTENTS. > > -- > > Comment: > > It turns out that all of us missed the following statement MPI-2.1 > p107:1-2: > > The actual arguments used in the creation call for a datatype can be > obtained from the call: > > (followed by the language neutral binding for MPI_TYPE_GET_CONTENTS) > > Hence, I withdraw this ticket -- the current text is perfectly clear > on > exactly what the behavior should be (sorry Dick!). > > -- > Ticket URL: <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/2#comment:26 > > > MPI Forum <https://svn.mpi-forum.org/> > MPI Forum -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-22] [MPI Forum] #111: Fix predefined attributes
by unknown＠example.com 10 Feb '09

10 Feb '09

Does Cray return a pointer to an int in the C case and the value of a INTEGER in the Fortran case, using different storage for the two values? If so, then we'll have to make the predefined attributes a special case. Bill On Feb 9, 2009, at 7:54 PM, MPI Forum wrote: > #111: Fix predefined attributes > ------------------------------------- > +-------------------------------------- > Reporter: jsquyres | Owner: jsquyres > Type: Correction to standard | Status: new > Priority: Forum feedback requested | Milestone: 2009/02/09 San > Jose > Version: MPI 2.2 | Resolution: > Keywords: | > ------------------------------------- > +-------------------------------------- > > Comment(by jsquyres): > > Cray cites that they have 2 versions of their library -- one that > supports > 32 bit INTEGERs and one that supports 64 bit INTEGERs. However, > both have > 32 bit int's. So changing the "int" to "MPI_Fint" will break user > apps, > and therefore this is problematic for MPI-2.2. > > Need further discussion on what to do here. > > -- > Ticket URL: <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/111#comment:4 > > > MPI Forum <https://svn.mpi-forum.org/> > MPI Forum William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign

1 0

Preparing for MPI Forum Meeting
by unknown＠example.com 06 Feb '09

06 Feb '09

I've gone through all of the MPI 2.2 tickets (or at least I tried, using the "next ticket" button); tickets that I believe are ready for discussion now are set to Milestone San Jose. Please have a look at these (you can use the custom query to select the MPI 2.2 version and the San Jose Milestone. There are many tickets that are waiting for reviews - please have a look at these. Authors, please make sure that you have the necessary 4 reviews - this will be a prerequisite for discussion next week. Thanks and see you Monday! Bill William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign

1 0