August 2011 - mpi-forum - mailman3.cels.anl.gov

Re: [Mpi-forum] [MPI3 Fortran] Fwd: Pre-review - New Fortran bindings - Formal reading
by Rolf Rabenseifner 31 Aug '11

31 Aug '11

> Also, the two documents linked below appear to be identical as far as > the I/O chapter goes. Yes, because in this chapter, there is nothing deleted. The changeonly doc does not show deleted text. Therefore it is better readable especially in the Language Binding chapter. Rolf ----- Original Message ----- > From: "Rajeev Thakur" <thakur(a)mcs.anl.gov> > To: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> > Cc: "MPI-3 Fortran working group" <mpi3-fortran(a)lists.mpi-forum.org> > Sent: Tuesday, August 30, 2011 8:25:04 PM > Subject: Re: [MPI3 Fortran] [Mpi-forum] Fwd: Pre-review - New Fortran bindings - Formal reading > I looked through the I/O chapter and didn't notice any obvious errors. > However, I don't understand the new Fortran bindings well enough to > say they are all correct for I/O. I would appreciate it if someone > with a better knowledge of the new bindings also verifies the I/O > chapter. > > Also, the two documents linked below appear to be identical as far as > the I/O chapter goes. > > Rajeev > > > On Aug 27, 2011, at 2:01 AM, Rolf Rabenseifner wrote: > > > Dear chapter authors, Fortran reviewers, and authors of MPI-3 > > tickets, > > > > I sent this also through the Forum list, > > because some of the MPI-3 ticket authors are missing in the > > individual list. > > > > And there may be others with interest on Fortran+MPI. > > > > Best regards > > Rolf > > > > ----- Forwarded Message ----- > > From: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> > > To: "Jeff Squyres" <jsquyres(a)cisco.com>, "Craig E Rasmussen" > > <rasmussn(a)lanl.gov>, "Hubert Ritzdorf" > > <Hubert.Ritzdorf(a)EMEA.NEC.COM>, "Purushotham Bangalore" > > <puri(a)cis.uab.edu>, "Bill Gropp" <wgropp(a)uiuc.edu>, "Reinhold Bader" > > <Reinhold.Bader(a)lrz.de>, "Richard L. Graham" <rlgraham(a)ornl.gov>, > > "George Bosilca" <bosilca(a)eecs.utk.edu>, "Adam Moody" > > <moody20(a)llnl.gov>, "Torsten Hoefler" <htor(a)illinois.edu>, "david > > solt" <david.solt(a)hp.com>, "Rajeev Thakur" <thakur(a)mcs.anl.gov>, > > "Bronis R. de Supinski" <bronis(a)llnl.gov>, "Martin Schulz" > > <schulzm(a)llnl.gov>, "Darius Buntinas" <buntinas(a)mcs.anl.gov> > > Sent: Friday, August 26, 2011 11:49:44 PM > > Subject: Pre-review - New Fortran bindings - Formal reading > > > > Dear chapter authors, Fortran reviewers, and authors of MPI-3 > > tickets > > > > the New Fortran bindings is prepared for reviewing. > > Please, now I need your help for the reviewing process. > > > > https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/229/mpi-repo… > > and > > https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/229/mpi-repo… > > > > > > All these pre-reviews should be done until Aug. 31. > > > > Please print the pages simplex where you make comments, > > scan in and please send the scanned pdf back to me. > > Longer new texts please also be email. > > Please use the changeonlyplustickets.pdf for commenting > > because it is more readable. > > For a precise review, you may also want to look at 'all' > > the deleted texts in the full reviewdoc.pdf > > > > This is only a pre-review, i.e., your wishes can be included > > in the version that will be published 2 weeks before > > Santorini for final reviews reported at Santorini. > > > > Please check you chapter very carefully. > > > > Not finished issues in this version: > > - Callbacks in mpi_f08: > > - The abstract interfaces will be will be BIND(C) > > - We check for abstract interfaces with TYPE(*), DIMENSION(*) > > for the two callbacks with choice-buffers > > - Tools and linker names: > > - we must allow to have duplicate versions for > > with/without TR29113 only for the choice-buffer routines > > - Cray-Pointer on MPI_ALLOC_MEM will be deprecated, > > i.e., overloading is only with mpi module, > > mpi_fo8 will have only the new interface. > > But same interface for MPI_Free_mem for all three methods. > > - String-OUT-arguments with fixed lengths were possible. > > - Example for splitting data to allow overlapping of > > communication and computation without hurting > > the ....affector rules for the ASYNCHRONOUS attribute. > > > > Next steps: > > - You review until Aug.31 > > Please print the pages simplex where you make comments, > > scan in and please send the scanned pdf back to me. > > Longer new texts please also be email. > > - I put in your review results between Sep.1 and Sep.8, > > I work page by page, therefore I need these scanned printouts. > > - Sep.8: Final version for official reading and your final > > reviewing. > > - Sep.21: Your final review should be finished > > - Sep.22-24: you or somebody acting for you will present your > > review in Santorini. > > > > Responsible: > > Special Fortran reviewers: > > "Jeff Squyres" <jsquyres(a)cisco.com>; > > "Craig E Rasmussen" <rasmussn(a)lanl.gov>; > > "Hubert Ritzdorf" <Hubert.Ritzdorf(a)EMEA.NEC.COM>; > > "Purushotham Bangalore" <puri(a)cis.uab.edu>; > > "Bill Gropp" <wgropp(a)uiuc.edu>; > > "Reinhold Bader" <Reinhold.Bader(a)lrz.de> > > Chapter authors from > > http://meetings.mpi-forum.org/mpi3.0_chapter_wgs.php > > - Front matter : Bill Gropp > > - Introduction : Bill Gropp > > - Terms and Definitions : Rolf Rabenseifner > > - Point-to-Point Communication : Richard Graham > > - Datatypes: George Bosilca > > - Collective Communication : Adam Moody, Torsten Hoefler, Yutaka > > Ishikawa, Hideyuki Jitsumoto > > Who is responsible? > > - Process Topologies : Torsten Hoefler > > - Groups, Contexts, and Communicators : Bill Gropp > > - Environmental Management : George Bosilca > > - Info-Object : Darius Buntinas > > - Process Creation and Management : David Solt > > - One-Sided Communications : Bill Gropp + Rajeev Thakur > > - External Interfaces : Bronis R. de Supinski > > - I/O : Rajeev Thakur(c) > > - Profiling interface : Bronis R. de Supinski + Martin Schulz > > - Deprecated Functions : Rolf Rabenseifner > > - Language Bindings : Jeffrey M. Squyres > > - Annex Language Bindings Summary : Rolf Rabenseifner > > - Annex Change-Log : Rolf Rabenseifner > > - Bibliography : Bill Gropp > > > > Please inform me, when somebody else from your chapter group is > > reviewing. > > > > New routines in MPI-3 tickets: > > - The ticket authors should check the routines in > > Appendix B.4 > > > > MPI-3 chair: > > "Richard L. Graham" <rlgraham(a)ornl.gov>; > > > > Best regards > > Rolf > > > > ----- Original Message ----- > >> From: "William Gropp" <wgropp(a)illinois.edu> > >> To: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> > >> Sent: Friday, July 29, 2011 8:42:18 PM > >> Subject: Re: [Mpi-forum] New Fortran bindings - Formal reading > >> In that case, I'd still do this in phases (for such extensive > >> changes): > >> > >> > >> 1) semi-official reading - intended to shake out any issues. > >> 2) review by chapter committees, including working through any > >> changes > >> (which may include such things as adding rationales, as was > >> recommended with the const proposal). > >> 3) the formal reading, done as described below, but with a summary > >> of > >> the chapter committees > >> 4) voting as usual. > >> > >> > >> Bill > >> > >> > >> > >> On Jul 28, 2011, at 12:06 AM, RICHARD GRAHAM wrote: > >> > >> > >> > >> > >> Good point - the issue I have with it, is given that number of > >> changes > >> this has taken over the last several month, and the increasing > >> number > >> of request for consideration coming before the Forum, I would like > >> to > >> keep from asking the chapter committees to review material, until > >> we > >> are rather sure that ideas are acceptable to the forum, and > >> implementation is essentially in the final form. Maybe all that is > >> required here is to use the term "formal reading" in a much more > >> conservative way that we have been doing, and really reserve it for > >> readings of material that has been well vetted with the Forum. > >> > >> Rich > >> > >> > >> > >> From: wgropp(a)illinois.edu > >> To: mpi-forum(a)lists.mpi-forum.org > >> Date: Wed, 27 Jul 2011 06:17:40 +0000 > >> Subject: Re: [Mpi-forum] New Fortran bindings - Formal reading > >> > >> > >> I agree with using a process that doesn't require reading each > >> individual change. However, the chapter authors should also review > >> and agree; if they are not comfortable with Fortran, they need to > >> find > >> someone (not already reading the changes) to whom they can delegate > >> the review. > >> > >> Bill > >> > >> > >> > >> From: mpi-forum-bounces(a)lists.mpi-forum.org [ > >> mpi-forum-bounces(a)lists.mpi-forum.org ] on behalf of Graham, > >> Richard > >> L. [ rlgraham(a)ornl.gov ] > >> Sent: Tuesday, July 26, 2011 5:54 PM > >> To: mpi-forum(a)lists.mpi-forum.org > >> Subject: [Mpi-forum] New Fortran bindings - Formal reading > >> > >> > >> > >> > >> > >> Since the proposed changes to the Fortran bindings are extensive, > >> we > >> would like to propose a different method of handing their formal > >> readings, so that people don’t have to sit through many hours of > >> reading. Please let me know if there are objections to the proposal > >> by August the 5 th if there are objections to this proposal, and > >> you > >> would prefer to have the full forum go through the entire text > >> changes > >> at the meeting. > >> > >> > >> Here is the proposal: > >> Rolf will apply that changes, as required, to the standard, with > >> Jeff and, Craig reviewing the changes. In addition, Hubert and Puri > >> will also review the changes as outside reviewers. A second round > >> of > >> changes and reviews will take place and complete by Sept the 4 th , > >> in > >> time to meet the 2-week time period to post the proposed changes. > >> If > >> others want to participate in the formal review, you are more than > >> welcome – just let either Rolf or me know. At the meeting in > >> addition > >> to the overview describing the changes, the reviewers will report > >> back > >> to the entire forum on their findings. > >> > >> > >> Please send it comments, > >> Rich > >> _______________________________________________ mpi-forum mailing > >> list > >> mpi-forum(a)lists.mpi-forum.org > >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > >> _______________________________________________ > >> mpi-forum mailing list > >> mpi-forum(a)lists.mpi-forum.org > >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > >> > >> > >> > >> > >> > >> William Gropp > >> Director, Parallel Computing Institute > >> Deputy Director for Research > >> Institute for Advanced Computing Applications and Technologies > >> Paul and Cynthia Saylor Professor of Computer Science > >> University of Illinois Urbana-Champaign > >> > >> > >> > >> > >> _______________________________________________ > >> mpi-forum mailing list > >> mpi-forum(a)lists.mpi-forum.org > >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > > > -- > > Dr. Rolf Rabenseifner . . . . . . . . . .. email > > rabenseifner(a)hlrs.de > > 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) > > > > -- > > Dr. Rolf Rabenseifner . . . . . . . . . .. email > > rabenseifner(a)hlrs.de > > 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-forum mailing list > > mpi-forum(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de 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

Re: [Mpi-forum] Fwd: Pre-review - New Fortran bindings - Formal reading
by Rajeev Thakur 30 Aug '11

30 Aug '11

I looked through the I/O chapter and didn't notice any obvious errors. However, I don't understand the new Fortran bindings well enough to say they are all correct for I/O. I would appreciate it if someone with a better knowledge of the new bindings also verifies the I/O chapter. Also, the two documents linked below appear to be identical as far as the I/O chapter goes. Rajeev On Aug 27, 2011, at 2:01 AM, Rolf Rabenseifner wrote: > Dear chapter authors, Fortran reviewers, and authors of MPI-3 tickets, > > I sent this also through the Forum list, > because some of the MPI-3 ticket authors are missing in the > individual list. > > And there may be others with interest on Fortran+MPI. > > Best regards > Rolf > > ----- Forwarded Message ----- > From: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> > To: "Jeff Squyres" <jsquyres(a)cisco.com>, "Craig E Rasmussen" <rasmussn(a)lanl.gov>, "Hubert Ritzdorf" <Hubert.Ritzdorf(a)EMEA.NEC.COM>, "Purushotham Bangalore" <puri(a)cis.uab.edu>, "Bill Gropp" <wgropp(a)uiuc.edu>, "Reinhold Bader" <Reinhold.Bader(a)lrz.de>, "Richard L. Graham" <rlgraham(a)ornl.gov>, "George Bosilca" <bosilca(a)eecs.utk.edu>, "Adam Moody" <moody20(a)llnl.gov>, "Torsten Hoefler" <htor(a)illinois.edu>, "david solt" <david.solt(a)hp.com>, "Rajeev Thakur" <thakur(a)mcs.anl.gov>, "Bronis R. de Supinski" <bronis(a)llnl.gov>, "Martin Schulz" <schulzm(a)llnl.gov>, "Darius Buntinas" <buntinas(a)mcs.anl.gov> > Sent: Friday, August 26, 2011 11:49:44 PM > Subject: Pre-review - New Fortran bindings - Formal reading > > Dear chapter authors, Fortran reviewers, and authors of MPI-3 tickets > > the New Fortran bindings is prepared for reviewing. > Please, now I need your help for the reviewing process. > > https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/229/mpi-repo… > and > https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/229/mpi-repo… > > > All these pre-reviews should be done until Aug. 31. > > Please print the pages simplex where you make comments, > scan in and please send the scanned pdf back to me. > Longer new texts please also be email. > Please use the changeonlyplustickets.pdf for commenting > because it is more readable. > For a precise review, you may also want to look at 'all' > the deleted texts in the full reviewdoc.pdf > > This is only a pre-review, i.e., your wishes can be included > in the version that will be published 2 weeks before > Santorini for final reviews reported at Santorini. > > Please check you chapter very carefully. > > Not finished issues in this version: > - Callbacks in mpi_f08: > - The abstract interfaces will be will be BIND(C) > - We check for abstract interfaces with TYPE(*), DIMENSION(*) > for the two callbacks with choice-buffers > - Tools and linker names: > - we must allow to have duplicate versions for > with/without TR29113 only for the choice-buffer routines > - Cray-Pointer on MPI_ALLOC_MEM will be deprecated, > i.e., overloading is only with mpi module, > mpi_fo8 will have only the new interface. > But same interface for MPI_Free_mem for all three methods. > - String-OUT-arguments with fixed lengths were possible. > - Example for splitting data to allow overlapping of > communication and computation without hurting > the ....affector rules for the ASYNCHRONOUS attribute. > > Next steps: > - You review until Aug.31 > Please print the pages simplex where you make comments, > scan in and please send the scanned pdf back to me. > Longer new texts please also be email. > - I put in your review results between Sep.1 and Sep.8, > I work page by page, therefore I need these scanned printouts. > - Sep.8: Final version for official reading and your final > reviewing. > - Sep.21: Your final review should be finished > - Sep.22-24: you or somebody acting for you will present your > review in Santorini. > > Responsible: > Special Fortran reviewers: > "Jeff Squyres" <jsquyres(a)cisco.com>; > "Craig E Rasmussen" <rasmussn(a)lanl.gov>; > "Hubert Ritzdorf" <Hubert.Ritzdorf(a)EMEA.NEC.COM>; > "Purushotham Bangalore" <puri(a)cis.uab.edu>; > "Bill Gropp" <wgropp(a)uiuc.edu>; > "Reinhold Bader" <Reinhold.Bader(a)lrz.de> > Chapter authors from > http://meetings.mpi-forum.org/mpi3.0_chapter_wgs.php > - Front matter : Bill Gropp > - Introduction : Bill Gropp > - Terms and Definitions : Rolf Rabenseifner > - Point-to-Point Communication : Richard Graham > - Datatypes: George Bosilca > - Collective Communication : Adam Moody, Torsten Hoefler, Yutaka Ishikawa, Hideyuki Jitsumoto > Who is responsible? > - Process Topologies : Torsten Hoefler > - Groups, Contexts, and Communicators : Bill Gropp > - Environmental Management : George Bosilca > - Info-Object : Darius Buntinas > - Process Creation and Management : David Solt > - One-Sided Communications : Bill Gropp + Rajeev Thakur > - External Interfaces : Bronis R. de Supinski > - I/O : Rajeev Thakur(c) > - Profiling interface : Bronis R. de Supinski + Martin Schulz > - Deprecated Functions : Rolf Rabenseifner > - Language Bindings : Jeffrey M. Squyres > - Annex Language Bindings Summary : Rolf Rabenseifner > - Annex Change-Log : Rolf Rabenseifner > - Bibliography : Bill Gropp > > Please inform me, when somebody else from your chapter group is reviewing. > > New routines in MPI-3 tickets: > - The ticket authors should check the routines in > Appendix B.4 > > MPI-3 chair: > "Richard L. Graham" <rlgraham(a)ornl.gov>; > > Best regards > Rolf > > ----- Original Message ----- >> From: "William Gropp" <wgropp(a)illinois.edu> >> To: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> >> Sent: Friday, July 29, 2011 8:42:18 PM >> Subject: Re: [Mpi-forum] New Fortran bindings - Formal reading >> In that case, I'd still do this in phases (for such extensive >> changes): >> >> >> 1) semi-official reading - intended to shake out any issues. >> 2) review by chapter committees, including working through any changes >> (which may include such things as adding rationales, as was >> recommended with the const proposal). >> 3) the formal reading, done as described below, but with a summary of >> the chapter committees >> 4) voting as usual. >> >> >> Bill >> >> >> >> On Jul 28, 2011, at 12:06 AM, RICHARD GRAHAM wrote: >> >> >> >> >> Good point - the issue I have with it, is given that number of changes >> this has taken over the last several month, and the increasing number >> of request for consideration coming before the Forum, I would like to >> keep from asking the chapter committees to review material, until we >> are rather sure that ideas are acceptable to the forum, and >> implementation is essentially in the final form. Maybe all that is >> required here is to use the term "formal reading" in a much more >> conservative way that we have been doing, and really reserve it for >> readings of material that has been well vetted with the Forum. >> >> Rich >> >> >> >> From: wgropp(a)illinois.edu >> To: mpi-forum(a)lists.mpi-forum.org >> Date: Wed, 27 Jul 2011 06:17:40 +0000 >> Subject: Re: [Mpi-forum] New Fortran bindings - Formal reading >> >> >> I agree with using a process that doesn't require reading each >> individual change. However, the chapter authors should also review >> and agree; if they are not comfortable with Fortran, they need to find >> someone (not already reading the changes) to whom they can delegate >> the review. >> >> Bill >> >> >> >> From: mpi-forum-bounces(a)lists.mpi-forum.org [ >> mpi-forum-bounces(a)lists.mpi-forum.org ] on behalf of Graham, Richard >> L. [ rlgraham(a)ornl.gov ] >> Sent: Tuesday, July 26, 2011 5:54 PM >> To: mpi-forum(a)lists.mpi-forum.org >> Subject: [Mpi-forum] New Fortran bindings - Formal reading >> >> >> >> >> >> Since the proposed changes to the Fortran bindings are extensive, we >> would like to propose a different method of handing their formal >> readings, so that people donï¿½t have to sit through many hours of >> reading. Please let me know if there are objections to the proposal >> by August the 5 th if there are objections to this proposal, and you >> would prefer to have the full forum go through the entire text changes >> at the meeting. >> >> >> Here is the proposal: >> Rolf will apply that changes, as required, to the standard, with >> Jeff and, Craig reviewing the changes. In addition, Hubert and Puri >> will also review the changes as outside reviewers. A second round of >> changes and reviews will take place and complete by Sept the 4 th , in >> time to meet the 2-week time period to post the proposed changes. If >> others want to participate in the formal review, you are more than >> welcome ï¿½ just let either Rolf or me know. At the meeting in addition >> to the overview describing the changes, the reviewers will report back >> to the entire forum on their findings. >> >> >> Please send it comments, >> Rich >> _______________________________________________ mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >> >> >> >> >> >> William Gropp >> Director, Parallel Computing Institute >> Deputy Director for Research >> Institute for Advanced Computing Applications and Technologies >> Paul and Cynthia Saylor Professor of Computer Science >> University of Illinois Urbana-Champaign >> >> >> >> >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > -- > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de > 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) > > -- > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de > 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-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

1 0

non-blocking collective I/O ticket
by Mohamad Chaarawi 30 Aug '11

30 Aug '11

Hi all, In that last forum meeting in Chicago, we proposed to add non-blocking collective I/O functions to the standard (ticket #273 https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/273 ), and I'm working on I/O chapter modifications for a first reading at the next MPI Forum. However non from the HDF group are able to attend the next meeting in September. We would like to ask if anybody attending the September meeting, is interested in volunteering to do the first reading. Please met me know if you are and we can coordinate. Thanks, Mohamad

1 0

Santorini meeting
by Graham, Richard L. 30 Aug '11

30 Aug '11

If you are planning to attend, please register ASAP. We need to commit to catering. At this stage virtually no one from the US has registered. Thanks, Rich Sent with Good (www.good.com)

1 0

Re: [Mpi-forum] MPI_Type_create_struct vs. other datatype creation routines
by Pavan Balaji 29 Aug '11

29 Aug '11

On 08/29/2011 01:52 PM, Mohamad Chaarawi wrote: > On 08/29/2011 09:21 AM, Pavan Balaji wrote: >> Great. We have a use case for this as well, and we are essentially >> doing exactly what you are doing. Are you planning to do a formal >> reading for it at the next meeting? > > We would like to, but unfortunately none from the HDF group are able to > attend the forum meeting in September. If you, or anyone to that > matter, would like to do a formal reading for this ticket, please let me > know. Otherwise it will have to wait for the Chicago meeting in October. I'm not going, but it'll be good if someone at least presents this to the Forum in September. I'm sure we can find a volunteer. >> Btw, hindexed is not a real replacement for indexed as the MPI >> implementation can be better optimized for indexed than hindexed >> (e.g., alignment checks). So the right solution would have been to >> allow indexed to take MPI_Aint arguments as well. But given that the >> performance difference would be so small, I'm not sure if we should >> create yet another set of routines for it. > > I'm not really sure what you mean. How can we specify a displacement in > multiples of old type and byte displacements in the same function? I > thought it has to be one or the other. Not in the same function. New functions, of course. For byte displacements, nothing needs to change. For the displacement with respect to multiples of old type, we need something better. -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [Mpi-forum] MPI_Type_create_struct vs. other datatype creation routines
by Pavan Balaji 29 Aug '11

29 Aug '11

Fab and Mohamad, A plan to change all the datatype creation functions to take greater than int size arguments sounds like a good idea. However, the hindexed_block is a simpler and more trivial addition to the standard. So, while both can be pursued, I think they should be separate tickets. -- Pavan On 08/29/2011 02:57 PM, Mohamad Chaarawi wrote: > Hi Fab, > > On 08/29/2011 02:29 PM, Fab Tillier wrote: >> Mohamad Chaarawi wrote on Mon, 29 Aug 2011 at 12:08:49 >> >>> Hi Fab, >>> >>> On 08/29/2011 01:58 PM, Fab Tillier wrote: >>>> Pavan Balaji wrote on Mon, 29 Aug 2011 at 07:21:32 >>>> >>>>> Great. We have a use case for this as well, and we are essentially doing >>>>> exactly what you are doing. Are you planning to do a formal reading for >>>>> it at the next meeting? >>>>> >>>>> Btw, hindexed is not a real replacement for indexed as the MPI >>>>> implementation can be better optimized for indexed than hindexed (e.g., >>>>> alignment checks). So the right solution would have been to allow >>>>> indexed to take MPI_Aint arguments as well. But given that the >>>>> performance difference would be so small, I'm not sure if we should >>>>> create yet another set of routines for it. >>>> IMO, there should be MPI_Count versions of all the datatype constructors, >>>> and the existing ones deprecated. I thought there was some work to that >>>> effect going on. That's not to say I wouldn't want to see hindexed_block in >>>> the standard, I'd just rather it used MPI_Count than MPI_Aint... >>>> >>> I though datatype creation (and several other) functions that use int s >>> for the count should have MPI_Count versions, but the H versions, that >>> use byte displacements, should still use MPI_Aint, because it's not >>> really a count of datatypes, but just an offset into memory. >> Datatypes may represent data on a file, not just in memory. How do you express an offset (byte displacement) in a file, when that offset can be larger than what can be represented by MPI_Aint? > > yea ok.. so you're saying MPI_Count should be able to handle large > counts of oldtype, and large addresses into memory (MPI_Aint) and file > (MPI_Offset). I though MPI_Count was just to handle larger than 32 bit > integer count of "oldtypes". > > Mohamad > >> Cheers, >> -Fab >> >>> Mohamad >>> >>>> -Fab >>>> >>>>> -- Pavan >>>>> On 08/29/2011 07:55 AM, Mohamad Chaarawi wrote: >>>>>> Hi Pavan, >>>>>> >>>>>> actually I created a ticket for that about a month ago, #280 :) >>>>>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/280 >>>>>> >>>>>> we have a usecase were we use hindexed for MPI_Aint displacement, but >>>>>> we really need 1 block length, so we end up passing an array of 1s :( >>>>>> >>>>>> Thanks, >>>>>> Mohamad >>>>>> >>>>>> On 08/27/2011 08:34 PM, Pavan Balaji wrote: >>>>>>> Ok, that makes sense. It would have been good if the ones where >>>>>>> offsets are specified in datatype lengths also took MPI_Aint, to allow >>>>>>> for MPI_BOTTOM. >>>>>>> >>>>>>> Using hindexed instead of indexed would have been OK, except the MPI >>>>>>> implementation can optimize alignment checks for indexed (by >>>>>>> checking only the first element), but can't do that for hindexed. >>>>>>> >>>>>>> Also, are we missing hindexed_block in the standard? >>>>>>> >>>>>>> -- Pavan >>>>>>> On 08/27/2011 10:04 AM, Rajeev Thakur wrote: >>>>>>>> If the displacement is specified in multiples of the extent of >>>>>>>> oldtype, it is defined as int. If the displacement is specified in >>>>>>>> bytes it is defined as Aint. >>>>>>>> >>>>>>>> Rajeev >>>>>>>> >>>>>>>> >>>>>>>> On Aug 27, 2011, at 7:08 AM, William Gropp wrote: >>>>>>>> >>>>>>>>> Look at the Fortran binding - to create Fortran interfaces that >>>>>>>>> used MPI_ADDRESS_KIND, we first had to *have* an MPI_ADDRESS_KIND, >>>>>>>>> which is possible in Fortran 90 and later. MPI-1 could only >>>>>>>>> provide a Fortran 77 binding. >>>>>>>>> >>>>>>>>> Bill >>>>>>>>> >>>>>>>>> On Aug 27, 2011, at 6:03 AM, Pavan Balaji wrote: >>>>>>>>> >>>>>>>>>> No, that can't be right. >>>>>>>>>> >>>>>>>>>> MPI_Type_hindexed was in MPI-1, and it had MPI_Aint for >>>>>>>>>> displacement. >>>>>>>>>> >>>>>>>>>> MPI_Type_indexed on the other hand uses int. >>>>>>>>>> >>>>>>>>>> MPI_Type_struct in MPI-1 also used MPI_Aint. >>>>>>>>>> >>>>>>>>>> MPI_Type_create_indexed_block was added in MPI-2.1 (or 2.2?) and >>>>>>>>>> uses int. >>>>>>>>>> >>>>>>>>>> It all seems arbitrary to me. >>>>>>>>>> >>>>>>>>>> -- Pavan >>>>>>>>>> >>>>>>>>>> On 08/27/2011 05:18 AM, Jeff Squyres wrote: >>>>>>>>>>> An offhand guess: TYPE_CREATE_STRUCT was created in MPI-2, >>>>>>>>>>> whereas the rest were created in MPI-1. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Aug 27, 2011, at 3:54 AM, Pavan Balaji wrote: >>>>>>>>>>> >>>>>>>>>>>> Is there a reason why MPI_Type_create_struct was given the >>>>>>>>>>>> special privilege of using MPI_Aint to store displacements, while >>>>>>>>>>>> the remaining datatype creation routines use int? This would >>>>>>>>>>>> essentially disallow creation of a datatype as an offset to >>>>>>>>>>>> MPI_BOTTOM. >>>>>>>>>>>> >>>>>>>>>>>> -- Pavan >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Pavan Balaji >>>>>>>>>>>> http://www.mcs.anl.gov/~balaji >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> mpi-forum mailing list >>>>>>>>>>>> mpi-forum(a)lists.mpi-forum.org >>>>>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>>>>>>> -- >>>>>>>>>> Pavan Balaji >>>>>>>>>> http://www.mcs.anl.gov/~balaji >>>>>>>>>> _______________________________________________ >>>>>>>>>> mpi-forum mailing list >>>>>>>>>> mpi-forum(a)lists.mpi-forum.org >>>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>>>>>> William Gropp >>>>>>>>> Director, Parallel Computing Institute >>>>>>>>> Deputy Director for Research >>>>>>>>> Institute for Advanced Computing Applications and Technologies >>>>>>>>> Paul and Cynthia Saylor Professor of Computer Science >>>>>>>>> University of Illinois Urbana-Champaign >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> mpi-forum mailing list >>>>>>>>> mpi-forum(a)lists.mpi-forum.org >>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>>>>> _______________________________________________ >>>>>>>> mpi-forum mailing list >>>>>>>> mpi-forum(a)lists.mpi-forum.org >>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>>> _______________________________________________ >>>>>> mpi-forum mailing list >>>>>> mpi-forum(a)lists.mpi-forum.org >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>> _______________________________________________ >>>> mpi-forum mailing list >>>> mpi-forum(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>> _______________________________________________ >>> mpi-forum mailing list >>> mpi-forum(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [Mpi-forum] 2012 tentative meeting agenda
by Graham, Richard L. 29 Aug '11

29 Aug '11

At this stage I do not plan to schedule the meeting over a weekend. In that past when we have done this, attendance has dropped off quite a bit from the week days at the same meeting. Rich On Aug 25, 2011, at 2:31 PM, Rolf Rabenseifner wrote: > About the Sep.-meeting 2012: > > We have only a few statements on date at EuroMPI 2012 > with mainly two alternatives next year 2012: > - MPI-3 Wed-Fri Sep 19-21 + EuroMPI Sun-Thu Sep 23-26 > with free whole Saturday; > - EuroMPI Sun-Thu Sep 23-26 + MPI-3 Fri-Sat Sep 27-29 > (6 day work for those who omit the conference tutorials > with free Fri-morning). > I believe, we should decide this at the next meeting, > with additional votes as reply to this mail from > those who want to come 2012 but cannot come to Santorini. > -------------------------------- > > Date: Aug 24, 2011 > Sept 19-21: In conjunction with EuroMPI > Rich > -------------------------------- > > Darius Buntinas: > I too would prefer September 27-29. > -------------------------------- > > For me, the weekend before is already filled (and the event is > already booked). > I automatically expected the usual rule: > After EuroMPI, Sep.27-29 (3 days) or Sep.27-30 (4days) > Most of us do not attend the EuroMPI tutorials, > therefore with EuroMPI talks + Forum only 3 days, > we have in total a 6 day week which is still okay > and reduces total travel time and costs. > > Rolf > -------------------------------- > > Staying over a weekend without any reason may cause significant costs > for some of us. Why can we not meet during the weekend? I propose > 9/27-9/29 or 9/20-9/22. > > Thanks & All the Best, > Torsten > -------------------------------- > > Bronis R. de Supinski: > I don't see any conflicts yet. I think it is good to get things > finalized ASAP as you suggest. I aslo agree that having fewer > intervening days will work better. So 9/18-21/12 looks best. > -------------------------------- > > Assuming MPI-3 is out before that meeting, do we still need a 4-day mtg? If we make this one 3 days, > we can have it on Thu-Sat after EuroMPI as usual. > > Rajeev > -------------------------------- > > Date: Aug 11, 2011 > To finalize the schedule for 2012, we need to come to a decision on the > date for the MPI Forum meeting in Europe next year. EuroMPI is scheduled > for Sept 23-26, 2012. > There are two possible dates that could go with this (trying to avoid meetings over the weekend) > Sep 18:noon - 21:noon, or Oct 1:noon - 4:noon. > I am inclined to go with the first date, as it leaves one weekend day > between the Forum meeting and EuroMPI, rather than 4 days between the > end of EuroMPI and the MPI Forum. What are people's opinions here ? > > Rich > > > ----- Original Message ----- >> From: "Jeff Squyres" <jsquyres(a)cisco.com> >> To: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> >> Sent: Thursday, August 25, 2011 4:27:05 PM >> Subject: Re: [Mpi-forum] 2012 tentative meeting agenda >> Please let me know when this is final so that I can request meeting >> rooms at Cisco/San Jose ASAP (they fill up far into the future). >> >> >> On Aug 24, 2011, at 12:48 PM, Graham, Richard L. wrote: >> >>> Here is the schedule for MPI Forum meetings in 2012 >>> >>> Jan 9-11: San Jose, CA >>> March 5-7: Chicago, IL >>> May 7-9: San Jose, CA >>> July 16-19: Chicago, IL >>> Sept 19-21: In conjunction with EuroMPI >>> Dec 3-6: San Jose, CA >>> >>> More comments are welcome, but this is what I plan to post in the >>> very near future. >>> >>> Rich >>> >>> >>> _______________________________________________ >>> mpi-forum mailing list >>> mpi-forum(a)lists.mpi-forum.org >>> hxxp://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >> >> >> -- >> Jeff Squyres >> jsquyres(a)cisco.com >> For corporate legal information go to: >> hxxp://www.cisco.com/web/about/doing_business/legal/cri/ >> >> >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> hxxp://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > -- > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de > 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-forum mailing list > mpi-forum(a)lists.mpi-forum.org > hxxp://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >

1 0

Re: [Mpi-forum] MPI_Type_create_struct vs. other datatype creation routines
by Mohamad Chaarawi 29 Aug '11

29 Aug '11

Hi Fab, On 08/29/2011 02:29 PM, Fab Tillier wrote: > Mohamad Chaarawi wrote on Mon, 29 Aug 2011 at 12:08:49 > >> Hi Fab, >> >> On 08/29/2011 01:58 PM, Fab Tillier wrote: >>> Pavan Balaji wrote on Mon, 29 Aug 2011 at 07:21:32 >>> >>>> Great. We have a use case for this as well, and we are essentially doing >>>> exactly what you are doing. Are you planning to do a formal reading for >>>> it at the next meeting? >>>> >>>> Btw, hindexed is not a real replacement for indexed as the MPI >>>> implementation can be better optimized for indexed than hindexed (e.g., >>>> alignment checks). So the right solution would have been to allow >>>> indexed to take MPI_Aint arguments as well. But given that the >>>> performance difference would be so small, I'm not sure if we should >>>> create yet another set of routines for it. >>> IMO, there should be MPI_Count versions of all the datatype constructors, >>> and the existing ones deprecated. I thought there was some work to that >>> effect going on. That's not to say I wouldn't want to see hindexed_block in >>> the standard, I'd just rather it used MPI_Count than MPI_Aint... >>> >> I though datatype creation (and several other) functions that use int s >> for the count should have MPI_Count versions, but the H versions, that >> use byte displacements, should still use MPI_Aint, because it's not >> really a count of datatypes, but just an offset into memory. > Datatypes may represent data on a file, not just in memory. How do you express an offset (byte displacement) in a file, when that offset can be larger than what can be represented by MPI_Aint? yea ok.. so you're saying MPI_Count should be able to handle large counts of oldtype, and large addresses into memory (MPI_Aint) and file (MPI_Offset). I though MPI_Count was just to handle larger than 32 bit integer count of "oldtypes". Mohamad > Cheers, > -Fab > >> Mohamad >> >>> -Fab >>> >>>> -- Pavan >>>> On 08/29/2011 07:55 AM, Mohamad Chaarawi wrote: >>>>> Hi Pavan, >>>>> >>>>> actually I created a ticket for that about a month ago, #280 :) >>>>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/280 >>>>> >>>>> we have a usecase were we use hindexed for MPI_Aint displacement, but >>>>> we really need 1 block length, so we end up passing an array of 1s :( >>>>> >>>>> Thanks, >>>>> Mohamad >>>>> >>>>> On 08/27/2011 08:34 PM, Pavan Balaji wrote: >>>>>> Ok, that makes sense. It would have been good if the ones where >>>>>> offsets are specified in datatype lengths also took MPI_Aint, to allow >>>>>> for MPI_BOTTOM. >>>>>> >>>>>> Using hindexed instead of indexed would have been OK, except the MPI >>>>>> implementation can optimize alignment checks for indexed (by >>>>>> checking only the first element), but can't do that for hindexed. >>>>>> >>>>>> Also, are we missing hindexed_block in the standard? >>>>>> >>>>>> -- Pavan >>>>>> On 08/27/2011 10:04 AM, Rajeev Thakur wrote: >>>>>>> If the displacement is specified in multiples of the extent of >>>>>>> oldtype, it is defined as int. If the displacement is specified in >>>>>>> bytes it is defined as Aint. >>>>>>> >>>>>>> Rajeev >>>>>>> >>>>>>> >>>>>>> On Aug 27, 2011, at 7:08 AM, William Gropp wrote: >>>>>>> >>>>>>>> Look at the Fortran binding - to create Fortran interfaces that >>>>>>>> used MPI_ADDRESS_KIND, we first had to *have* an MPI_ADDRESS_KIND, >>>>>>>> which is possible in Fortran 90 and later. MPI-1 could only >>>>>>>> provide a Fortran 77 binding. >>>>>>>> >>>>>>>> Bill >>>>>>>> >>>>>>>> On Aug 27, 2011, at 6:03 AM, Pavan Balaji wrote: >>>>>>>> >>>>>>>>> No, that can't be right. >>>>>>>>> >>>>>>>>> MPI_Type_hindexed was in MPI-1, and it had MPI_Aint for >>>>>>>>> displacement. >>>>>>>>> >>>>>>>>> MPI_Type_indexed on the other hand uses int. >>>>>>>>> >>>>>>>>> MPI_Type_struct in MPI-1 also used MPI_Aint. >>>>>>>>> >>>>>>>>> MPI_Type_create_indexed_block was added in MPI-2.1 (or 2.2?) and >>>>>>>>> uses int. >>>>>>>>> >>>>>>>>> It all seems arbitrary to me. >>>>>>>>> >>>>>>>>> -- Pavan >>>>>>>>> >>>>>>>>> On 08/27/2011 05:18 AM, Jeff Squyres wrote: >>>>>>>>>> An offhand guess: TYPE_CREATE_STRUCT was created in MPI-2, >>>>>>>>>> whereas the rest were created in MPI-1. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Aug 27, 2011, at 3:54 AM, Pavan Balaji wrote: >>>>>>>>>> >>>>>>>>>>> Is there a reason why MPI_Type_create_struct was given the >>>>>>>>>>> special privilege of using MPI_Aint to store displacements, while >>>>>>>>>>> the remaining datatype creation routines use int? This would >>>>>>>>>>> essentially disallow creation of a datatype as an offset to >>>>>>>>>>> MPI_BOTTOM. >>>>>>>>>>> >>>>>>>>>>> -- Pavan >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Pavan Balaji >>>>>>>>>>> http://www.mcs.anl.gov/~balaji >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> mpi-forum mailing list >>>>>>>>>>> mpi-forum(a)lists.mpi-forum.org >>>>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>>>>>> -- >>>>>>>>> Pavan Balaji >>>>>>>>> http://www.mcs.anl.gov/~balaji >>>>>>>>> _______________________________________________ >>>>>>>>> mpi-forum mailing list >>>>>>>>> mpi-forum(a)lists.mpi-forum.org >>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>>>>> William Gropp >>>>>>>> Director, Parallel Computing Institute >>>>>>>> Deputy Director for Research >>>>>>>> Institute for Advanced Computing Applications and Technologies >>>>>>>> Paul and Cynthia Saylor Professor of Computer Science >>>>>>>> University of Illinois Urbana-Champaign >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> mpi-forum mailing list >>>>>>>> mpi-forum(a)lists.mpi-forum.org >>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>>>> _______________________________________________ >>>>>>> mpi-forum mailing list >>>>>>> mpi-forum(a)lists.mpi-forum.org >>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>> _______________________________________________ >>>>> mpi-forum mailing list >>>>> mpi-forum(a)lists.mpi-forum.org >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>> _______________________________________________ >>> mpi-forum mailing list >>> mpi-forum(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

1 0

Re: [Mpi-forum] MPI_Type_create_struct vs. other datatype creation routines
by Fab Tillier 29 Aug '11

29 Aug '11

Mohamad Chaarawi wrote on Mon, 29 Aug 2011 at 12:08:49 > Hi Fab, > > On 08/29/2011 01:58 PM, Fab Tillier wrote: >> Pavan Balaji wrote on Mon, 29 Aug 2011 at 07:21:32 >> >>> Great. We have a use case for this as well, and we are essentially doing >>> exactly what you are doing. Are you planning to do a formal reading for >>> it at the next meeting? >>> >>> Btw, hindexed is not a real replacement for indexed as the MPI >>> implementation can be better optimized for indexed than hindexed (e.g., >>> alignment checks). So the right solution would have been to allow >>> indexed to take MPI_Aint arguments as well. But given that the >>> performance difference would be so small, I'm not sure if we should >>> create yet another set of routines for it. >> IMO, there should be MPI_Count versions of all the datatype constructors, >> and the existing ones deprecated. I thought there was some work to that >> effect going on. That's not to say I wouldn't want to see hindexed_block in >> the standard, I'd just rather it used MPI_Count than MPI_Aint... >> > > I though datatype creation (and several other) functions that use int s > for the count should have MPI_Count versions, but the H versions, that > use byte displacements, should still use MPI_Aint, because it's not > really a count of datatypes, but just an offset into memory. Datatypes may represent data on a file, not just in memory. How do you express an offset (byte displacement) in a file, when that offset can be larger than what can be represented by MPI_Aint? Cheers, -Fab > > Mohamad > >> -Fab >> >>> -- Pavan >>> On 08/29/2011 07:55 AM, Mohamad Chaarawi wrote: >>>> Hi Pavan, >>>> >>>> actually I created a ticket for that about a month ago, #280 :) >>>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/280 >>>> >>>> we have a usecase were we use hindexed for MPI_Aint displacement, but >>>> we really need 1 block length, so we end up passing an array of 1s :( >>>> >>>> Thanks, >>>> Mohamad >>>> >>>> On 08/27/2011 08:34 PM, Pavan Balaji wrote: >>>>> Ok, that makes sense. It would have been good if the ones where >>>>> offsets are specified in datatype lengths also took MPI_Aint, to allow >>>>> for MPI_BOTTOM. >>>>> >>>>> Using hindexed instead of indexed would have been OK, except the MPI >>>>> implementation can optimize alignment checks for indexed (by >>>>> checking only the first element), but can't do that for hindexed. >>>>> >>>>> Also, are we missing hindexed_block in the standard? >>>>> >>>>> -- Pavan >>>>> On 08/27/2011 10:04 AM, Rajeev Thakur wrote: >>>>>> If the displacement is specified in multiples of the extent of >>>>>> oldtype, it is defined as int. If the displacement is specified in >>>>>> bytes it is defined as Aint. >>>>>> >>>>>> Rajeev >>>>>> >>>>>> >>>>>> On Aug 27, 2011, at 7:08 AM, William Gropp wrote: >>>>>> >>>>>>> Look at the Fortran binding - to create Fortran interfaces that >>>>>>> used MPI_ADDRESS_KIND, we first had to *have* an MPI_ADDRESS_KIND, >>>>>>> which is possible in Fortran 90 and later. MPI-1 could only >>>>>>> provide a Fortran 77 binding. >>>>>>> >>>>>>> Bill >>>>>>> >>>>>>> On Aug 27, 2011, at 6:03 AM, Pavan Balaji wrote: >>>>>>> >>>>>>>> No, that can't be right. >>>>>>>> >>>>>>>> MPI_Type_hindexed was in MPI-1, and it had MPI_Aint for >>>>>>>> displacement. >>>>>>>> >>>>>>>> MPI_Type_indexed on the other hand uses int. >>>>>>>> >>>>>>>> MPI_Type_struct in MPI-1 also used MPI_Aint. >>>>>>>> >>>>>>>> MPI_Type_create_indexed_block was added in MPI-2.1 (or 2.2?) and >>>>>>>> uses int. >>>>>>>> >>>>>>>> It all seems arbitrary to me. >>>>>>>> >>>>>>>> -- Pavan >>>>>>>> >>>>>>>> On 08/27/2011 05:18 AM, Jeff Squyres wrote: >>>>>>>>> An offhand guess: TYPE_CREATE_STRUCT was created in MPI-2, >>>>>>>>> whereas the rest were created in MPI-1. >>>>>>>>> >>>>>>>>> >>>>>>>>> On Aug 27, 2011, at 3:54 AM, Pavan Balaji wrote: >>>>>>>>> >>>>>>>>>> Is there a reason why MPI_Type_create_struct was given the >>>>>>>>>> special privilege of using MPI_Aint to store displacements, while >>>>>>>>>> the remaining datatype creation routines use int? This would >>>>>>>>>> essentially disallow creation of a datatype as an offset to >>>>>>>>>> MPI_BOTTOM. >>>>>>>>>> >>>>>>>>>> -- Pavan >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Pavan Balaji >>>>>>>>>> http://www.mcs.anl.gov/~balaji >>>>>>>>>> _______________________________________________ >>>>>>>>>> mpi-forum mailing list >>>>>>>>>> mpi-forum(a)lists.mpi-forum.org >>>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>>>>>> >>>>>>>> -- >>>>>>>> Pavan Balaji >>>>>>>> http://www.mcs.anl.gov/~balaji >>>>>>>> _______________________________________________ >>>>>>>> mpi-forum mailing list >>>>>>>> mpi-forum(a)lists.mpi-forum.org >>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>>>> William Gropp >>>>>>> Director, Parallel Computing Institute >>>>>>> Deputy Director for Research >>>>>>> Institute for Advanced Computing Applications and Technologies >>>>>>> Paul and Cynthia Saylor Professor of Computer Science >>>>>>> University of Illinois Urbana-Champaign >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> mpi-forum mailing list >>>>>>> mpi-forum(a)lists.mpi-forum.org >>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>>> >>>>>> _______________________________________________ >>>>>> mpi-forum mailing list >>>>>> mpi-forum(a)lists.mpi-forum.org >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>> _______________________________________________ >>>> mpi-forum mailing list >>>> mpi-forum(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

1 0

Re: [Mpi-forum] MPI_Type_create_struct vs. other datatype creation routines
by Mohamad Chaarawi 29 Aug '11

29 Aug '11

Hi Fab, On 08/29/2011 01:58 PM, Fab Tillier wrote: > Pavan Balaji wrote on Mon, 29 Aug 2011 at 07:21:32 > >> Great. We have a use case for this as well, and we are essentially doing >> exactly what you are doing. Are you planning to do a formal reading for >> it at the next meeting? >> >> Btw, hindexed is not a real replacement for indexed as the MPI >> implementation can be better optimized for indexed than hindexed (e.g., >> alignment checks). So the right solution would have been to allow >> indexed to take MPI_Aint arguments as well. But given that the >> performance difference would be so small, I'm not sure if we should >> create yet another set of routines for it. > IMO, there should be MPI_Count versions of all the datatype constructors, and the existing ones deprecated. I thought there was some work to that effect going on. That's not to say I wouldn't want to see hindexed_block in the standard, I'd just rather it used MPI_Count than MPI_Aint... > I though datatype creation (and several other) functions that use int s for the count should have MPI_Count versions, but the H versions, that use byte displacements, should still use MPI_Aint, because it's not really a count of datatypes, but just an offset into memory. Mohamad > -Fab > >> -- Pavan >> On 08/29/2011 07:55 AM, Mohamad Chaarawi wrote: >>> Hi Pavan, >>> >>> actually I created a ticket for that about a month ago, #280 :) >>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/280 >>> >>> we have a usecase were we use hindexed for MPI_Aint displacement, but >>> we really need 1 block length, so we end up passing an array of 1s :( >>> >>> Thanks, >>> Mohamad >>> >>> On 08/27/2011 08:34 PM, Pavan Balaji wrote: >>>> Ok, that makes sense. It would have been good if the ones where >>>> offsets are specified in datatype lengths also took MPI_Aint, to allow >>>> for MPI_BOTTOM. >>>> >>>> Using hindexed instead of indexed would have been OK, except the MPI >>>> implementation can optimize alignment checks for indexed (by checking >>>> only the first element), but can't do that for hindexed. >>>> >>>> Also, are we missing hindexed_block in the standard? >>>> >>>> -- Pavan >>>> On 08/27/2011 10:04 AM, Rajeev Thakur wrote: >>>>> If the displacement is specified in multiples of the extent of >>>>> oldtype, it is defined as int. If the displacement is specified in >>>>> bytes it is defined as Aint. >>>>> >>>>> Rajeev >>>>> >>>>> >>>>> On Aug 27, 2011, at 7:08 AM, William Gropp wrote: >>>>> >>>>>> Look at the Fortran binding - to create Fortran interfaces that used >>>>>> MPI_ADDRESS_KIND, we first had to *have* an MPI_ADDRESS_KIND, which >>>>>> is possible in Fortran 90 and later. MPI-1 could only provide a >>>>>> Fortran 77 binding. >>>>>> >>>>>> Bill >>>>>> >>>>>> On Aug 27, 2011, at 6:03 AM, Pavan Balaji wrote: >>>>>> >>>>>>> No, that can't be right. >>>>>>> >>>>>>> MPI_Type_hindexed was in MPI-1, and it had MPI_Aint for >>>>>>> displacement. >>>>>>> >>>>>>> MPI_Type_indexed on the other hand uses int. >>>>>>> >>>>>>> MPI_Type_struct in MPI-1 also used MPI_Aint. >>>>>>> >>>>>>> MPI_Type_create_indexed_block was added in MPI-2.1 (or 2.2?) and >>>>>>> uses int. >>>>>>> >>>>>>> It all seems arbitrary to me. >>>>>>> >>>>>>> -- Pavan >>>>>>> >>>>>>> On 08/27/2011 05:18 AM, Jeff Squyres wrote: >>>>>>>> An offhand guess: TYPE_CREATE_STRUCT was created in MPI-2, whereas >>>>>>>> the rest were created in MPI-1. >>>>>>>> >>>>>>>> >>>>>>>> On Aug 27, 2011, at 3:54 AM, Pavan Balaji wrote: >>>>>>>> >>>>>>>>> Is there a reason why MPI_Type_create_struct was given the >>>>>>>>> special privilege of using MPI_Aint to store displacements, while >>>>>>>>> the remaining datatype creation routines use int? This would >>>>>>>>> essentially disallow creation of a datatype as an offset to >>>>>>>>> MPI_BOTTOM. >>>>>>>>> >>>>>>>>> -- Pavan >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Pavan Balaji >>>>>>>>> http://www.mcs.anl.gov/~balaji >>>>>>>>> _______________________________________________ >>>>>>>>> mpi-forum mailing list >>>>>>>>> mpi-forum(a)lists.mpi-forum.org >>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>>>>> >>>>>>> -- >>>>>>> Pavan Balaji >>>>>>> http://www.mcs.anl.gov/~balaji >>>>>>> _______________________________________________ >>>>>>> mpi-forum mailing list >>>>>>> mpi-forum(a)lists.mpi-forum.org >>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>>> William Gropp >>>>>> Director, Parallel Computing Institute >>>>>> Deputy Director for Research >>>>>> Institute for Advanced Computing Applications and Technologies >>>>>> Paul and Cynthia Saylor Professor of Computer Science >>>>>> University of Illinois Urbana-Champaign >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> mpi-forum mailing list >>>>>> mpi-forum(a)lists.mpi-forum.org >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>> >>>>> _______________________________________________ >>>>> mpi-forum mailing list >>>>> mpi-forum(a)lists.mpi-forum.org >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>> _______________________________________________ >>> mpi-forum mailing list >>> mpi-forum(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

1 0