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

Re: [mpi-22] FW: [mpi-21] Proposal: MPI_OFFSET built-in type
by unknown＠example.com 28 Jan '08

28 Jan '08

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 <robl_at_[hidden]> > > Reply-To: "Mailing list for discussion of MPI 2.1" > > <mpi-21_at_[hidden]> > > Date: Thu, 24 Jan 2008 10:41:52 -0600 > > To: <mpi-21_at_[hidden]> > > 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

1 0

Re: [mpi-22] FW: [mpi-21] Proposal: MPI_OFFSET built-in type
by unknown＠example.com 24 Jan '08

24 Jan '08

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" <thakur_at_[hidden]> 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 <robl_at_[hidden]> >>>> Reply-To: "Mailing list for discussion of MPI 2.1" >>>> <mpi-21_at_[hidden]> >>>> Date: Thu, 24 Jan 2008 10:41:52 -0600 >>>> To: <mpi-21_at_[hidden]> >>>> 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

1 0

Re: [mpi-22] FW: [mpi-21] Proposal: MPI_OFFSET built-in type
by unknown＠example.com 24 Jan '08

24 Jan '08

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" <thakur_at_[hidden]> 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 <robl_at_[hidden]> > >> Reply-To: "Mailing list for discussion of MPI 2.1" > >> <mpi-21_at_[hidden]> > >> Date: Thu, 24 Jan 2008 10:41:52 -0600 > >> To: <mpi-21_at_[hidden]> > >> 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 > >

1 0

Re: [mpi-22] FW: [mpi-21] Proposal: MPI_OFFSET built-in type
by unknown＠example.com 24 Jan '08

24 Jan '08

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" <thakur_at_[hidden]> 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 <robl_at_[hidden]> >> Reply-To: "Mailing list for discussion of MPI 2.1" >> <mpi-21_at_[hidden]> >> Date: Thu, 24 Jan 2008 10:41:52 -0600 >> To: <mpi-21_at_[hidden]> >> 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

1 0

Re: [mpi-22] FW: [mpi-21] Proposal: MPI_OFFSET built-in type
by unknown＠example.com 24 Jan '08

24 Jan '08

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 <robl_at_[hidden]> > Reply-To: "Mailing list for discussion of MPI 2.1" > <mpi-21_at_[hidden]> > Date: Thu, 24 Jan 2008 10:41:52 -0600 > To: <mpi-21_at_[hidden]> > 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 > >

1 0

Fwd: Proposal: MPI_OFFSET built-in type
by unknown＠example.com 24 Jan '08

24 Jan '08

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)

1 0

FW: [mpi-21] Proposal: MPI_OFFSET built-in type
by unknown＠example.com 24 Jan '08

24 Jan '08

Moving this to the appropriate list. Rich ------ Forwarded Message From: Robert Latham <robl_at_[hidden]> Reply-To: "Mailing list for discussion of MPI 2.1" <mpi-21_at_[hidden]> Date: Thu, 24 Jan 2008 10:41:52 -0600 To: <mpi-21_at_[hidden]> 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

1 0

Proposal: C++ MPI constructors
by unknown＠example.com 18 Jan '08

18 Jan '08

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/discus… 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

1 0