From jsquyres at [hidden] Fri Jan 18 14:07:08 2008 From: jsquyres at [hidden] (Jeff Squyres) Date: Fri, 18 Jan 2008 15:07:08 -0500 Subject: [mpi-22] Proposal: C++ MPI constructors Message-ID: Per http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/ , the errata item entitled "C++ constructors for MPI objects". Mail discussing: http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discuss/C++objs/ Proposal: MPI-2, page 350, before line 37, add // MPI::Op::Init is deprecated MPI-2, page 350, after line 37, add Op Op::Create(User_function* function, bool commute); --> In MPI-2.2, if the C++ bindings for MPI-1 functions (like MPI_OP_CREATE) are put in the rest of the document, MPI::Op::Init should be marked as deprecated. Rationale: I'm actually reversing my position from the April 2000 e-mail; the path of least resistance is to make MPI::Op be the same as all other MPI classes, even if it is awkward. Specifically, if we *really* wanted to do it right, the C++ bindings for various MPI_*_CREATE functions should be overloaded C++ constructors (e.g., MPI::Op::Op(User_function* function, bool commute), MPI::Intracomm::Intracomm(const Group& group), etc.) so that you could do things like this: MPI::Op op(user_function, true); MPI::Intracomm(group); But I think that's too much for MPI-2.2. Perhaps for MPI-3 (if anyone cares). Note that such constructors would only be syntactic sugar since the same functionality can be obtained in the current MPI C++ API, but the current functionality feels slightly "unnatural" to C++. Note that this is an MPI-2.2 proposal. -- Jeff Squyres Cisco Systems From rlgraham at [hidden] Thu Jan 24 11:08:50 2008 From: rlgraham at [hidden] (Richard Graham) Date: Thu, 24 Jan 2008 12:08:50 -0500 Subject: [mpi-22] FW: [mpi-21] Proposal: MPI_OFFSET built-in type In-Reply-To: <20080124164152.GL24508@mcs.anl.gov> Message-ID: Moving this to the appropriate list. Rich ------ Forwarded Message From: Robert Latham Reply-To: "Mailing list for discussion of MPI 2.1" Date: Thu, 24 Jan 2008 10:41:52 -0600 To: Subject: [mpi-21] Proposal: MPI_OFFSET built-in type I hope this is less contentious than adding 'const' keywords... I would like to propose a new built-in type MPI_OFFSET, defined to be a type corresponding to INTEGER(KIND=MPI_OFFSET_KIND) or MPI_Offset This is a minor addition to the standard, which would have no impact on existing code while serving to simplify code which exchanges file offsets among processes. There is a workaround in the standard: a user can define a type from MPI_BYTE: MPI_Type_contiguous(sizeof(MPI_Offset), MPI_BYTE, &offtype); However, it would clearly be more convienient to operate on built-in types. MPI Datatype: MPI_OFFSET Corresponding C type: long long int Corresponding Fortran type: INTEGER(KIND=MPI_OFFSET_KIND) Thanks ==rob -- Rob Latham Mathematics and Computer Science Division A215 0178 EA2D B059 8CDF Argonne National Lab, IL USA B29D F333 664A 4280 315B _______________________________________________ mpi-21 mailing list mpi-21_at_[hidden] http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 ------ End of Forwarded Message From rabenseifner at [hidden] Thu Jan 24 11:13:50 2008 From: rabenseifner at [hidden] (Rolf Rabenseifner) Date: Thu, 24 Jan 2008 18:13:50 +0100 Subject: [mpi-22] Fwd: Proposal: MPI_OFFSET built-in type In-Reply-To: <20080124164152.GL24508@mcs.anl.gov> Message-ID: There is already a bullet on that topic, see MPI_AINT, MPI_OFFSET Is there an MPI datatype that can be used to send and receive these values? This needed by applications working with MPI windows and files. in section Clarifications (10th item there) on http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/ Bill Gropp has proposed to put this topic on the agenda of MPI 2.2. I agree and I'm forwarding your mail therefore to the MPI 2.2 mailing list. On Thu, 24 Jan 2008 10:41:52 -0600 robl_at_[hidden] (Robert Latham) wrote: >I hope this is less contentious than adding 'const' keywords... > > >I would like to propose a new built-in type MPI_OFFSET, defined to be >a type corresponding to INTEGER(KIND=MPI_OFFSET_KIND) or MPI_Offset > >This is a minor addition to the standard, which would have no impact >on existing code while serving to simplify code which exchanges file >offsets among processes. > >There is a workaround in the standard: a user can define a type from >MPI_BYTE: > > MPI_Type_contiguous(sizeof(MPI_Offset), MPI_BYTE, &offtype); > >However, it would clearly be more convienient to operate on built-in >types. > >MPI Datatype: MPI_OFFSET >Corresponding C type: long long int >Corresponding Fortran type: INTEGER(KIND=MPI_OFFSET_KIND) > > >Thanks >==rob > >-- >Rob Latham >Mathematics and Computer Science Division A215 0178 EA2D B059 8CDF >Argonne National Lab, IL USA B29D F333 664A 4280 315B >_______________________________________________ >mpi-21 mailing list >mpi-21_at_[hidden] >http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) From thakur at [hidden] Thu Jan 24 11:18:52 2008 From: thakur at [hidden] (Rajeev Thakur) Date: Thu, 24 Jan 2008 11:18:52 -0600 Subject: [mpi-22] FW: [mpi-21] Proposal: MPI_OFFSET built-in type In-Reply-To: Message-ID: <003701c85ead$31457d90$860add8c@mcs.anl.gov> A similar one is needed for MPI_Aint. Rajeev > -----Original Message----- > From: mpi-22-bounces_at_[hidden] > [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Richard Graham > Sent: Thursday, January 24, 2008 11:09 AM > To: mpi-22_at_[hidden] > Subject: [mpi-22] FW: [mpi-21] Proposal: MPI_OFFSET built-in type > > Moving this to the appropriate list. > > Rich > > ------ Forwarded Message > From: Robert Latham > Reply-To: "Mailing list for discussion of MPI 2.1" > > Date: Thu, 24 Jan 2008 10:41:52 -0600 > To: > Subject: [mpi-21] Proposal: MPI_OFFSET built-in type > > I hope this is less contentious than adding 'const' keywords... > > > I would like to propose a new built-in type MPI_OFFSET, defined to be > a type corresponding to INTEGER(KIND=MPI_OFFSET_KIND) or MPI_Offset > > This is a minor addition to the standard, which would have no impact > on existing code while serving to simplify code which exchanges file > offsets among processes. > > There is a workaround in the standard: a user can define a type from > MPI_BYTE: > > MPI_Type_contiguous(sizeof(MPI_Offset), MPI_BYTE, &offtype); > > However, it would clearly be more convienient to operate on built-in > types. > > MPI Datatype: MPI_OFFSET > Corresponding C type: long long int > Corresponding Fortran type: INTEGER(KIND=MPI_OFFSET_KIND) > > > Thanks > ==rob > > -- > Rob Latham > Mathematics and Computer Science Division A215 0178 EA2D B059 8CDF > Argonne National Lab, IL USA B29D F333 664A 4280 315B > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > > ------ End of Forwarded Message > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-22 > > From rlgraham at [hidden] Thu Jan 24 11:48:21 2008 From: rlgraham at [hidden] (Richard Graham) Date: Thu, 24 Jan 2008 12:48:21 -0500 Subject: [mpi-22] FW: [mpi-21] Proposal: MPI_OFFSET built-in type In-Reply-To: <003701c85ead$31457d90$860add8c@mcs.anl.gov> Message-ID: Do you think this should go into 2.2 or 3.0 ? I ask not because the change is large, but because it will change the signature of several interface functions (presumably marking the older functions as deprecated - for removal in X number of years). There is another change that I would like to see added to the standard, which is adding a way to convey information between MPI_Alloc_mem() to the functions using this memory, w/o forcing the implementations to try and use all sorts of non-portable solutions to figure out if this memory can be used "as-is" by the network layer, of if it needs to be "prepared" (pinned, and ?). It seems prudent to combine such interface changes into the smallest number of changes (1 is preferred). What do you think ? Rich On 1/24/08 12:18 PM, "Rajeev Thakur" wrote: > A similar one is needed for MPI_Aint. > > Rajeev > >> -----Original Message----- >> From: mpi-22-bounces_at_[hidden] >> [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Richard Graham >> Sent: Thursday, January 24, 2008 11:09 AM >> To: mpi-22_at_[hidden] >> Subject: [mpi-22] FW: [mpi-21] Proposal: MPI_OFFSET built-in type >> >> Moving this to the appropriate list. >> >> Rich >> >> ------ Forwarded Message >> From: Robert Latham >> Reply-To: "Mailing list for discussion of MPI 2.1" >> >> Date: Thu, 24 Jan 2008 10:41:52 -0600 >> To: >> Subject: [mpi-21] Proposal: MPI_OFFSET built-in type >> >> I hope this is less contentious than adding 'const' keywords... >> >> >> I would like to propose a new built-in type MPI_OFFSET, defined to be >> a type corresponding to INTEGER(KIND=MPI_OFFSET_KIND) or MPI_Offset >> >> This is a minor addition to the standard, which would have no impact >> on existing code while serving to simplify code which exchanges file >> offsets among processes. >> >> There is a workaround in the standard: a user can define a type from >> MPI_BYTE: >> >> MPI_Type_contiguous(sizeof(MPI_Offset), MPI_BYTE, &offtype); >> >> However, it would clearly be more convienient to operate on built-in >> types. >> >> MPI Datatype: MPI_OFFSET >> Corresponding C type: long long int >> Corresponding Fortran type: INTEGER(KIND=MPI_OFFSET_KIND) >> >> >> Thanks >> ==rob >> >> -- >> Rob Latham >> Mathematics and Computer Science Division A215 0178 EA2D B059 8CDF >> Argonne National Lab, IL USA B29D F333 664A 4280 315B >> _______________________________________________ >> mpi-21 mailing list >> mpi-21_at_[hidden] >> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 >> >> ------ End of Forwarded Message >> >> _______________________________________________ >> mpi-22 mailing list >> mpi-22_at_[hidden] >> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-22 >> >> > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-22 From thakur at [hidden] Thu Jan 24 11:55:53 2008 From: thakur at [hidden] (Rajeev Thakur) Date: Thu, 24 Jan 2008 11:55:53 -0600 Subject: [mpi-22] FW: [mpi-21] Proposal: MPI_OFFSET built-in type In-Reply-To: Message-ID: <005601c85eb2$5ccb5c00$860add8c@mcs.anl.gov> Is it an interface change? It would be an addition to the set of predefined types, such as MPI_INT, MPI_CHAR, so it should just work I think. >> MPI Datatype: MPI_OFFSET >> Corresponding C type: long long int >> Corresponding Fortran type: INTEGER(KIND=MPI_OFFSET_KIND) The corresponding C type should be "implementation defined". It could be int for example in an implementation that only supports 32-bit file sizes. Rajeev > -----Original Message----- > From: mpi-22-bounces_at_[hidden] > [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Richard Graham > Sent: Thursday, January 24, 2008 11:48 AM > To: mpi-22_at_[hidden] > Subject: Re: [mpi-22] FW: [mpi-21] Proposal: MPI_OFFSET built-in type > > Do you think this should go into 2.2 or 3.0 ? I ask not > because the change > is large, but because it will change the signature of several > interface > functions (presumably marking the older functions as deprecated - for > removal in X number of years). There is another change that > I would like to > see added to the standard, which is adding a way to convey information > between MPI_Alloc_mem() to the functions using this memory, > w/o forcing the > implementations to try and use all sorts of non-portable > solutions to figure > out if this memory can be used "as-is" by the network layer, > of if it needs > to be "prepared" (pinned, and ?). > > It seems prudent to combine such interface changes into the > smallest number > of changes (1 is preferred). > > What do you think ? > Rich > > > On 1/24/08 12:18 PM, "Rajeev Thakur" wrote: > > > A similar one is needed for MPI_Aint. > > > > Rajeev > > > >> -----Original Message----- > >> From: mpi-22-bounces_at_[hidden] > >> [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Richard Graham > >> Sent: Thursday, January 24, 2008 11:09 AM > >> To: mpi-22_at_[hidden] > >> Subject: [mpi-22] FW: [mpi-21] Proposal: MPI_OFFSET built-in type > >> > >> Moving this to the appropriate list. > >> > >> Rich > >> > >> ------ Forwarded Message > >> From: Robert Latham > >> Reply-To: "Mailing list for discussion of MPI 2.1" > >> > >> Date: Thu, 24 Jan 2008 10:41:52 -0600 > >> To: > >> Subject: [mpi-21] Proposal: MPI_OFFSET built-in type > >> > >> I hope this is less contentious than adding 'const' keywords... > >> > >> > >> I would like to propose a new built-in type MPI_OFFSET, > defined to be > >> a type corresponding to INTEGER(KIND=MPI_OFFSET_KIND) or MPI_Offset > >> > >> This is a minor addition to the standard, which would have > no impact > >> on existing code while serving to simplify code which > exchanges file > >> offsets among processes. > >> > >> There is a workaround in the standard: a user can define a > type from > >> MPI_BYTE: > >> > >> MPI_Type_contiguous(sizeof(MPI_Offset), MPI_BYTE, &offtype); > >> > >> However, it would clearly be more convienient to operate > on built-in > >> types. > >> > >> MPI Datatype: MPI_OFFSET > >> Corresponding C type: long long int > >> Corresponding Fortran type: INTEGER(KIND=MPI_OFFSET_KIND) > >> > >> > >> Thanks > >> ==rob > >> > >> -- > >> Rob Latham > >> Mathematics and Computer Science Division A215 0178 > EA2D B059 8CDF > >> Argonne National Lab, IL USA B29D F333 > 664A 4280 315B > >> _______________________________________________ > >> mpi-21 mailing list > >> mpi-21_at_[hidden] > >> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > >> > >> ------ End of Forwarded Message > >> > >> _______________________________________________ > >> mpi-22 mailing list > >> mpi-22_at_[hidden] > >> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-22 > >> > >> > > > > _______________________________________________ > > mpi-22 mailing list > > mpi-22_at_[hidden] > > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-22 > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-22 > > From jsquyres at [hidden] Thu Jan 24 19:52:17 2008 From: jsquyres at [hidden] (Jeff Squyres) Date: Thu, 24 Jan 2008 20:52:17 -0500 Subject: [mpi-22] FW: [mpi-21] Proposal: MPI_OFFSET built-in type In-Reply-To: <005601c85eb2$5ccb5c00$860add8c@mcs.anl.gov> Message-ID: Don't forget MPI::OFFSET (and MPI::AINT). And they should be const. ;-) On Jan 24, 2008, at 12:55 PM, Rajeev Thakur wrote: > Is it an interface change? It would be an addition to the set of > predefined > types, such as MPI_INT, MPI_CHAR, so it should just work I think. > >>> MPI Datatype: MPI_OFFSET >>> Corresponding C type: long long int >>> Corresponding Fortran type: INTEGER(KIND=MPI_OFFSET_KIND) > > The corresponding C type should be "implementation defined". It > could be int > for example in an implementation that only supports 32-bit file sizes. > > Rajeev > > >> -----Original Message----- >> From: mpi-22-bounces_at_[hidden] >> [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Richard Graham >> Sent: Thursday, January 24, 2008 11:48 AM >> To: mpi-22_at_[hidden] >> Subject: Re: [mpi-22] FW: [mpi-21] Proposal: MPI_OFFSET built-in type >> >> Do you think this should go into 2.2 or 3.0 ? I ask not >> because the change >> is large, but because it will change the signature of several >> interface >> functions (presumably marking the older functions as deprecated - for >> removal in X number of years). There is another change that >> I would like to >> see added to the standard, which is adding a way to convey >> information >> between MPI_Alloc_mem() to the functions using this memory, >> w/o forcing the >> implementations to try and use all sorts of non-portable >> solutions to figure >> out if this memory can be used "as-is" by the network layer, >> of if it needs >> to be "prepared" (pinned, and ?). >> >> It seems prudent to combine such interface changes into the >> smallest number >> of changes (1 is preferred). >> >> What do you think ? >> Rich >> >> >> On 1/24/08 12:18 PM, "Rajeev Thakur" wrote: >> >>> A similar one is needed for MPI_Aint. >>> >>> Rajeev >>> >>>> -----Original Message----- >>>> From: mpi-22-bounces_at_[hidden] >>>> [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Richard Graham >>>> Sent: Thursday, January 24, 2008 11:09 AM >>>> To: mpi-22_at_[hidden] >>>> Subject: [mpi-22] FW: [mpi-21] Proposal: MPI_OFFSET built-in type >>>> >>>> Moving this to the appropriate list. >>>> >>>> Rich >>>> >>>> ------ Forwarded Message >>>> From: Robert Latham >>>> Reply-To: "Mailing list for discussion of MPI 2.1" >>>> >>>> Date: Thu, 24 Jan 2008 10:41:52 -0600 >>>> To: >>>> Subject: [mpi-21] Proposal: MPI_OFFSET built-in type >>>> >>>> I hope this is less contentious than adding 'const' keywords... >>>> >>>> >>>> I would like to propose a new built-in type MPI_OFFSET, >> defined to be >>>> a type corresponding to INTEGER(KIND=MPI_OFFSET_KIND) or MPI_Offset >>>> >>>> This is a minor addition to the standard, which would have >> no impact >>>> on existing code while serving to simplify code which >> exchanges file >>>> offsets among processes. >>>> >>>> There is a workaround in the standard: a user can define a >> type from >>>> MPI_BYTE: >>>> >>>> MPI_Type_contiguous(sizeof(MPI_Offset), MPI_BYTE, &offtype); >>>> >>>> However, it would clearly be more convienient to operate >> on built-in >>>> types. >>>> >>>> MPI Datatype: MPI_OFFSET >>>> Corresponding C type: long long int >>>> Corresponding Fortran type: INTEGER(KIND=MPI_OFFSET_KIND) >>>> >>>> >>>> Thanks >>>> ==rob >>>> >>>> -- >>>> Rob Latham >>>> Mathematics and Computer Science Division A215 0178 >> EA2D B059 8CDF >>>> Argonne National Lab, IL USA B29D F333 >> 664A 4280 315B >>>> _______________________________________________ >>>> mpi-21 mailing list >>>> mpi-21_at_[hidden] >>>> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 >>>> >>>> ------ End of Forwarded Message >>>> >>>> _______________________________________________ >>>> mpi-22 mailing list >>>> mpi-22_at_[hidden] >>>> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-22 >>>> >>>> >>> >>> _______________________________________________ >>> mpi-22 mailing list >>> mpi-22_at_[hidden] >>> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-22 >> >> _______________________________________________ >> mpi-22 mailing list >> mpi-22_at_[hidden] >> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-22 >> >> > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-22 -- Jeff Squyres Cisco Systems From traff at [hidden] Mon Jan 28 07:48:29 2008 From: traff at [hidden] (Jesper Larsson Traeff) Date: Mon, 28 Jan 2008 14:48:29 +0100 Subject: [mpi-22] FW: [mpi-21] Proposal: MPI_OFFSET built-in type In-Reply-To: <003701c85ead$31457d90$860add8c@mcs.anl.gov> Message-ID: <20080128134829.GA5118@fourier.it.neclab.eu> On Thu, Jan 24, 2008 at 11:18:52AM -0600, Rajeev Thakur wrote: > A similar one is needed for MPI_Aint. > yes, it is needed... but maybe it was really not intended in MPI-1 that addresses be sent around, and therefore there was no MPI_AINT? A cleaner (overly puristic?) solution would be to introduce more types with MPI types only for those really intended to be communicable, e.g. MPI_COUNT (MPI type for new MPI_Count type), MPI_OFFSET (for MPI_Offset), ... Unfortunately, introducing new types would/could have large consequences for the interface... Related concerns for MPI-3.0 discussion: can MPI_Op's be sent (useful when writing MPI correctness checking software)? can MPI_Datatypes be sent (currently not - but would be very useful in combination with more functionality for manipulating datatypes)? Jesper > Rajeev > > > -----Original Message----- > > From: mpi-22-bounces_at_[hidden] > > [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Richard Graham > > Sent: Thursday, January 24, 2008 11:09 AM > > To: mpi-22_at_[hidden] > > Subject: [mpi-22] FW: [mpi-21] Proposal: MPI_OFFSET built-in type > > > > Moving this to the appropriate list. > > > > Rich > > > > ------ Forwarded Message > > From: Robert Latham > > Reply-To: "Mailing list for discussion of MPI 2.1" > > > > Date: Thu, 24 Jan 2008 10:41:52 -0600 > > To: > > Subject: [mpi-21] Proposal: MPI_OFFSET built-in type > > > > I hope this is less contentious than adding 'const' keywords... > > > > > > I would like to propose a new built-in type MPI_OFFSET, defined to be > > a type corresponding to INTEGER(KIND=MPI_OFFSET_KIND) or MPI_Offset > > > > This is a minor addition to the standard, which would have no impact > > on existing code while serving to simplify code which exchanges file > > offsets among processes. > > > > There is a workaround in the standard: a user can define a type from > > MPI_BYTE: > > > > MPI_Type_contiguous(sizeof(MPI_Offset), MPI_BYTE, &offtype); > > > > However, it would clearly be more convienient to operate on built-in > > types. > > > > MPI Datatype: MPI_OFFSET > > Corresponding C type: long long int > > Corresponding Fortran type: INTEGER(KIND=MPI_OFFSET_KIND) > > > > > > Thanks > > ==rob > > > > -- > > Rob Latham > > Mathematics and Computer Science Division A215 0178 EA2D B059 8CDF > > Argonne National Lab, IL USA B29D F333 664A 4280 315B > > _______________________________________________ > > mpi-21 mailing list > > mpi-21_at_[hidden] > > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > > > > ------ End of Forwarded Message > > > > _______________________________________________ > > mpi-22 mailing list > > mpi-22_at_[hidden] > > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-22 > > > > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-22 From thakur at [hidden] Mon Jan 28 10:55:17 2008 From: thakur at [hidden] (Rajeev Thakur) Date: Mon, 28 Jan 2008 10:55:17 -0600 Subject: [mpi-22] FW: [mpi-21] Proposal: MPI_OFFSET built-in type In-Reply-To: <20080128134829.GA5118@fourier.it.neclab.eu> Message-ID: <002201c861ce$8f805a50$860add8c@mcs.anl.gov> MPI_Aint is also used for extent of a datatype and size of a window, which one may want to communicate. Rajeev > -----Original Message----- > From: mpi-22-bounces_at_[hidden] > [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jesper Larsson Traeff > Sent: Monday, January 28, 2008 7:48 AM > To: Discussion of MPI Standard version 2.2 > Subject: Re: [mpi-22] FW: [mpi-21] Proposal: MPI_OFFSET built-in type > > On Thu, Jan 24, 2008 at 11:18:52AM -0600, Rajeev Thakur wrote: > > A similar one is needed for MPI_Aint. > > > yes, it is needed... but maybe it was really not intended in > MPI-1 that > addresses be sent around, and therefore there was no MPI_AINT? > > A cleaner (overly puristic?) solution would be to introduce > more types > with MPI types only for those really intended to be > communicable, e.g. > MPI_COUNT (MPI type for new MPI_Count type), MPI_OFFSET (for > MPI_Offset), ... > Unfortunately, introducing new types would/could have large > consequences > for the interface... > > Related concerns for MPI-3.0 discussion: can MPI_Op's be sent (useful > when writing MPI correctness checking software)? can MPI_Datatypes be > sent (currently not - but would be very useful in combination > with more > functionality for manipulating datatypes)? > > Jesper > > > Rajeev > > > > > -----Original Message----- > > > From: mpi-22-bounces_at_[hidden] > > > [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Richard Graham > > > Sent: Thursday, January 24, 2008 11:09 AM > > > To: mpi-22_at_[hidden] > > > Subject: [mpi-22] FW: [mpi-21] Proposal: MPI_OFFSET built-in type > > > > > > Moving this to the appropriate list. > > > > > > Rich > > > > > > ------ Forwarded Message > > > From: Robert Latham > > > Reply-To: "Mailing list for discussion of MPI 2.1" > > > > > > Date: Thu, 24 Jan 2008 10:41:52 -0600 > > > To: > > > Subject: [mpi-21] Proposal: MPI_OFFSET built-in type > > > > > > I hope this is less contentious than adding 'const' keywords... > > > > > > > > > I would like to propose a new built-in type MPI_OFFSET, > defined to be > > > a type corresponding to INTEGER(KIND=MPI_OFFSET_KIND) or > MPI_Offset > > > > > > This is a minor addition to the standard, which would > have no impact > > > on existing code while serving to simplify code which > exchanges file > > > offsets among processes. > > > > > > There is a workaround in the standard: a user can define > a type from > > > MPI_BYTE: > > > > > > MPI_Type_contiguous(sizeof(MPI_Offset), MPI_BYTE, &offtype); > > > > > > However, it would clearly be more convienient to operate > on built-in > > > types. > > > > > > MPI Datatype: MPI_OFFSET > > > Corresponding C type: long long int > > > Corresponding Fortran type: INTEGER(KIND=MPI_OFFSET_KIND) > > > > > > > > > Thanks > > > ==rob > > > > > > -- > > > Rob Latham > > > Mathematics and Computer Science Division A215 0178 > EA2D B059 8CDF > > > Argonne National Lab, IL USA B29D F333 > 664A 4280 315B > > > _______________________________________________ > > > mpi-21 mailing list > > > mpi-21_at_[hidden] > > > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > > > > > > ------ End of Forwarded Message > > > > > > _______________________________________________ > > > mpi-22 mailing list > > > mpi-22_at_[hidden] > > > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-22 > > > > > > > > > > _______________________________________________ > > mpi-22 mailing list > > mpi-22_at_[hidden] > > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-22 > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-22 > > From thakur at [hidden] Mon Jan 28 10:59:51 2008 From: thakur at [hidden] (Rajeev Thakur) Date: Mon, 28 Jan 2008 10:59:51 -0600 Subject: [mpi-22] FW: [mpi-21] Proposal: MPI_OFFSET built-in type In-Reply-To: <20080128134829.GA5118@fourier.it.neclab.eu> Message-ID: <002b01c861cf$32e8eef0$860add8c@mcs.anl.gov> > Unfortunately, introducing new types would/could have large > consequences for the interface... Will it change the interface much? It just adds to the list of predefined types. Rajeev > -----Original Message----- > From: mpi-22-bounces_at_[hidden] > [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jesper Larsson Traeff > Sent: Monday, January 28, 2008 7:48 AM > To: Discussion of MPI Standard version 2.2 > Subject: Re: [mpi-22] FW: [mpi-21] Proposal: MPI_OFFSET built-in type > > On Thu, Jan 24, 2008 at 11:18:52AM -0600, Rajeev Thakur wrote: > > A similar one is needed for MPI_Aint. > > > yes, it is needed... but maybe it was really not intended in > MPI-1 that > addresses be sent around, and therefore there was no MPI_AINT? > > A cleaner (overly puristic?) solution would be to introduce > more types > with MPI types only for those really intended to be > communicable, e.g. > MPI_COUNT (MPI type for new MPI_Count type), MPI_OFFSET (for > MPI_Offset), ... > Unfortunately, introducing new types would/could have large > consequences > for the interface... > > Related concerns for MPI-3.0 discussion: can MPI_Op's be sent (useful > when writing MPI correctness checking software)? can MPI_Datatypes be > sent (currently not - but would be very useful in combination > with more > functionality for manipulating datatypes)? > > Jesper > > > Rajeev > > > > > -----Original Message----- > > > From: mpi-22-bounces_at_[hidden] > > > [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Richard Graham > > > Sent: Thursday, January 24, 2008 11:09 AM > > > To: mpi-22_at_[hidden] > > > Subject: [mpi-22] FW: [mpi-21] Proposal: MPI_OFFSET built-in type > > > > > > Moving this to the appropriate list. > > > > > > Rich > > > > > > ------ Forwarded Message > > > From: Robert Latham > > > Reply-To: "Mailing list for discussion of MPI 2.1" > > > > > > Date: Thu, 24 Jan 2008 10:41:52 -0600 > > > To: > > > Subject: [mpi-21] Proposal: MPI_OFFSET built-in type > > > > > > I hope this is less contentious than adding 'const' keywords... > > > > > > > > > I would like to propose a new built-in type MPI_OFFSET, > defined to be > > > a type corresponding to INTEGER(KIND=MPI_OFFSET_KIND) or > MPI_Offset > > > > > > This is a minor addition to the standard, which would > have no impact > > > on existing code while serving to simplify code which > exchanges file > > > offsets among processes. > > > > > > There is a workaround in the standard: a user can define > a type from > > > MPI_BYTE: > > > > > > MPI_Type_contiguous(sizeof(MPI_Offset), MPI_BYTE, &offtype); > > > > > > However, it would clearly be more convienient to operate > on built-in > > > types. > > > > > > MPI Datatype: MPI_OFFSET > > > Corresponding C type: long long int > > > Corresponding Fortran type: INTEGER(KIND=MPI_OFFSET_KIND) > > > > > > > > > Thanks > > > ==rob > > > > > > -- > > > Rob Latham > > > Mathematics and Computer Science Division A215 0178 > EA2D B059 8CDF > > > Argonne National Lab, IL USA B29D F333 > 664A 4280 315B > > > _______________________________________________ > > > mpi-21 mailing list > > > mpi-21_at_[hidden] > > > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > > > > > > ------ End of Forwarded Message > > > > > > _______________________________________________ > > > mpi-22 mailing list > > > mpi-22_at_[hidden] > > > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-22 > > > > > > > > > > _______________________________________________ > > mpi-22 mailing list > > mpi-22_at_[hidden] > > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-22 > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-22 > > From traff at [hidden] Mon Jan 28 11:14:23 2008 From: traff at [hidden] (Jesper Larsson Traeff) Date: Mon, 28 Jan 2008 18:14:23 +0100 Subject: [mpi-22] FW: [mpi-21] Proposal: MPI_OFFSET built-in type In-Reply-To: <002201c861ce$8f805a50$860add8c@mcs.anl.gov> Message-ID: <20080128171423.GA7870@fourier.it.neclab.eu> On Mon, Jan 28, 2008 at 10:55:17AM -0600, Rajeev Thakur wrote: > MPI_Aint is also used for extent of a datatype and size of a window, which > one may want to communicate. > One does want to communicate those things. Having an MPI_AINT would be the easiest solution, but not the cleanest or most correct... If new types were introduced, the interfaces should be changed correspondingly (eg. MPI_Count for count arguments), and that would be a big change... I don't want to push the point, though. Jesper > Rajeev > > > > -----Original Message----- > > From: mpi-22-bounces_at_[hidden] > > [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jesper Larsson Traeff > > Sent: Monday, January 28, 2008 7:48 AM > > To: Discussion of MPI Standard version 2.2 > > Subject: Re: [mpi-22] FW: [mpi-21] Proposal: MPI_OFFSET built-in type > > > > On Thu, Jan 24, 2008 at 11:18:52AM -0600, Rajeev Thakur wrote: > > > A similar one is needed for MPI_Aint. > > > > > yes, it is needed... but maybe it was really not intended in > > MPI-1 that > > addresses be sent around, and therefore there was no MPI_AINT? > > > > A cleaner (overly puristic?) solution would be to introduce > > more types > > with MPI types only for those really intended to be > > communicable, e.g. > > MPI_COUNT (MPI type for new MPI_Count type), MPI_OFFSET (for > > MPI_Offset), ... > > Unfortunately, introducing new types would/could have large > > consequences > > for the interface... > > > > Related concerns for MPI-3.0 discussion: can MPI_Op's be sent (useful > > when writing MPI correctness checking software)? can MPI_Datatypes be > > sent (currently not - but would be very useful in combination > > with more > > functionality for manipulating datatypes)? > > > > Jesper > > > > > Rajeev > > > > > > > -----Original Message----- > > > > From: mpi-22-bounces_at_[hidden] > > > > [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Richard Graham > > > > Sent: Thursday, January 24, 2008 11:09 AM > > > > To: mpi-22_at_[hidden] > > > > Subject: [mpi-22] FW: [mpi-21] Proposal: MPI_OFFSET built-in type > > > > > > > > Moving this to the appropriate list. > > > > > > > > Rich > > > > > > > > ------ Forwarded Message > > > > From: Robert Latham > > > > Reply-To: "Mailing list for discussion of MPI 2.1" > > > > > > > > Date: Thu, 24 Jan 2008 10:41:52 -0600 > > > > To: > > > > Subject: [mpi-21] Proposal: MPI_OFFSET built-in type > > > > > > > > I hope this is less contentious than adding 'const' keywords... > > > > > > > > > > > > I would like to propose a new built-in type MPI_OFFSET, > > defined to be > > > > a type corresponding to INTEGER(KIND=MPI_OFFSET_KIND) or > > MPI_Offset > > > > > > > > This is a minor addition to the standard, which would > > have no impact > > > > on existing code while serving to simplify code which > > exchanges file > > > > offsets among processes. > > > > > > > > There is a workaround in the standard: a user can define > > a type from > > > > MPI_BYTE: > > > > > > > > MPI_Type_contiguous(sizeof(MPI_Offset), MPI_BYTE, &offtype); > > > > > > > > However, it would clearly be more convienient to operate > > on built-in > > > > types. > > > > > > > > MPI Datatype: MPI_OFFSET > > > > Corresponding C type: long long int > > > > Corresponding Fortran type: INTEGER(KIND=MPI_OFFSET_KIND) > > > > > > > > > > > > Thanks > > > > ==rob > > > > > > > > -- > > > > Rob Latham > > > > Mathematics and Computer Science Division A215 0178 > > EA2D B059 8CDF > > > > Argonne National Lab, IL USA B29D F333 > > 664A 4280 315B > > > > _______________________________________________ > > > > mpi-21 mailing list > > > > mpi-21_at_[hidden] > > > > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > > > > > > > > ------ End of Forwarded Message > > > > > > > > _______________________________________________ > > > > mpi-22 mailing list > > > > mpi-22_at_[hidden] > > > > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-22 > > > > > > > > > > > > > > _______________________________________________ > > > mpi-22 mailing list > > > mpi-22_at_[hidden] > > > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-22 > > _______________________________________________ > > mpi-22 mailing list > > mpi-22_at_[hidden] > > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-22 > > > > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-22 From rabenseifner at [hidden] Tue Jan 29 06:08:31 2008 From: rabenseifner at [hidden] (Rolf Rabenseifner) Date: Tue, 29 Jan 2008 13:08:31 +0100 Subject: [mpi-22] C++ MPI constants In-Reply-To: <[mpi-22] C++ MPI constants> Message-ID: This is a follow up to: MPI C++ Constants conflict with stdio in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/index.html with mail discussion in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discuss/C++constants/ ___________________________________ I want to add the following first part of a mail in another track to this track because it mentions that the C++ problem with SEEK_SET, SEEK_CUR, and SEEK_END does not only exist with stdio.h but also with fcntl.h . ------- ___________________________________ forwarded mail: (From Shared File Pointers, http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discuss/sharedfile/ ) Date: Thu, 21 Dec 2000 14:53:30 -0500 (EST) From: Leonard Wisniewski - Sun High Performance Computing Subject: Two MPI I/O questions To: mpi-comments_at_XXXXXXXXXXXXX Cc: thakur_at_XXXXXXXXXXX I have two MPI I/O questions and I was hoping somebody on this alias would know one or both answers. 1) The MPI C++ bindings for SEEK_SET, SEEK_CUR, and SEEK_END will conflict when used in a source file in which /usr/include/fcntl.h is #include'd. I recall seeing some discussion on this topic, but I don't recall the resolution. 2) ... [this topic is not part of the SEEK_SET, SEEK_CUR, and SEEK_END problem, therefore removed for this mail track] ___________________________________ Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) From bronis at [hidden] Thu Jan 31 11:57:59 2008 From: bronis at [hidden] (Bronis R. de Supinski) Date: Thu, 31 Jan 2008 09:57:59 -0800 (PST) Subject: [mpi-22] [mpi-21] Ballot 4 - MPI_THREAD_FUNNELED - was Re: Attending, topics, etc In-Reply-To: Message-ID: Jim and Rich: Then I suggest that fixing this broken semantic decision is something that we should consider for MPI 2.2. It should not break any existing programs and might even make some existing ones standards conforming. Although I can imagine ways for the MPI implementation to detect that the one thread is not the main thread it is not at all clear to me how it would matter to the implementation. Bronis On Thu, 31 Jan 2008, Cownie, James H wrote: > Because that's how it's always been. We're not adding a restriction with > the change, merely clarifying the existing restriction. > > -- Jim > > James Cownie > SSG/DPD/PAT > Tel: +44 117 9071438 > > ________________________________ > > From: mpi-21-bounces_at_[hidden] [mailto:mpi-21-bounces_at_[hidden]] On > Behalf Of Richard Graham > Sent: 31 January 2008 15:51 > To: Mailing list for discussion of MPI 2.1 > Subject: Re: [mpi-21] Ballot 4 - MPI_THREAD_FUNNELED - was Re: > Attending, topics, etc > > > > Why restrict this to a standard specified thread (main thread), why not > word it > as a singe thread, and let the app decide what thread this is, based on > what > ever criteria it wants to use to select this thread ? > > Rich > > > On 1/31/08 10:27 AM, "Richard Treumann" wrote: > > How about:: > MPI_THREAD_FUNNELED The process may be multi-threaded, but the > application > must insure that only the main thread makes MPI calls. > > > 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-21-bounces_at_[hidden] wrote on 01/31/2008 09:44:08 AM: > > > A simpler change which would seem to achieve the desired clarification > > would be :- > > > > MPI_THREAD_FUNNELED The process may be multi-threaded, but only the > > main > > thread is allowed to make MPI calls. > > > > (and you could add > > If other threads make MPI calls the behavior is undefined. > > if you want to be verbose about it). > > > > -- Jim > > > > James Cownie > > SSG/DPD/PAT > > Tel: +44 117 9071438 > > > > > > > > > > > -----Original Message----- > > > From: mpi-21-bounces_at_[hidden] [mailto:mpi-21-bounces_at_[hidden]] > > > On > > > Behalf Of Rolf Rabenseifner > > > Sent: 31 January 2008 14:31 > > > To: mpi-21_at_[hidden] > > > Subject: [mpi-21] Ballot 4 - MPI_THREAD_FUNNELED - was Re: > Attending, > > > topics, etc > > > > > > This is a proposal for MPI 2.1, Ballot 4. > > > > > > I'm asking especially > > > Greg Lindahl, > > > the participants of the email-discussion in 2007, to review this > > proposal. > > > > > > This is a follow up to: > > > Which thread is the funneled thread? > > > in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- > > > errata/index.html > > > with mail discussion in > > > http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- > > > errata/discuss/funneled/ > > > ___________________________________ > > > > > > Proposal: > > > MPI-2.0 Sect. 8.7.3, MPI_Init_thread, page 196, lines 25-26 read: > > > > > > MPI_THREAD_FUNNELED The process may be multi-threaded, but only > > > the main thread will make MPI calls (all MPI calls are "funneled" > > > to the main thread). > > > > > > but should read: > > > > > > MPI_THREAD_FUNNELED The process may be multi-threaded, but only > > > the main thread will make MPI calls (all MPI calls are "funneled" > > > to the main thread, e.g., by using the OpenMP directive "master" > > > in the application program). > > > ___________________________________ > > > Rationale for this clarification from the email from Greg Lindahl: > > > The existing document doesn't make it clear that > > > the MPI user has to funnel the calls to the main thread; > > > it's not the job of the MPI library. I have seen multiple > > > MPI users confused by this issue, and when I first read > > > this section, I was confused by it, too. > > > ___________________________________ > > > > > > > > > Best regards > > > Rolf > > > > > > > > > > > > > > > Dr. Rolf Rabenseifner . . . . . . . . . .. email > rabenseifner_at_[hidden] > > > High Performance Computing Center (HLRS) . phone > ++49(0)711/685-65530 > > > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / > 685-65832 > > > Head of Dpmt Parallel Computing . . . > www.hlrs.de/people/rabenseifner > > > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) > > > _______________________________________________ > > > mpi-21 mailing list > > > mpi-21_at_[hidden] > > > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > > --------------------------------------------------------------------- > > Intel Corporation (UK) Limited > > Registered No. 1134945 (England) > > Registered Office: Pipers Way, Swindon SN3 1RJ > > VAT No: 860 2173 47 > > > > 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-21 mailing list > > mpi-21_at_[hidden] > > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > > ________________________________ > > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > > > > --------------------------------------------------------------------- > Intel Corporation (UK) Limited > Registered No. 1134945 (England) > Registered Office: Pipers Way, Swindon SN3 1RJ > VAT No: 860 2173 47 > > 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. > From treumann at [hidden] Thu Jan 31 13:35:50 2008 From: treumann at [hidden] (Richard Treumann) Date: Thu, 31 Jan 2008 14:35:50 -0500 Subject: [mpi-22] [mpi-21] Ballot 4 - MPI_THREAD_FUNNELED - was Re: Attending, topics, etc In-Reply-To: Message-ID: Hi Bronis For some time IBM MPI offered a User Space communication mode in which certain adapter resources are mapped into process space. The mapping happens at MPI_Init and once it is done, MPI communication calls can manipulate the adapter to send/recv without a need to switch into the kernel. The ability to access the adapter is actually managed by AIX on a per thread basis. That means that on return from MPI_Init, the thread that called MPI_Init can manipulate the adapter to send/recv but other threads in the process cannot (yet). If an appplication thread that did not go through MPI_Init tries to do send/recv we recognize that it is not yet registered and register it on the fly. We do this because we added thread support before the MPI Forum defined MPI_INIT_THREAD with MPI_THREAD_FUNNELED. By the time the Forum defined MPI_INIT_THREAD we were offering MPI_THREAD_MULTIPLE so stuck with that even when MPI_THREAD_FUNNELED is requested. If we had been starting from scratch we might have decided the for MPI_THREAD_FUNNELED we would not try to do registration on the fly but for MPI_THREAD_MULTIPLE we would. 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 mpi-22-bounces_at_[hidden] wrote on 01/31/2008 12:57:59 PM: > > Jim and Rich: > > Then I suggest that fixing this broken semantic decision is > something that we should consider for MPI 2.2. It should not > break any existing programs and might even make some existing > ones standards conforming. > > Although I can imagine ways for the MPI implementation to detect > that the one thread is not the main thread it is not at all clear > to me how it would matter to the implementation. > > Bronis > > > On Thu, 31 Jan 2008, Cownie, James H wrote: > > > Because that's how it's always been. We're not adding a restriction with > > the change, merely clarifying the existing restriction. > > > > -- Jim > > > > James Cownie > > SSG/DPD/PAT > > Tel: +44 117 9071438 > > > > ________________________________ > > > > From: mpi-21-bounces_at_[hidden] [mailto:mpi-21-bounces_at_[hidden]] On > > Behalf Of Richard Graham > > Sent: 31 January 2008 15:51 > > To: Mailing list for discussion of MPI 2.1 > > Subject: Re: [mpi-21] Ballot 4 - MPI_THREAD_FUNNELED - was Re: > > Attending, topics, etc > > > > > > > > Why restrict this to a standard specified thread (main thread), why not > > word it > > as a singe thread, and let the app decide what thread this is, based on > > what > > ever criteria it wants to use to select this thread ? > > > > Rich > > > > > > On 1/31/08 10:27 AM, "Richard Treumann" wrote: > > > > How about:: > > MPI_THREAD_FUNNELED The process may be multi-threaded, but the > > application > > must insure that only the main thread makes MPI calls. > > > > > > 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-21-bounces_at_[hidden] wrote on 01/31/2008 09:44:08 AM: > > > > > A simpler change which would seem to achieve the desired clarification > > > would be :- > > > > > > MPI_THREAD_FUNNELED The process may be multi-threaded, but only the > > > main > > > thread is allowed to make MPI calls. > > > > > > (and you could add > > > If other threads make MPI calls the behavior is undefined. > > > if you want to be verbose about it). > > > > > > -- Jim > > > > > > James Cownie > > > SSG/DPD/PAT > > > Tel: +44 117 9071438 > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: mpi-21-bounces_at_[hidden] [mailto:mpi-21-bounces_at_[hidden]] > > > > > On > > > > Behalf Of Rolf Rabenseifner > > > > Sent: 31 January 2008 14:31 > > > > To: mpi-21_at_[hidden] > > > > Subject: [mpi-21] Ballot 4 - MPI_THREAD_FUNNELED - was Re: > > Attending, > > > > topics, etc > > > > > > > > This is a proposal for MPI 2.1, Ballot 4. > > > > > > > > I'm asking especially > > > > Greg Lindahl, > > > > the participants of the email-discussion in 2007, to review this > > > proposal. > > > > > > > > This is a follow up to: > > > > Which thread is the funneled thread? > > > > in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- > > > > errata/index.html > > > > with mail discussion in > > > > http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- > > > > errata/discuss/funneled/ > > > > ___________________________________ > > > > > > > > Proposal: > > > > MPI-2.0 Sect. 8.7.3, MPI_Init_thread, page 196, lines 25-26 read: > > > > > > > > MPI_THREAD_FUNNELED The process may be multi-threaded, but only > > > > the main thread will make MPI calls (all MPI calls are "funneled" > > > > to the main thread). > > > > > > > > but should read: > > > > > > > > MPI_THREAD_FUNNELED The process may be multi-threaded, but only > > > > the main thread will make MPI calls (all MPI calls are "funneled" > > > > to the main thread, e.g., by using the OpenMP directive "master" > > > > in the application program). > > > > ___________________________________ > > > > Rationale for this clarification from the email from Greg Lindahl: > > > > The existing document doesn't make it clear that > > > > the MPI user has to funnel the calls to the main thread; > > > > it's not the job of the MPI library. I have seen multiple > > > > MPI users confused by this issue, and when I first read > > > > this section, I was confused by it, too. > > > > ___________________________________ > > > > > > > > > > > > Best regards > > > > Rolf > > > > > > > > > > > > > > > > > > > > Dr. Rolf Rabenseifner . . . . . . . . . .. email > > rabenseifner_at_[hidden] > > > > High Performance Computing Center (HLRS) . phone > > ++49(0)711/685-65530 > > > > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / > > 685-65832 > > > > Head of Dpmt Parallel Computing . . . > > www.hlrs.de/people/rabenseifner > > > > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) > > > > _______________________________________________ > > > > mpi-21 mailing list > > > > mpi-21_at_[hidden] > > > > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > > > --------------------------------------------------------------------- > > > Intel Corporation (UK) Limited > > > Registered No. 1134945 (England) > > > Registered Office: Pipers Way, Swindon SN3 1RJ > > > VAT No: 860 2173 47 > > > > > > 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-21 mailing list > > > mpi-21_at_[hidden] > > > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > > > > ________________________________ > > > > _______________________________________________ > > mpi-21 mailing list > > mpi-21_at_[hidden] > > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > > > > > > > > --------------------------------------------------------------------- > > Intel Corporation (UK) Limited > > Registered No. 1134945 (England) > > Registered Office: Pipers Way, Swindon SN3 1RJ > > VAT No: 860 2173 47 > > > > 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.cs.uiuc.edu/mailman/listinfo/mpi-22 * -------------- next part -------------- An HTML attachment was scrubbed... URL: From bronis at [hidden] Thu Jan 31 14:58:53 2008 From: bronis at [hidden] (Bronis R. de Supinski) Date: Thu, 31 Jan 2008 12:58:53 -0800 (PST) Subject: [mpi-22] [mpi-21] Ballot 4 - MPI_THREAD_FUNNELED - was Re: Attending, topics, etc In-Reply-To: Message-ID: Dick: Re: > For some time IBM MPI offered a User Space communication mode in which > certain adapter resources are mapped into process space. The mapping > happens at MPI_Init and once it is done, MPI communication calls can > manipulate the adapter to send/recv without a need to switch into the > kernel. The ability to access the adapter is actually managed by AIX on a > per thread basis. That means that on return from MPI_Init, the thread that > called MPI_Init can manipulate the adapter to send/recv but other threads > in the process cannot (yet). Yes, this makes sense to me. What I had intended was something I should have looked up first. Following your reference to MPI_IS_MAIN_THREAD, I see the definition is consistent with what I would consider reasonable. Any thread can call MPI_Init or MPI_Init_thread; all subsequent calls must be funneled through that thread if MPI_THREAD_FUNNELED is the level of support. I was mistakenly taken the main thread to refer to the initial thread created by the OS, which would be overly restrictive. So, I withdraw my suggestion. Bronis > If an appplication thread that did not go through MPI_Init tries to do > send/recv we recognize that it is not yet registered and register it on the > fly. We do this because we added thread support before the MPI Forum > defined MPI_INIT_THREAD with MPI_THREAD_FUNNELED. By the time the Forum > defined MPI_INIT_THREAD we were offering MPI_THREAD_MULTIPLE so stuck with > that even when MPI_THREAD_FUNNELED is requested. > > If we had been starting from scratch we might have decided the for > MPI_THREAD_FUNNELED we would not try to do registration on the fly but for > MPI_THREAD_MULTIPLE we would. > > 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 > > > mpi-22-bounces_at_[hidden] wrote on 01/31/2008 12:57:59 PM: > > > > > Jim and Rich: > > > > Then I suggest that fixing this broken semantic decision is > > something that we should consider for MPI 2.2. It should not > > break any existing programs and might even make some existing > > ones standards conforming. > > > > Although I can imagine ways for the MPI implementation to detect > > that the one thread is not the main thread it is not at all clear > > to me how it would matter to the implementation. > > > > Bronis > > > > > > On Thu, 31 Jan 2008, Cownie, James H wrote: > > > > > Because that's how it's always been. We're not adding a restriction > with > > > the change, merely clarifying the existing restriction. > > > > > > -- Jim > > > > > > James Cownie > > > SSG/DPD/PAT > > > Tel: +44 117 9071438 > > > > > > ________________________________ > > > > > > From: mpi-21-bounces_at_[hidden] [mailto:mpi-21-bounces_at_[hidden]] On > > > Behalf Of Richard Graham > > > Sent: 31 January 2008 15:51 > > > To: Mailing list for discussion of MPI 2.1 > > > Subject: Re: [mpi-21] Ballot 4 - MPI_THREAD_FUNNELED - was Re: > > > Attending, topics, etc > > > > > > > > > > > > Why restrict this to a standard specified thread (main thread), why not > > > word it > > > as a singe thread, and let the app decide what thread this is, based > on > > > what > > > ever criteria it wants to use to select this thread ? > > > > > > Rich > > > > > > > > > On 1/31/08 10:27 AM, "Richard Treumann" wrote: > > > > > > How about:: > > > MPI_THREAD_FUNNELED The process may be multi-threaded, but the > > > application > > > must insure that only the main thread makes MPI calls. > > > > > > > > > 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-21-bounces_at_[hidden] wrote on 01/31/2008 09:44:08 AM: > > > > > > > A simpler change which would seem to achieve the desired > clarification > > > > would be :- > > > > > > > > MPI_THREAD_FUNNELED The process may be multi-threaded, but only > the > > > > main > > > > thread is allowed to make MPI calls. > > > > > > > > (and you could add > > > > If other threads make MPI calls the behavior is undefined. > > > > if you want to be verbose about it). > > > > > > > > -- Jim > > > > > > > > James Cownie > > > > SSG/DPD/PAT > > > > Tel: +44 117 9071438 > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: mpi-21-bounces_at_[hidden] > [mailto:mpi-21-bounces_at_[hidden]] > > > > > > > On > > > > > Behalf Of Rolf Rabenseifner > > > > > Sent: 31 January 2008 14:31 > > > > > To: mpi-21_at_[hidden] > > > > > Subject: [mpi-21] Ballot 4 - MPI_THREAD_FUNNELED - was Re: > > > Attending, > > > > > topics, etc > > > > > > > > > > This is a proposal for MPI 2.1, Ballot 4. > > > > > > > > > > I'm asking especially > > > > > Greg Lindahl, > > > > > the participants of the email-discussion in 2007, to review this > > > > proposal. > > > > > > > > > > This is a follow up to: > > > > > Which thread is the funneled thread? > > > > > in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- > > > > > errata/index.html > > > > > with mail discussion in > > > > > http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- > > > > > errata/discuss/funneled/ > > > > > ___________________________________ > > > > > > > > > > Proposal: > > > > > MPI-2.0 Sect. 8.7.3, MPI_Init_thread, page 196, lines 25-26 read: > > > > > > > > > > MPI_THREAD_FUNNELED The process may be multi-threaded, but only > > > > > the main thread will make MPI calls (all MPI calls are "funneled" > > > > > to the main thread). > > > > > > > > > > but should read: > > > > > > > > > > MPI_THREAD_FUNNELED The process may be multi-threaded, but only > > > > > the main thread will make MPI calls (all MPI calls are "funneled" > > > > > to the main thread, e.g., by using the OpenMP directive "master" > > > > > in the application program). > > > > > ___________________________________ > > > > > Rationale for this clarification from the email from Greg Lindahl: > > > > > The existing document doesn't make it clear that > > > > > the MPI user has to funnel the calls to the main thread; > > > > > it's not the job of the MPI library. I have seen multiple > > > > > MPI users confused by this issue, and when I first read > > > > > this section, I was confused by it, too. > > > > > ___________________________________ > > > > > > > > > > > > > > > Best regards > > > > > Rolf > > > > > > > > > > > > > > > > > > > > > > > > > Dr. Rolf Rabenseifner . . . . . . . . . .. email > > > rabenseifner_at_[hidden] > > > > > High Performance Computing Center (HLRS) . phone > > > ++49(0)711/685-65530 > > > > > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / > > > 685-65832 > > > > > Head of Dpmt Parallel Computing . . . > > > www.hlrs.de/people/rabenseifner > > > > > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) > > > > > _______________________________________________ > > > > > mpi-21 mailing list > > > > > mpi-21_at_[hidden] > > > > > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > > > > --------------------------------------------------------------------- > > > > Intel Corporation (UK) Limited > > > > Registered No. 1134945 (England) > > > > Registered Office: Pipers Way, Swindon SN3 1RJ > > > > VAT No: 860 2173 47 > > > > > > > > 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-21 mailing list > > > > mpi-21_at_[hidden] > > > > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > > > > > > ________________________________ > > > > > > _______________________________________________ > > > mpi-21 mailing list > > > mpi-21_at_[hidden] > > > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > > > > > > > > > > > > --------------------------------------------------------------------- > > > Intel Corporation (UK) Limited > > > Registered No. 1134945 (England) > > > Registered Office: Pipers Way, Swindon SN3 1RJ > > > VAT No: 860 2173 47 > > > > > > 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.cs.uiuc.edu/mailman/listinfo/mpi-22