October 2011 - mpiwg-fortran - mailman3.cels.anl.gov

Re: [MPI3 Fortran] [Mpi-forum] Formal Reading of the new Fortran bindings in Chicago, Oct. 24, 2011, Ticket #229
by George Bosilca 25 Oct '11

25 Oct '11

On Oct 25, 2011, at 06:31 , Rolf Rabenseifner wrote: > Hi George, > > Thanks for your detailed reviuew. > I provide answers and further inquiries about your review, see below. > > ----- Original Message ----- >> From: "George Bosilca" <bosilca(a)eecs.utk.edu> >> To: "William Gropp" <wgropp(a)illinois.edu> >> Cc: "Jeff Squyres" <jsquyres(a)cisco.com>, "Bill Gropp" <wgropp(a)uiuc.edu>, "Brian Barrett" <bwbarre(a)sandia.gov>, >> "Torsten Hoefler" <htor(a)illinois.edu>, "Rolf Rabenseifner" <rabenseifner(a)hlrs.de>, "Craig E Rasmussen" >> <rasmussn(a)lanl.gov> >> Sent: Monday, October 24, 2011 5:32:58 PM >> Subject: Re: [Mpi-forum] Formal Reading of the new Fortran bindings in Chicago, Oct. 24, 2011, Ticket #229 >> I have some remarks. >> >> ============================== >> - mpi-report-F2008-2011-09-08-changeonlyplustickets.pdf p36:40-42 >> (=MPI-2.2 p34:3-5) readï¿½ >> >> There is no mention on the probe/iprobe about the possibility of >> passing MPI_STATUS_IGNORE as an argument. I can understand that if the >> probe is fully named (source and tag), in some cases the status >> argument is superfluous, one only need the flag. However, as this is >> not clearly stated on the probe/iprobe I would not consider adding it >> to p36 a viable option. Moreover, there is __no__ way to link >> MPI_STATUSES_IGNORE with probe/iprobe. > > https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/229/MPI-Fort… > lines 22-83 is doing all needed changes. > > Okay? OK. >> ============================== >> Section 3.6 Buffer Allocation and Usage (MPI_BUFFER_ATTACH), >> INTENT(IN) is added because the routine does not modify the content of >> the buffer: >> >> The role of this function is to provide a playground for the MPI >> library to handle buffered operations. Why do we have to restrict how >> the MPI implementation is handling this memory (by adding the >> INTENT(IN)) ? > > Your question is related to > https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/229/MPI-Fort… > line 97 (as part of lines 84-115). > > This question is independent of the rest of 84-115. > Yes, we can freely decide. > The INTENT(IN) is based on the rules of how much length > can be used of such a buffer. With zero content it is zero. > Therefore it would be erroneous, if the MPI library writes anything into > this buffer. > Therefore INTENT(IN) should be technically okay. > > Are there known MPI libraries that fill something into the buf > as side-effect of MPI_BUFFER_ATTACH? > > How should we proceed with this question? Removing the INTENT(IN) is fine. Thanks. > ============================== >> In general I'm totally confused about the usage of >> INTENT(IN)/INTENT(OUT) through the document. In the changed proposed >> you remove INTENT(OUT) from the status argument on the MPI_Probe and >> friends, because they might not modify the output buffer. Then why do >> you add it to the MPI_Buffer_detach? Do the MPI library have to modify >> the entire buffer to qualify as a correct implementation? > > Your question is related to > https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/229/MPI-Fort… > - line 41, 60, and 69 (as part of lines 22-83) about the probe variants, > - line 130 (as part of lines 116-218) about MPI_BUFFER_DETACH. > > In MPI_BUFFER_DETACH, the buf is an OUT argument! > Many people missed this, at least the members of the MPI Forum > when defining the wrong Fortran binding! > > mpi_f08 will have the first time a correct Fortran binding, > i.e., correct in the sense that it implements the language > independent routine definition. > > About MPI_PROBE and others: > We decided in Santorini that we want to allow MPI_STATUS_IGNORE > (lines 41 and 60), and therefore the INTENT(OUT) must be removed (line 69). > > > Is it now okay with these explanations? As the output of the MPI_BUFFER_DETACH is not an array but a pointer to an array, the buffer argument should be marked as OUT. You're right. > ============================== >> Regarding Hubert question, I agree with him. Simply contiguous is not >> defined in the document, so I don't see how you expect the users to >> magically understand the subtle difference between contiguous and >> simply contiguous? Moreover on the paragraph where "simply contiguous" >> appears for the first time (copied below), I think MPI-2.2 is used >> instead of MPI-3.0. >> >>> Advice to users. For an MPI implementation that fully supports >>> nonblocking calls with the ASYNCHRONOUS attribute for choice >>> buffers, an existing MPI-2.2 application may fail to compile even if >>> it compiled and executed with expected results with an MPI-2.2 >>> implementation. One reason may be that the application uses >>> contiguous but not simply contiguous ASYNCHRONOUS arrays as actual >>> arguments for choice buffers of nonblocking routines, > > Your question is related to > https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/229/mpi-repo… > page 554, lines 33-47. > > "Simply contiguous" is a term defined by the Fortran standard. > This means, that we are not allowed to redefine it. > Therefore I added to examples to show the two main cases where > this causes a problem. > > I propose to add > "See Section 16.2.12 on page 576 for more details." > At the end of this advice to users. > > Okay? Sounds good. > ============================== >> While looking at thee changes I read the following statement. I had to >> go over twice to understand what exactly the meaning was, but I still >> consider it as very unclear. How this get into the standard? Page 31, >> lines 11-16. >> >>> In the case of a message shorter than the receive buffer, MPI is >>> quite strict in that it allows no modification of the other >>> locations. A more lenient statement would allow for some >>> optimizations but this is not allowed. The implementation must be >>> ready to end a copy into the receiver memory exactly at the end of >>> the receive buffer, even if it is an odd address. > > This is MPI-2.2 page 31 lines 11-16! > This has nothing to do with this Fortran ticket #229. > > Therefore no need to do anything in #229 about your question. Sorry. > > Okay? OK. Regards, george. > > > ================================= >> Thanks, >> george. > > Tanks and best regards > Rolf > > -- > 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: [MPI3 Fortran] [Mpi-forum] Formal Reading of the new Fortran bindings in Chicago, Oct. 24, 2011, Ticket #229
by Bill Long 25 Oct '11

25 Oct '11

On 10/25/11 11:18 AM, George Bosilca wrote: > > On Oct 25, 2011, at 06:31 , Rolf Rabenseifner wrote: > >> ============================== >>> In general I'm totally confused about the usage of >>> INTENT(IN)/INTENT(OUT) through the document. In the changed proposed >>> you remove INTENT(OUT) from the status argument on the MPI_Probe and >>> friends, because they might not modify the output buffer. Then why do >>> you add it to the MPI_Buffer_detach? Do the MPI library have to modify >>> the entire buffer to qualify as a correct implementation? >> >> Your question is related to >> https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/229/MPI-Fort… >> - line 41, 60, and 69 (as part of lines 22-83) about the probe variants, >> - line 130 (as part of lines 116-218) about MPI_BUFFER_DETACH. >> >> In MPI_BUFFER_DETACH, the buf is an OUT argument! > > Last time we talked about this you said INTENT(OUT) should only be used if the entire buffer is modified by the call. There is no guarantee that the entire attached buffer will be written by the MPI library (it will depends on the application anyway). Thus, to insure F08 correctness, a valid MPI library will have to overwrite the attached buffer on MPI_BUFFER_DETACH. > Might be going a bit too far. INTENT(OUT) causes the dummy argument to become undefined on entry to the subprogram (and deallocated if is is allocatable). However, there is no mandate that (all of) the argument be defined - you are just not allowed to reference the undefined parts. Cheers, Bill -- Bill Long longb(a)cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101

1 0

Re: [MPI3 Fortran] [Mpi-forum] Formal Reading of the new Fortran bindings in Chicago, Oct. 24, 2011, Ticket #229
by George Bosilca 25 Oct '11

25 Oct '11

On Oct 25, 2011, at 06:31 , Rolf Rabenseifner wrote: > Hi George, > > Thanks for your detailed reviuew. > I provide answers and further inquiries about your review, see below. > > ----- Original Message ----- >> From: "George Bosilca" <bosilca(a)eecs.utk.edu> >> To: "William Gropp" <wgropp(a)illinois.edu> >> Cc: "Jeff Squyres" <jsquyres(a)cisco.com>, "Bill Gropp" <wgropp(a)uiuc.edu>, "Brian Barrett" <bwbarre(a)sandia.gov>, >> "Torsten Hoefler" <htor(a)illinois.edu>, "Rolf Rabenseifner" <rabenseifner(a)hlrs.de>, "Craig E Rasmussen" >> <rasmussn(a)lanl.gov> >> Sent: Monday, October 24, 2011 5:32:58 PM >> Subject: Re: [Mpi-forum] Formal Reading of the new Fortran bindings in Chicago, Oct. 24, 2011, Ticket #229 >> I have some remarks. >> >> ============================== >> - mpi-report-F2008-2011-09-08-changeonlyplustickets.pdf p36:40-42 >> (=MPI-2.2 p34:3-5) readï¿½ >> >> There is no mention on the probe/iprobe about the possibility of >> passing MPI_STATUS_IGNORE as an argument. I can understand that if the >> probe is fully named (source and tag), in some cases the status >> argument is superfluous, one only need the flag. However, as this is >> not clearly stated on the probe/iprobe I would not consider adding it >> to p36 a viable option. Moreover, there is __no__ way to link >> MPI_STATUSES_IGNORE with probe/iprobe. > > https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/229/MPI-Fort… > lines 22-83 is doing all needed changes. > > Okay? No, it's not addressing the issue I raised. MPI_Probe and MPI_Iprobe don't mention that MPI_STATUS_IGNORE is a valid value to be passed on. Second, the way your sentence read it indicates that MPI_STATUSES_IGNORE is a valid value for probe, which is not. >> ============================== >> Section 3.6 Buffer Allocation and Usage (MPI_BUFFER_ATTACH), >> INTENT(IN) is added because the routine does not modify the content of >> the buffer: >> >> The role of this function is to provide a playground for the MPI >> library to handle buffered operations. Why do we have to restrict how >> the MPI implementation is handling this memory (by adding the >> INTENT(IN)) ? > > Your question is related to > https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/229/MPI-Fort… > line 97 (as part of lines 84-115). > > This question is independent of the rest of 84-115. > Yes, we can freely decide. > The INTENT(IN) is based on the rules of how much length > can be used of such a buffer. With zero content it is zero. > Therefore it would be erroneous, if the MPI library writes anything into > this buffer. With a zero length I hope the MPI library complains. What's the point of providing a zero length buffer there? > Therefore INTENT(IN) should be technically okay. > > Are there known MPI libraries that fill something into the buf > as side-effect of MPI_BUFFER_ATTACH? The purpose of this function is to give away this "simply contiguous" memory to the MPI library. Without any strings attached. > How should we proceed with this question? Remove the INTENT(IN) seems like the right approach. > ============================== >> In general I'm totally confused about the usage of >> INTENT(IN)/INTENT(OUT) through the document. In the changed proposed >> you remove INTENT(OUT) from the status argument on the MPI_Probe and >> friends, because they might not modify the output buffer. Then why do >> you add it to the MPI_Buffer_detach? Do the MPI library have to modify >> the entire buffer to qualify as a correct implementation? > > Your question is related to > https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/229/MPI-Fort… > - line 41, 60, and 69 (as part of lines 22-83) about the probe variants, > - line 130 (as part of lines 116-218) about MPI_BUFFER_DETACH. > > In MPI_BUFFER_DETACH, the buf is an OUT argument! Last time we talked about this you said INTENT(OUT) should only be used if the entire buffer is modified by the call. There is no guarantee that the entire attached buffer will be written by the MPI library (it will depends on the application anyway). Thus, to insure F08 correctness, a valid MPI library will have to overwrite the attached buffer on MPI_BUFFER_DETACH. > Many people missed this, at least the members of the MPI Forum > when defining the wrong Fortran binding! > > mpi_f08 will have the first time a correct Fortran binding, > i.e., correct in the sense that it implements the language > independent routine definition. > > About MPI_PROBE and others: > We decided in Santorini that we want to allow MPI_STATUS_IGNORE > (lines 41 and 60), and therefore the INTENT(OUT) must be removed (line 69). Then similar wording should be added to the C part of the MPI_Probe/MPI_Iprobe. > Is it now okay with these explanations? > > >> ============================== >> Regarding Hubert question, I agree with him. Simply contiguous is not >> defined in the document, so I don't see how you expect the users to >> magically understand the subtle difference between contiguous and >> simply contiguous? Moreover on the paragraph where "simply contiguous" >> appears for the first time (copied below), I think MPI-2.2 is used >> instead of MPI-3.0. >> >>> Advice to users. For an MPI implementation that fully supports >>> nonblocking calls with the ASYNCHRONOUS attribute for choice >>> buffers, an existing MPI-2.2 application may fail to compile even if >>> it compiled and executed with expected results with an MPI-2.2 >>> implementation. One reason may be that the application uses >>> contiguous but not simply contiguous ASYNCHRONOUS arrays as actual >>> arguments for choice buffers of nonblocking routines, > > Your question is related to > https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/229/mpi-repo… > page 554, lines 33-47. > > "Simply contiguous" is a term defined by the Fortran standard. We should not mandate the reading of the Fortran standard in order to understand the MPI standard. If we use a term to depict MPI requirements, this term has to be defined, even if it's a citation from the Fortran standard. > This means, that we are not allowed to redefine it. > Therefore I added to examples to show the two main cases where > this causes a problem. > > I propose to add > "See Section 16.2.12 on page 576 for more details." > At the end of this advice to users. > > Okay? > > >> ============================== >> While looking at thee changes I read the following statement. I had to >> go over twice to understand what exactly the meaning was, but I still >> consider it as very unclear. How this get into the standard? Page 31, >> lines 11-16. >> >>> In the case of a message shorter than the receive buffer, MPI is >>> quite strict in that it allows no modification of the other >>> locations. A more lenient statement would allow for some >>> optimizations but this is not allowed. The implementation must be >>> ready to end a copy into the receiver memory exactly at the end of >>> the receive buffer, even if it is an odd address. > > This is MPI-2.2 page 31 lines 11-16! > This has nothing to do with this Fortran ticket #229. No it doesn't ï¿½ george. > > Therefore no need to do anything in #229 about your question. Sorry. > > Okay? > > > ================================= >> Thanks, >> george. > > Tanks and best regards > Rolf > > -- > 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: [MPI3 Fortran] [Mpi-forum] Formal Reading of the new Fortran bindings in Chicago, Oct. 24, 2011, Ticket #229
by Rolf Rabenseifner 25 Oct '11

25 Oct '11

Hi George, Thanks for your detailed reviuew. I provide answers and further inquiries about your review, see below. ----- Original Message ----- > From: "George Bosilca" <bosilca(a)eecs.utk.edu> > To: "William Gropp" <wgropp(a)illinois.edu> > Cc: "Jeff Squyres" <jsquyres(a)cisco.com>, "Bill Gropp" <wgropp(a)uiuc.edu>, "Brian Barrett" <bwbarre(a)sandia.gov>, > "Torsten Hoefler" <htor(a)illinois.edu>, "Rolf Rabenseifner" <rabenseifner(a)hlrs.de>, "Craig E Rasmussen" > <rasmussn(a)lanl.gov> > Sent: Monday, October 24, 2011 5:32:58 PM > Subject: Re: [Mpi-forum] Formal Reading of the new Fortran bindings in Chicago, Oct. 24, 2011, Ticket #229 > I have some remarks. > > ============================== > - mpi-report-F2008-2011-09-08-changeonlyplustickets.pdf p36:40-42 > (=MPI-2.2 p34:3-5) read… > > There is no mention on the probe/iprobe about the possibility of > passing MPI_STATUS_IGNORE as an argument. I can understand that if the > probe is fully named (source and tag), in some cases the status > argument is superfluous, one only need the flag. However, as this is > not clearly stated on the probe/iprobe I would not consider adding it > to p36 a viable option. Moreover, there is __no__ way to link > MPI_STATUSES_IGNORE with probe/iprobe. https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/229/MPI-Fort… lines 22-83 is doing all needed changes. Okay? > > ============================== > Section 3.6 Buffer Allocation and Usage (MPI_BUFFER_ATTACH), > INTENT(IN) is added because the routine does not modify the content of > the buffer: > > The role of this function is to provide a playground for the MPI > library to handle buffered operations. Why do we have to restrict how > the MPI implementation is handling this memory (by adding the > INTENT(IN)) ? Your question is related to https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/229/MPI-Fort… line 97 (as part of lines 84-115). This question is independent of the rest of 84-115. Yes, we can freely decide. The INTENT(IN) is based on the rules of how much length can be used of such a buffer. With zero content it is zero. Therefore it would be erroneous, if the MPI library writes anything into this buffer. Therefore INTENT(IN) should be technically okay. Are there known MPI libraries that fill something into the buf as side-effect of MPI_BUFFER_ATTACH? How should we proceed with this question? > ============================== > In general I'm totally confused about the usage of > INTENT(IN)/INTENT(OUT) through the document. In the changed proposed > you remove INTENT(OUT) from the status argument on the MPI_Probe and > friends, because they might not modify the output buffer. Then why do > you add it to the MPI_Buffer_detach? Do the MPI library have to modify > the entire buffer to qualify as a correct implementation? Your question is related to https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/229/MPI-Fort… - line 41, 60, and 69 (as part of lines 22-83) about the probe variants, - line 130 (as part of lines 116-218) about MPI_BUFFER_DETACH. In MPI_BUFFER_DETACH, the buf is an OUT argument! Many people missed this, at least the members of the MPI Forum when defining the wrong Fortran binding! mpi_f08 will have the first time a correct Fortran binding, i.e., correct in the sense that it implements the language independent routine definition. About MPI_PROBE and others: We decided in Santorini that we want to allow MPI_STATUS_IGNORE (lines 41 and 60), and therefore the INTENT(OUT) must be removed (line 69). Is it now okay with these explanations? > ============================== > Regarding Hubert question, I agree with him. Simply contiguous is not > defined in the document, so I don't see how you expect the users to > magically understand the subtle difference between contiguous and > simply contiguous? Moreover on the paragraph where "simply contiguous" > appears for the first time (copied below), I think MPI-2.2 is used > instead of MPI-3.0. > > > Advice to users. For an MPI implementation that fully supports > > nonblocking calls with the ASYNCHRONOUS attribute for choice > > buffers, an existing MPI-2.2 application may fail to compile even if > > it compiled and executed with expected results with an MPI-2.2 > > implementation. One reason may be that the application uses > > contiguous but not simply contiguous ASYNCHRONOUS arrays as actual > > arguments for choice buffers of nonblocking routines, Your question is related to https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/229/mpi-repo… page 554, lines 33-47. "Simply contiguous" is a term defined by the Fortran standard. This means, that we are not allowed to redefine it. Therefore I added to examples to show the two main cases where this causes a problem. I propose to add "See Section 16.2.12 on page 576 for more details." At the end of this advice to users. Okay? > ============================== > While looking at thee changes I read the following statement. I had to > go over twice to understand what exactly the meaning was, but I still > consider it as very unclear. How this get into the standard? Page 31, > lines 11-16. > > > In the case of a message shorter than the receive buffer, MPI is > > quite strict in that it allows no modification of the other > > locations. A more lenient statement would allow for some > > optimizations but this is not allowed. The implementation must be > > ready to end a copy into the receiver memory exactly at the end of > > the receive buffer, even if it is an odd address. This is MPI-2.2 page 31 lines 11-16! This has nothing to do with this Fortran ticket #229. Therefore no need to do anything in #229 about your question. Sorry. Okay? ================================= > Thanks, > george. Tanks and best regards Rolf -- 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

[MPI3 Fortran] Fwd: Formal Reading of the new Fortran bindings in Chicago, Oct. 24, 2011, Ticket #229
by Rolf Rabenseifner 24 Oct '11

24 Oct '11

Sorry, I forget to forward the review and my answer to the whole Fortran group. The mails was only in the group of the currently needed reviewers for these latest changes. Best regards Rolf ----- Forwarded Message ----- From: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> To: "Hubert Ritzdorf" <Hubert.Ritzdorf(a)EMEA.NEC.COM> Cc: "Bill Gropp" <wgropp(a)uiuc.edu>, "Richard Graham" <rlgraham(a)ornl.gov>, "Brian W Barrett" <bwbarre(a)sandia.gov>, "George Bosilca" <bosilca(a)eecs.utk.edu>, "Martin Schulz" <schulzm(a)llnl.gov>, "Torsten Hoefler" <htor(a)illinois.edu> Sent: Sunday, October 23, 2011 6:55:08 PM Subject: Re: Formal Reading of the new Fortran bindings in Chicago, Oct. 24, 2011, Ticket #229 Dear Hubert and all others, Hubert: thank you for your detailed review of the whole text. others: please can you check whether the revised version 2011-10-23 is now okay for youa all. I inlined my comments. With one exception, I changed the text according to Huberts advices, see below. Best regards Rolf PS: The reading in Chicago Oct. 2011, is now based on - https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/229/mpi-repo… - https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/229/MPI-3.0-… Slides 8-14. - https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/229/MPI-Fort… The revised version from Oct. 23, 2011 ----- Original Message ----- > From: "Hubert Ritzdorf" <Hubert.Ritzdorf(a)EMEA.NEC.COM> > To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de>, "Bill Gropp" <wgropp(a)uiuc.edu>, "Richard Graham" <rlgraham(a)ornl.gov>, > "Brian W Barrett" <bwbarre(a)sandia.gov>, "George Bosilca" <bosilca(a)eecs.utk.edu>, "Martin Schulz" <schulzm(a)llnl.gov>, > "Torsten Hoefler" <htor(a)illinois.edu> > Sent: Wednesday, October 12, 2011 1:03:02 PM > Subject: RE: Formal Reading of the new Fortran bindings in Chicago, Oct. 24, 2011, Ticket #229 > Hi Rolf, > > I checked all lines. Here my review: > > --------------------------------- > Lines 110-113 of file MPI-Fortran-Changes_2011-20-09-1.txt > Additional text for Section 3.6: > > There are many possibilities to pass a simply contiguous memory region > to MPI_BUFFER_ATTACH (and all other MPI functions such as MPI_Send, > .....). > Therefore, I don't like especially the sentence in Fortran. I would > propose to change > Lines 110-113 > > * In C and C++, buffer is the starting address of a memory region. > * In Fortran, one can pass the first element of a memory region > * or a whole array, which must be simply contiguous > * (for simply contiguous, see also Section 16.2.12 on page 576). > > into > > * buffer is the starting address of a simply contiguous memory region > * (for simply contiguous in Fortran, see also Section 16.2.12 on page > 576). No, I do not change the text, because the term "simply contiguous" is defined only in the context of Fortran, and there only in the context of an array. That is the reason, why we must differentiate these three cases. > > ------------------------------ > Lines 468-476 > Change of p581:11-29 > > I think, you want to add a 5th entry to mytype. I think mytype > currently has 4 entrys. > My view is: > > type, BIND(C) :: mytype > integer i > real x > double precision d > logical l > end type mytype Yes, on line 469, it must be "fifth" instead of sixth". > > To be consistent, we should add a double colon :: before each entry of > the derived type. Yes, I add the :: > Adding the 5th entry doesn't guarantee that the array of structures is > contiguous. > The special alignment rule of the compiler could .be: align the > derived type to 256 bit/8 words > (see also the last sentence (Line 474-476), which mentions such a > possibility). Yes, therefore I change "guarantee" in "force in most cases", and I remove the next three lines about "Without such an additional...", and on line 474, "With" --> "Even with", and removing "also". The text is therefore As recommended in the advice to users in Section 4.1.6 on page 106, one should add an additional fifth structure element with one numerical storage unit at the end of this structure to force in most cases that the array of structures is contiguous. Even with such an additional element, one should keep this resizing due to the special alignment rules that can be used by the compiler for structures, as also mentioned in this advice. > > ---------------------- > > Line 482-387 it is 482-487 > In Annex B > > The problem may also occur for other datatype constructors. > Example: > > type, BIND(C): huhu > integer :: huhu_entry(5) > end type huhu > > type (huhu) :: array(10) > integer :: huhu_type > > call MPI_Type_contiguous (5, MPI_INTEGER, huhu_type, ierror) > call MPI_Type_commit (huhu_type, ierror) > > call MPI_Send (array, 10, huhu_type, .... > > Therefore, I propose to change > > n Using MPI_TYPE_CREATE_STRUCT, it is always recommended that the user applies > n additionally MPI_TYPE_CREATE_RESIZED if the datatype handle should be used to communicate > n an array of structures. > > to > > n If an array of structures (in C/C++) or derived types (In Fortran) should be communicated, > n it is always recommended that the user creates a portable datatype handle and applies > n additionally MPI_TYPE_CREATE_RESIZED to this datatype handle. Yes, I change it. > ------------------- > > Line 570-573 > p394:45-p395:2 > > There are many additional possibilities of windows in Fortran (for > example a derived type, > a single variable): Therefore, I propose to replace > > * In C and C++, base is the starting address of a memory region. > * In Fortran, one can pass the first element of a memory region > * or a whole array, which must be simply contiguous > * (for simply contiguous, see also Section 16.2.12 on page 576). > > by > > * base is the starting address of a simply contiguous memory region > * (for simply contiguous in Fortran, see also Section 16.2.12 on page > 576). > The same as above: No, I do not change the text, because the term "simply contiguous" is defined only in the context of Fortran, and there only in the context of an array. That is the reason, why we must differentiate these three cases. > > Best regards > > Hubert > -- 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)

1 0

Re: [MPI3 Fortran] The alignment kerfluffle
by Rolf Rabenseifner 11 Oct '11

11 Oct '11

Hi Jeff, Yes, therefore my text is clearly telling that it is implementation dependent. Therefore, changes are not necessary. OpenMP and mpich2 and IBM are doing it different, and therefore "implementation-dependent" is a good solution. Rolf ----- Original Message ----- > From: "Jeff Squyres" <jsquyres(a)cisco.com> > To: "MPI-3 WG" <mpi3-fortran(a)lists.mpi-forum.org> > Sent: Monday, October 10, 2011 4:02:23 PM > Subject: Re: [MPI3 Fortran] The alignment kerfluffle > On Sep 28, 2011, at 4:18 PM, Jeff Squyres wrote: > > > We'll fix the alignment test in Open MPI and I suspect that everyone > > will continue to not care. :-) > > The more I think about this (and talk off-list with George about it), > the less convinced I am that Open MPI needs to change anything. > > So just to follow up on this thread on the web archives, I don't think > I'm going to change Open MPI's alignment tests. > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > _______________________________________________ > 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: [MPI3 Fortran] The alignment kerfluffle
by Jeff Squyres 10 Oct '11

10 Oct '11

On Sep 28, 2011, at 4:18 PM, Jeff Squyres wrote: > We'll fix the alignment test in Open MPI and I suspect that everyone will continue to not care. :-) The more I think about this (and talk off-list with George about it), the less convinced I am that Open MPI needs to change anything. So just to follow up on this thread on the web archives, I don't think I'm going to change Open MPI's alignment tests. -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [MPI3 Fortran] Serious problem/bug in MPI libraries with the alignment of MPI_DOUBLE_PRECISION
by Rolf Rabenseifner 09 Oct '11

09 Oct '11

Jeff, your mail didn't contain an attachment, nor the text wit "> " was modified, nor there have been lines without "> " showing the grammer corrections. I should have them as soon as possible. Best regards Rolf ----- Original Message ----- > From: "Jeff Squyres" <jsquyres(a)cisco.com> > To: "MPI-3 Fortran working group" <mpi3-fortran(a)lists.mpi-forum.org> > Sent: Friday, October 7, 2011 4:48:17 PM > Subject: Re: [MPI3 Fortran] Serious problem/bug in MPI libraries with the alignment of MPI_DOUBLE_PRECISION > I guess this looks ok -- there's some grammar changes I'd make, > though. > > One thing to be careful of: > > > * Advice to users. > > * Structures combining different basic datatypes should be defined > > so that there will > > * be no gaps based on alignment rules, and if used as an array of > > structures, then > > * also without such an alignment-gap at the end of the structure. > > * In MPI communication, the content of such gaps would not be > > communicated. > > > ^^^ This is not necessarily true. A smart enough MPI implementation > may realize that it's faster to treat a small gap as a contiguous > datatype and just ignore the extra data, especially if it's in a > homogeneous environment, and copy-in/copy-out is used anyway. > > > > On Oct 6, 2011, at 7:55 PM, Rolf Rabenseifner wrote: > > > Dear all, > > > > here is my proposal to solve the alignment problems. > > Please check carefully. > > > > It is touching only the Fortran side. > > C problems with alignments are not really touched, but should be > > small. > > > > ---------------------------------------------------------------------- > > > > (Lines with * are new, lines with : are modified, lines with x are > > removed) > > > > mpi-report-F2008-2011-09-08-changeonlyplustickets.pdf > > p86:45-47 (=MPI-2.2 p78:45-47) read > > > > If type_i requires alignment to a byte address that is a multiple > > of k_i, then epsilon > > is the least non-negative increment needed to round extent(Typemap) > > to the next multiple > > of max_i k_i. > > The complete definition of extent is given on page 107. > > > > but should read > > > > If type_i requires alignment to a byte address that is a multiple > > of k_i, then epsilon > > is the least non-negative increment needed to round extent(Typemap) > > to the next multiple > > of max_i k_i. > > * In Fortran, whether the alignments k_i are computed according to > > the alignments > > * used by the compiler in common blocks, SEQUENCE derived types, or > > BIND(C) derived types, > > * is implementation-dependent. > > : The complete definition of extent is given in Section 4.1.6 on > > page 106. > > > > ________ > > > > mpi-report-F2008-2011-09-08-changeonlyplustickets.pdf > > p87:7-11 (=MPI-2.2 p79:7-11) read > > > > Rationale. The definition of extent is motivated by the assumption > > that the amount > > of padding added at the end of each structure in an array of > > structures is the least > > needed to fulfill alignment constraints. More explicit control of > > the extent is provided > > in Section 4.1.6. Such explicit control is needed in cases where > > the assumption does > > not hold, for example, where union types are used. > > (End of rationale.) > > > > but should read > > > > Rationale. The definition of extent is motivated by the assumption > > that the amount > > of padding added at the end of each structure in an array of > > structures is the least > > needed to fulfill alignment constraints. More explicit control of > > the extent is provided > > in Section 4.1.6. Such explicit control is needed in cases where > > the assumption does > > not hold, for example, where union types are used. > > * In Fortran, structures can be expressed with several language > > features, e.g., > > * common blocks, SEQUENCE derived types, or BIND(C) derived types. > > The compiler may > > * use different alignments, and therefore, it is recommended to use > > MPI_TYPE_CREATE_RESIZED > > * for arrays of structures if an alignment may cause an > > alignment-gap at the end of > > * a structure as described in Section 4.1.6 on page 106 and in > > Section 16.2.15 on page 580. > > (End of rationale.) > > > > > > ________ > > > > mpi-report-F2008-2011-09-08-changeonlyplustickets.pdf > > p107:13-17 (=MPI-2.2 p96:42-45) read > > > > If type_i requires alignment to a byte address that is a multiple > > of k_i, then epsilon > > is the least non-negative increment needed to round extent(Typemap) > > to the next multiple > > of max_i k_i. > > The formal definitions given for the various datatype constructors > > apply now, > > with the amended definition of extent. > > > > but should read > > > > If type_i requires alignment to a byte address that is a multiple > > of k_i, then epsilon > > is the least non-negative increment needed to round extent(Typemap) > > to the next multiple > > of max_i k_i. > > * In Fortran, whether the alignments k_i are computed according to > > the alignments > > * used by the compiler in common blocks, SEQUENCE derived types, or > > BIND(C) derived types, > > * is implementation-dependent. > > The formal definitions given for the various datatype constructors > > apply now, > > with the amended definition of extent. > > > > * Rationale. > > * Before Fortran 2003, MPI_TYPE_CREATE_STRUCT could be applied to > > Fortran common blocks and > > * SEQUENCE derived types. With Fortran 2003, this list was extended > > by BIND(C) derived types > > * and MPI implementors have implemented the alignments k_i > > different, i.e., some based on > > * the alignments used in SEQUENCE derived types, and others > > according to BIND(C) derived types. > > * End of rationale. > > > > * Advice to implementors. > > * In Fortran, it is generally recommended to use BIND(C) derived > > types instead of > > * common blocks or SEQUENCE derived types. Therefore it is > > recommended to calculate the > > * alignments k_i based on BIND(C) derived types. > > * End of advoice to implementors. > > > > * Advice to users. > > * Structures combining different basic datatypes should be defined > > so that there will > > * be no gaps based on alignment rules, and if used as an array of > > structures, then > > * also without such an alignment-gap at the end of the structure. > > * In MPI communication, the content of such gaps would not be > > communicated. > > * If alignment-gaps may occur, e.g., between an odd number of floats > > ore REAL before > > * a double or DOUBLE PRECISION data, then such gaps should be added > > explicitely in > > * the structure and also to the MPI derived datatype handle, because > > the communication > > * of a contiguous derived datatype may be significantly faster than > > the communication > > * of one that is non-contiguous due such alignment-gaps. > > * > > * Example: > > * Instead of > > * > > * TYPE, BIND(C) :: my_data > > * REAL, DIMENSION(3) :: x > > * ! there may be a gap of the size of one REAL > > * ! if the alignment of a DOUBLE PRECISION is > > * ! two times the size of a REAL > > * DOUBLE PRECISION: p > > * END TYPE > > * > > * one should define > > * > > * TYPE, BIND(C) :: my_data > > * REAL, DIMENSION(3) :: x > > * REAL :: gap1 > > * DOUBLE PRECISION: p > > * END TYPE > > * > > * and also including gap1 in the matching MPI derived datatype. > > __________ > > > > mpi-report-F2008-2011-09-08-changeonlyplustickets.pdf > > p580:12,21,26,30,34,36: > > > > Add a forth structure entry: logical l after the double precision d > > ________ > > > > mpi-report-F2008-2011-09-08-changeonlyplustickets.pdf > > p581:11-29 read > > > > x TODO: The following text about the extent of derived types should > > be > > x strongly checked by specialist on derived types!!! The correct > > variant should > > x be chosen. > > To use a derived type in an array requires a correct extent of the > > datatype handle to > > take care of the alignment rules applied by the compiler. These > > alignment rules may imply > > that there are gaps between the elements of a derived type, and > > also between the array > > elements. > > x The alignment rules in Section 4.1 on page 85 and Section 4.1.6 on > > page 106 > > x apply only to > > x VARIANT 1: SEQUENCE > > x VARIANT 2: BIND(C) > > x derived types. > > The extent of an iteroperable derived type (i.e., defined with > > BIND(C)) and > > a SEQUENCE derived type with the same content may be different > > because C and Fortran > > may apply different alignment rules. > > x VARIANT 1: > > x Using the SEQUENCE attribute instead of BIND(C) in the declararion > > on mytype, one can > > x directly use newtype to send the fooarr array. > > x VARIANT 2: > > x In the example, one can directly use newtype to send the fooarr > > array. The resized > > x newarrtype datatype is only needed, if mytype is a SEQUENCE > > derived type. > > > > but should read > > > > To use a derived type in an array requires a correct extent of the > > datatype handle to > > take care of the alignment rules applied by the compiler. These > > alignment rules may imply > > that there are gaps between the elements of a derived type, and > > also between the array > > elements. > > The extent of an iteroperable derived type (i.e., defined with > > BIND(C)) and > > a SEQUENCE derived type with the same content may be different > > because C and Fortran > > may apply different alignment rules. > > As mentioned in Section 4.1 on page 86 and Section 4.1.6 on page > > 106, > > one should resize the datatype before using it for an array of > > structures fooarr, > > if elements may have different alignments that may cause an > > alignment-gap > > at the end of the structure. > > _________________________ > > > > Best regards > > Rolf > > > > > > -- > > 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) > > _______________________________________________ > > mpi3-fortran mailing list > > mpi3-fortran(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran > > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > _______________________________________________ > 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: [MPI3 Fortran] Serious problem/bug in MPI libraries with the alignment of MPI_DOUBLE_PRECISION
by Rolf Rabenseifner 07 Oct '11

07 Oct '11

I forgot to add the struct-alignment discussion which is valid for C and BIND(C) Fortran! Now (Oct.7) done! (This mail does not take reviews into account that were doen since yesterday) The atteched .txt file contains the same as this mail-text. (Lines with n are new on Oct.7, 2011, lines with * are new on Oct.6, 2011, lines with : are modified, lines with x are removed) ________ mpi-report-F2008-2011-09-08-changeonlyplustickets.pdf p13:23-31 read Rationale. Since the Fortran integer values are equivalent, applications can easily convert MPI handles between all three supported Fortran methods. For example, an integer communicator handle COMM can be converted directly into an exactly equivalent mpi_f08 communicator handle named comm_f08 by comm_f08%MPI_VAL=COMM, and vice versa. The use of the INTEGER defined handles and the BIND(C) derived type handles is different: Fortran 2003 (and later) define that BIND(C) derived types can be used within user defined common blocks, but it is up to the rules of the companion C compiler how many numerical storage unit are used for these BIND(C) derived type handles. (End of rationale.) but should read Rationale. Since the Fortran integer values are equivalent, applications can easily convert MPI handles between all three supported Fortran methods. For example, an integer communicator handle COMM can be converted directly into an exactly equivalent mpi_f08 communicator handle named comm_f08 by comm_f08%MPI_VAL=COMM, and vice versa. The use of the INTEGER defined handles and the BIND(C) derived type handles is different: Fortran 2003 (and later) define that BIND(C) derived types can be used within user defined common blocks, but it is up to the rules of the companion : C compiler how many numerical storage units are used for these BIND(C) derived type handles. n Most compilers use one unit for both, the INTEGER handles and the handles defined as n BIND(C) derived types. (End of rationale.) ________ mpi-report-F2008-2011-09-08-changeonlyplustickets.pdf p86:45-47 (=MPI-2.2 p78:45-47) read If type_i requires alignment to a byte address that is a multiple of k_i, then epsilon is the least non-negative increment needed to round extent(Typemap) to the next multiple of max_i k_i. The complete definition of extent is given on page 107. but should read If type_i requires alignment to a byte address that is a multiple of k_i, then epsilon is the least non-negative increment needed to round extent(Typemap) to the next multiple of max_i k_i. * In Fortran, whether the alignments k_i are computed according to the alignments * used by the compiler in common blocks, SEQUENCE derived types, or BIND(C) derived types, * is implementation-dependent. : The complete definition of extent is given in Section 4.1.6 on page 106. ________ mpi-report-F2008-2011-09-08-changeonlyplustickets.pdf p87:7-11 (=MPI-2.2 p79:7-11) read Rationale. The definition of extent is motivated by the assumption that the amount of padding added at the end of each structure in an array of structures is the least needed to fulfill alignment constraints. More explicit control of the extent is provided in Section 4.1.6. Such explicit control is needed in cases where the assumption does not hold, for example, where union types are used. (End of rationale.) but should read Rationale. The definition of extent is motivated by the assumption that the amount of padding added at the end of each structure in an array of structures is the least needed to fulfill alignment constraints. More explicit control of the extent is provided in Section 4.1.6. Such explicit control is needed in cases where the assumption does not hold, for example, where union types are used. * In Fortran, structures can be expressed with several language features, e.g., * common blocks, SEQUENCE derived types, or BIND(C) derived types. The compiler may * use different alignments, and therefore, it is recommended to use MPI_TYPE_CREATE_RESIZED * for arrays of structures if an alignment may cause an alignment-gap at the end of * a structure as described in Section 4.1.6 on page 106 and in Section 16.2.15 on page 580. (End of rationale.) ________ mpi-report-F2008-2011-09-08-changeonlyplustickets.pdf p107:13-17 (=MPI-2.2 p96:42-45) read If type_i requires alignment to a byte address that is a multiple of k_i, then epsilon is the least non-negative increment needed to round extent(Typemap) to the next multiple of max_i k_i. The formal definitions given for the various datatype constructors apply now, with the amended definition of extent. but should read If type_i requires alignment to a byte address that is a multiple of k_i, then epsilon is the least non-negative increment needed to round extent(Typemap) to the next multiple of max_i k_i. * In Fortran, whether the alignments k_i are computed according to the alignments * used by the compiler in common blocks, SEQUENCE derived types, or BIND(C) derived types, * is implementation-dependent. The formal definitions given for the various datatype constructors apply now, with the amended definition of extent. * Rationale. * Before Fortran 2003, MPI_TYPE_CREATE_STRUCT could be applied to Fortran common blocks and * SEQUENCE derived types. With Fortran 2003, this list was extended by BIND(C) derived types * and MPI implementors have implemented the alignments k_i different, i.e., some based on * the alignments used in SEQUENCE derived types, and others according to BIND(C) derived types. * (End of rationale.) * Advice to implementors. * In Fortran, it is generally recommended to use BIND(C) derived types instead of * common blocks or SEQUENCE derived types. Therefore it is recommended to calculate the * alignments k_i based on BIND(C) derived types. * (End of advice to implementors.) * Advice to users. * Structures combining different basic datatypes should be defined so that there will * be no gaps based on alignment rules, and if used as an array of structures, then * also without such an alignment-gap at the end of the structure. * In MPI communication, the content of such gaps would not be communicated. * If alignment-gaps may occur, e.g., between an odd number of floats ore REAL before * a double or DOUBLE PRECISION data, then such gaps should be added explicitely in * the structure and also to the MPI derived datatype handle, because the communication * of a contiguous derived datatype may be significantly faster than the communication * of one that is non-contiguous due such alignment-gaps. * * Example: * Instead of * * TYPE, BIND(C) :: my_data * REAL, DIMENSION(3) :: x * ! there may be a gap of the size of one REAL * ! if the alignment of a DOUBLE PRECISION is * ! two times the size of a REAL * DOUBLE PRECISION: p * END TYPE * * one should define * * TYPE, BIND(C) :: my_data * REAL, DIMENSION(3) :: x * REAL :: gap1 * DOUBLE PRECISION: p * END TYPE * * and also including gap1 in the matching MPI derived datatype. n It is required that all processes in a communication add the same n gaps, i.e., with defined the same basic datatype. n n In principle, a compiler may define an additional alignment rule n for structures, e.g., to use at least 4 or 8 byte alignment although n the content may have a max_i k_i alignment less than this structure n alignment. To keep an application portable, it is therefore n recommended to always resize structure derived datatype handles n if used in an array of structures, see the Example in Section n 16.2.15 on page 580. n (End of advice to users.) __________ mpi-report-F2008-2011-09-08-changeonlyplustickets.pdf p580:12,21,26,30,34,36: Add a forth structure entry: logical l after the double precision d ________ mpi-report-F2008-2011-09-08-changeonlyplustickets.pdf p581:11-29 read x TODO: The following text about the extent of derived types should be x strongly checked by specialist on derived types!!! The correct variant should x be chosen. To use a derived type in an array requires a correct extent of the datatype handle to take care of the alignment rules applied by the compiler. These alignment rules may imply that there are gaps between the elements of a derived type, and also between the array elements. x The alignment rules in Section 4.1 on page 85 and Section 4.1.6 on page 106 x apply only to x VARIANT 1: SEQUENCE x VARIANT 2: BIND(C) x derived types. The extent of an iteroperable derived type (i.e., defined with BIND(C)) and a SEQUENCE derived type with the same content may be different because C and Fortran may apply different alignment rules. x VARIANT 1: x Using the SEQUENCE attribute instead of BIND(C) in the declararion on mytype, one can x directly use newtype to send the fooarr array. x VARIANT 2: x In the example, one can directly use newtype to send the fooarr array. The resized x newarrtype datatype is only needed, if mytype is a SEQUENCE derived type. but should read To use a derived type in an array requires a correct extent of the datatype handle to take care of the alignment rules applied by the compiler. These alignment rules may imply that there are gaps between the elements of a derived type, and also between the array elements. The extent of an iteroperable derived type (i.e., defined with BIND(C)) and a SEQUENCE derived type with the same content may be different because C and Fortran may apply different alignment rules. n As recommended in the advice to users in Section 4.1.6 on page 106, n one should add an additional sixth structure element with one numerical storage unit n at the end of this structure to guarantee that the array of stuctures is contiguous. n Without such an additional element, the resizing is needed because the n alignment rules cannot guarantee that aliagnment of the stucture used by the compiler n and calculated by MPI is identical. n With such an additional element, one should also keep the resizing due to the n special alignment rules that can be used by the compiler for structures, n as also mentioned in this advice. ________________ Best regards Rolf -- 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: [MPI3 Fortran] Serious problem/bug in MPI libraries with the alignment of MPI_DOUBLE_PRECISION
by Bill Long 07 Oct '11

07 Oct '11

On 10/6/11 6:55 PM, Rolf Rabenseifner wrote: > ________ > > mpi-report-F2008-2011-09-08-changeonlyplustickets.pdf > p87:7-11 (=MPI-2.2 p79:7-11) read > > Rationale. The definition of extent is motivated by the assumption that the amount > of padding added at the end of each structure in an array of structures is the least > needed to fulfill alignment constraints. More explicit control of the extent is provided > in Section 4.1.6. Such explicit control is needed in cases where the assumption does > not hold, for example, where union types are used. > (End of rationale.) > > but should read > > Rationale. The definition of extent is motivated by the assumption that the amount > of padding added at the end of each structure in an array of structures is the least > needed to fulfill alignment constraints. More explicit control of the extent is provided > in Section 4.1.6. Such explicit control is needed in cases where the assumption does > not hold, for example, where union types are used. > * In Fortran, structures can be expressed with several language features, e.g., > * common blocks, SEQUENCE derived types, or BIND(C) derived types. The compiler may or derived types that are neither SEQUENCE nor BIND(C) types (which is the most common case). > * use different alignments, and therefore, it is recommended to use MPI_TYPE_CREATE_RESIZED > * for arrays of structures if an alignment may cause an alignment-gap at the end of > * a structure as described in Section 4.1.6 on page 106 and in Section 16.2.15 on page 580. > (End of rationale.) > > > ________ > > mpi-report-F2008-2011-09-08-changeonlyplustickets.pdf > p107:13-17 (=MPI-2.2 p96:42-45) read > > If type_i requires alignment to a byte address that is a multiple of k_i, then epsilon > is the least non-negative increment needed to round extent(Typemap) to the next multiple > of max_i k_i. > The formal definitions given for the various datatype constructors apply now, > with the amended definition of extent. > > but should read > > If type_i requires alignment to a byte address that is a multiple of k_i, then epsilon > is the least non-negative increment needed to round extent(Typemap) to the next multiple > of max_i k_i. > * In Fortran, whether the alignments k_i are computed according to the alignments > * used by the compiler in common blocks, SEQUENCE derived types, or BIND(C) derived types, again, or derived types that are neither SEQUENCE nor BIND(C). > * is implementation-dependent. > The formal definitions given for the various datatype constructors apply now, > with the amended definition of extent. > Cheers, Bill -- Bill Long longb(a)cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101

1 0