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

Re: [Mpi-22] [Mpi-forum] MPI 2.2 proposal: resolving MPI_Request_free issues
by unknown＠example.com 17 Jul '08

17 Jul '08

The problem with solution #5 is that it still might be incorrect. It is okay to read the buffer while the local interconnect is still using it but it's not always the case with write. For example, it is okay for the interconnect to probe the memory again before releasing it. It can use probe for write (which is odd, but can happen). This probe is usually implemented as read-write back, if the probe happens as the same time the user is updating the data; the user data might get corrupted. I know it is farfetched, but I'd be extremely cautions recommending the user to write the buffer before the local resource "owner" (which is the interconnect) relinquish it back. As a solution I would put text that discourage the use for MPI_Request_free for active request; and recommend using Adam Moody proposal for MPI_REQUEST_IGNORE. (we might not be able to make this an error case in 2.2 to keep backward compatibility) The text specifically would say that writing or freeing the buffer after calling MPI_Request_free is unsafe. Thanks, .Erez -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Wednesday, July 16, 2008 6:59 PM To: MPI 2.2 Subject: Re: [Mpi-22] [Mpi-forum] MPI 2.2 proposal:resolving MPI_Request_free issues On Jul 16, 2008, at 7:31 PM, Underwood, Keith D wrote: >>> [erezh] Correct; this is the scenario I was describing with the RDMA write. > > It would be interesting to see exactly what the error mode here is. > Retransmitting corrupted data should be ok, since a correctly > delivered > message means that the retransmit must be dropped. I suppose that if > the NIC speaks virtual addresses and the free actually results in a > trap > to the kernel that unmaps the pages, then the NIC could retransmit and > find that there isn't a valid page table entry... 'zactly. And then the local completion entry would be a failure -- so the sender would [erroneously] think that the message had failed to be delivered. > Solution #5: Change the advice to users - "...the arrival of the > reply > informs the sender that the send has completed and the send buffer can > be overwritten. If the buffer will ever be freed, the application > should call MPI_Wait or MPI_Cancel instead of MPI_Request_free." That seems like a good compromise. -- Jeff Squyres Cisco Systems _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22

1 0

Re: [Mpi-22] [Mpi-forum] MPI 2.2 proposal: resolving MPI_Request_free issues
by unknown＠example.com 17 Jul '08

17 Jul '08

On Thu, Jul 17, 2008 at 02:51:10PM -0400, Richard Treumann wrote: > Also, in most systems support for malloc/free, the free() call does not > change the ability of the adapter or VMM to modify the status of the > address range. The address range that had been exposed to application use > before the free() is simply added back to the heap and stays there until > another malloc needs it. glibc issues individual mmap()s for large allocations. These are returned to the OS on free. Also, if the top of the heap of small allocations is all free (rare due to fragmentation), it will sbrk backwards. Adaptors which have to maintain virt->phys mappings all struggle with this, in one way or another. I'm finding this whole discussion confusing. On all of the interconnects that I'm familiar with, freeing and modifying the buffer are both unsafe before the wait, and safe after. There's no free lunch. Am I not thinking of some important example? -- greg

1 0

Re: [Mpi-22] [Mpi-forum] MPI 2.2 proposal: resolving MPI_Request_free issues
by unknown＠example.com 17 Jul '08

17 Jul '08

On any MPI implementation the author of this application sequence: MPI_ISEND compute MPI_WAIT modify or free buffer will hope that the MPI_WAIT takes as little time as possible. The standard tells the user he can safely "reuse" the send buffer when the MPI_WAIT returns. If there are things which must happen before it is safe to free the buffer that do not need to happen before it is safe to modify its content, must an MPI implementation with the kind of issues Erez is suggesting delay the return from MPI_WAIT until both modify and free are safe? I suppose so - but it is unfortunate to need to delay the return from MPI_WAIT when it is safe for the user to do what he most likely has in mind (modify). As someone else pointed out, once the destination receive has finished, any packet retransmissions that are caused by ACK loss can harmlessly contain modified data. The send buffer does not need to be protected from updates. The destination will simply discard these packets them anyway. Also, in most systems support for malloc/free, the free() call does not change the ability of the adapter or VMM to modify the status of the address range. The address range that had been exposed to application use before the free() is simply added back to the heap and stays there until another malloc needs it. Doing a store to a memory range after a free() is likely to cause trouble but doing a load from ii is normally harmless. (I suppose someone will now tell me about a system where "free(ptr); x=*ptr;" causes segfaults. It is not the norm) Dick Dick Treumann - MPI Team/TCEM IBM Systems & Technology Group Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 mpi-22-bounces_at_[hidden] wrote on 07/17/2008 02:01:24 PM: > > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22- > bounces_at_[hidden]] On Behalf Of Underwood, Keith D > Sent: Wednesday, July 16, 2008 4:32 PM > To: MPI 2.2 > Subject: Re: [Mpi-22] [Mpi-forum] MPI 2.2 proposal:resolving > MPI_Request_free issues > > >> I don't quite understand examples 1 and 2 (how would they cause segv's > >> in the TCP stack). It is permissible to (pseudocode): > >> > >> while (bytes_to_send > 0) { > >> rc = write(fd, buffer, bytes_to_send); > >> if (rc > 0) { > >> buffer += rc; > >> bytes_to_send -= rc; > >> } else { > >> ...error... > >> } > >> } > >> free(buffer); > >> > >> regardless of what the receiver does. I'm not a kernel guy; does > >> updating TCP sequence numbers also interact with the payload buffer? > > > >[erezh] it will never happen with your code above; but you are not using > >async zcopy. > >The pattern in windows is to use overlapped send (write) which is still > >active when the function returns, and is the most efficient way to send > >your buffer. I know it's possible with Linux but I don't' have the exact > >pattern. > > > [Keith] > > So, how does this work for other users of zero copy? How do they know > > when the send buffer is truly free? > > [erezh] you get a notification from your local resource manager; on > windows with the overlapped mechanism you have few ways to get > notified. 1) The overlapped event get set, the thread can wait on > it. 2) a completion port notification that the thread can dequeue. > 3) an APC (similar to unix signal) get queued to the thread (thread > need to be in an alertable state) > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 *

1 0

Re: [Mpi-22] [Mpi-forum] MPI 2.2 proposal: resolving MPI_Request_free issues
by unknown＠example.com 17 Jul '08

17 Jul '08

-----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Underwood, Keith D Sent: Wednesday, July 16, 2008 4:32 PM To: MPI 2.2 Subject: Re: [Mpi-22] [Mpi-forum] MPI 2.2 proposal:resolving MPI_Request_free issues >> I don't quite understand examples 1 and 2 (how would they cause segv's >> in the TCP stack). It is permissible to (pseudocode): >> >> while (bytes_to_send > 0) { >> rc = write(fd, buffer, bytes_to_send); >> if (rc > 0) { >> buffer += rc; >> bytes_to_send -= rc; >> } else { >> ...error... >> } >> } >> free(buffer); >> >> regardless of what the receiver does. I'm not a kernel guy; does >> updating TCP sequence numbers also interact with the payload buffer? > >[erezh] it will never happen with your code above; but you are not using >async zcopy. >The pattern in windows is to use overlapped send (write) which is still >active when the function returns, and is the most efficient way to send >your buffer. I know it's possible with Linux but I don't' have the exact >pattern. > [Keith] > So, how does this work for other users of zero copy? How do they know > when the send buffer is truly free? [erezh] you get a notification from your local resource manager; on windows with the overlapped mechanism you have few ways to get notified. 1) The overlapped event get set, the thread can wait on it. 2) a completion port notification that the thread can dequeue. 3) an APC (similar to unix signal) get queued to the thread (thread need to be in an alertable state)

1 0

Re: [Mpi-22] MPI-2.1 ambiguity?
by unknown＠example.com 17 Jul '08

17 Jul '08

I don't think that text will work. Specifically, what is the type of MPI_INT in Fortran? It may be something other than a Fortran INTEGER. So, either these values need to already be converted into the language-of-the-headerfile, or we need a new datatype for Fortran that can contain a C or a C++ Datatype (e.g., something like INTEGER (KIND=MPI_DATATYPE_C_HANDLE) ). That's why I think that they must be presented by the implementation with the values that you would get by taking making use of the conversion functions. Of course, an application must then be careful not to apply MPI_Type_c2f to the Fortran version of MPI_INT ... There's another option. Drop the requirement that all of the predefined datatypes are predefined in all languages, but specify that they may be used (with the appropriate handle conversion) as input to any routine where it makes sense. For datatypes, this includes the datatype construction routines but not the communication routines (don't use MPI_INT when sending INTEGERs with Fortran). This is what the Opaque Objects text expects. Bill On Jul 17, 2008, at 10:01 AM, Rolf Rabenseifner wrote: > My primary oal is: > We should make clarifications which state that > each predefined handle must be available in every > language binding. > People may be confused by current wording in several places: > > - MPI-2.1 (June 23, 2008) Section 16.3.6 MPI Opaque Objects, > page 483, lines 46-47: > "All predefined datatypes can be used in datatype constructors > in any language." > > - MPI-2.1 (June 23, 2008) Section 16.3.9 Constants, > page 488, lines 33-35: > "MPI constants have the same value in all languages, > unless specified otherwise. This does not > apply to constant handles (MPI_INT, MPI_COMM_WORLD, > MPI_ERRORS_RETURN, MPI_SUM, etc.) These handles need > to be converted, as explained in Section 16.3.4." > > - MPI-2.1 (June 23, 2008) Annex A.1.1 Defined Constants, > page 491, lines 22-23: > "The C and Fortran name is listed in the left column and the > C++ name is listed in the middle or right column." > > Proposal: > ========= > > MPI-2.1 p. 488, lines 33-35 reads: > "MPI constants have the same value in all languages, > unless specified otherwise. This does not > apply to constant handles (MPI_INT, MPI_COMM_WORLD, > MPI_ERRORS_RETURN, MPI_SUM, etc.) These handles need > to be converted, as explained in Section 16.3.4." > > but should read: > "MPI constants have the same value in all languages, > unless specified otherwise. This does not > apply to constant handles (MPI_INT, MPI_COMM_WORLD, > MPI_ERRORS_RETURN, MPI_SUM, etc.) > Although these handles (e.g. predefined datatypes) > must exist in all language bindings, their values > may be different in each language binding. > If one wants to use a constant handle from one language binding > (e.g., MPI_DOUBLE from mpi.h) in a call to an MPI function in > another language binding (e.g., in Fortran MPI_SEND), then > these handles need > to be converted, as explained in Section 16.3.4." > > Does this help? > > Best regards > Rolf > > > On Thu, 17 Jul 2008 09:03:35 -0500 > William Gropp <wgropp_at_[hidden]> wrote: >> To make this perfectly clear, should the standard state that the >> values of the predefined datatypes from another language are exactly >> the same as the value produced by the handle conversion function? >> E.g., in Fortran, the value of MPI_INT is what you would get from >> MPI_TYPE_C2F( MPI_INT ) (where MPI_INT is the C version). It >> should also state that just because Fortran defines MPI_LONG_LONG, >> that does not imply that Fortran support an integer type that >> corresponds to the C long long type. >> >> Bill >> >> On Jul 17, 2008, at 4:03 AM, Rolf Rabenseifner wrote: >> >>> Hi all, >>> >>> The argument-chain was: >>> >>>>>> William Gropp wrote: >>>>>>> One piece of relevant text in MPI 2.0 is in section 4.12.6 (in >>>>>>> MPI-2.0) says that "All predefined datatypes can be used in >>>>>>> datatype constructors in any language." >>> [....] >>> >>> This text is supported also by: >>> MPI-2.0 Chap. 10.1.6 page 276 and >>> MPI-2.0 Annex B.2, page 344 define for all Fortran predefined >>> datatype handles as C++ counter-part. >>> >>> In the meeting, there was a consensus (?) that it is a bug >>> if an MPI implementation does not support, e.g. MPI_INT >>> in the mpif.h Fortran header file. >>> (This bug can be found, e.g., in MPICH-2 and will be fixed, >>> when I understood correctly) >>> >>> The value (not the name!!) of MPI_INT in mpif.h and mpi.h may be >>> different, as stated already in MPI-2.0, Sect. 4.12.9. >>> MPI_INT from C mpi.h cannot be used in a Fortran CALL MPI_SEND(...). >>> You need to convert, or you must use MPI_INT from Fortran mpif.h. >>> >>> (I.e. one may distiguish between mixed languages in >>> one MPI executable [addressed by MPI-2.0 Section 4.12.9], >>> and sending a message from a Fortran MPI executable to a C MPI >>> executable and vice versa [see MPI 2.0 Section 4.12.6].) >>> >>> Because this is already "clearly" defined in MPI-2.0, >>> you will not find any remark about this in the Change-Log >>> of MPI-2.1. >>> >>> MPI-2.2 may make it more clear in the revisiting of datatypes. >>> >>> Best regards >>> Rolf >>> >>> On Thu, 17 Jul 2008 10:20:28 +0200 >>> Hubert Ritzdorf <ritzdorf_at_it.neclab.eu> wrote: >>>> No, we didn't have them. The request to provide all C datatypes in >>>> Fortran was specified in one of the last meetings. When I remember >>>> correctly, it was specified in the last meeting in Chicago or >>>> the meeting before (I think it was specified together with item 33 >>>> of the change log). I implemented it together with the changes >>>> for MPI 2.1 since I assumed that it was contained also in the >>>> change log. After your mail, I recognized that it is only >>>> implicitly >>>> mentioned by item 33. >>>> >>>> Hubert >>>> >>>> Jeff Squyres wrote: >>>>> What does NEC MPI do -- do you have MPI_INT and MPI_FLOAT >>>>> (etc.) in >>>>> mpif.h? >>>>> >>>>> >>>>> On Jul 16, 2008, at 12:57 PM, Hubert Ritzdorf wrote: >>>>> >>>>>> What's about the C++ datatypes for complex ? >>>>>> MPI_COMPLEX and MPI_Double_Complex are already defined for >>>>>> Fortran >>>>>> datatypes. The complex Fortran datatypes within C++ have a >>>>>> special >>>>>> name in order to avoid a name collision. >>>>>> >>>>>> Hubert >>>>>> >>>>>> William Gropp wrote: >>>>>>> One piece of relevant text in MPI 2.0 is in section 4.12.6 (in >>>>>>> MPI-2.0) says that "All predefined datatypes can be used in >>>>>>> datatype >>>>>>> constructors in any language." However, the example uses >>>>>>> MPI_Type_f2c ton convert the Fortran handle to the C version >>>>>>> before >>>>>>> passing it into the MPI_Type_create_struct routine, so this text >>>>>>> could be interpreted as allowing the use of those datatypes >>>>>>> through >>>>>>> the handle conversion mechanism without requiring them to be >>>>>>> defined >>>>>>> in each languages header file. Presumably the requirement is >>>>>>> that >>>>>>> they be predefined with the value that you'd get from the handle >>>>>>> conversion function? >>>>>>> >>>>>>> Bill >>>>>>> >>>>>>> On Jul 16, 2008, at 8:18 AM, Hubert Ritzdorf wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> when I remember correctly, it was decided to provide the C MPI >>>>>>>> datatypes >>>>>>>> in Fortran since >>>>>>>> the Fortran datatypes are supported in C and C++. >>>>>>>> >>>>>>>> Hubert >>>>>>>> >>>>>>>> Jeff Squyres wrote: >>>>>>>>> I will file a proposal about this if there is a problem, but I >>>>>>>>> wanted >>>>>>>>> to ask the group before I did so. In the changelog for >>>>>>>>> MPI-2.1: >>>>>>>>> >>>>>>>>> 2. Section 3.2.2 on page 27, Section 16.1.6 on page 453, and >>>>>>>>> Annex >>>>>>>>> A.1 >>>>>>>>> on page 491. >>>>>>>>> MPI_LONG_LONG_INT, MPI_LONG_LONG (as synonym), >>>>>>>>> MPI_UNSIGNED_LONG_LONG, >>>>>>>>> MPI_SIGNED_CHAR, and MPI_WCHAR are moved from optional to >>>>>>>>> oï¬cial >>>>>>>>> and they >>>>>>>>> are therefore deï¬ned for all three language bindings. >>>>>>>>> >>>>>>>>> Note that it says that these C datatype names must be in all >>>>>>>>> three >>>>>>>>> language bindings. >>>>>>>>> >>>>>>>>> Are C MPI datatypes supposed to be available in Fortran? I >>>>>>>>> looked >>>>>>>>> in >>>>>>>>> mpif.h for Open MPI, MPICH2, HP MPI, and Intel MPI, and I >>>>>>>>> didn't >>>>>>>>> see C >>>>>>>>> MPI datatypes in there (e.g., MPI_INT and MPI_FLOAT). >>>>>>>>> >>>>>>>>> So: >>>>>>>>> >>>>>>>>> - is there language somewhere in MPI that says that C >>>>>>>>> datatypes are >>>>>>>>> not supposed to be in mpif.h? (and therefore the MPI-2.1 >>>>>>>>> changelog >>>>>>>>> is >>>>>>>>> wrong) >>>>>>>>> >>>>>>>>> or >>>>>>>>> >>>>>>>>> - are all 4 of the above MPI's wrong for not including the C >>>>>>>>> datatypes >>>>>>>>> in mpif.h? >>>>>>>>> >>>>>>>>> --Jeff Squyres >>>>>>>>> Cisco Systems >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> mpi-22 mailing list >>>>>>>>> mpi-22_at_[hidden] <mailto:mpi-22_at_[hidden]> >>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >>>>>>>>> >>>>>>>>> <smime.p7s><ATT00001.txt> >>>>>>> >>>>>>> William Gropp >>>>>>> Paul and Cynthia Saylor Professor of Computer Science >>>>>>> University of Illinois Urbana-Champaign >>>>>>> >>>>>>> >>>>>>> >>>>>>> ---------------------------------------------------------------- >>>>>>> -- >>>>>>> ------ >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> mpi-22 mailing list >>>>>>> mpi-22_at_[hidden] >>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >>>>>>> >>>>>> _______________________________________________ >>>>>> mpi-22 mailing list >>>>>> mpi-22_at_[hidden] >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >>>>> >>>>> >>>>> --Jeff Squyres >>>>> Cisco Systems >>>>> >>>>> >>>>> _______________________________________________ >>>>> mpi-22 mailing list >>>>> mpi-22_at_[hidden] >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >>>>> >>> >>> Dr. Rolf Rabenseifner . . . . . . . . . .. email >>> rabenseifner_at_[hidden] >>> High Performance Computing Center (HLRS) . phone >>> ++49(0)711/685-65530 >>> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / >>> 685-65832 >>> Head of Dpmt Parallel Computing . . . >>> www.hlrs.de/people/rabenseifner >>> Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) >>> _______________________________________________ >>> mpi-22 mailing list >>> mpi-22_at_[hidden] >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >> >> William Gropp >> Paul and Cynthia Saylor Professor of Computer Science >> University of Illinois Urbana-Champaign >> >> >> > > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 William Gropp Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign *

1 0

Re: [Mpi-22] MPI-2.1 ambiguity?
by unknown＠example.com 17 Jul '08

17 Jul '08

To me this debate seems trivial but perhaps that is because for IBM MPI the value of a predefined datatype handle is a 4 byte integer constant and MPI_INT is a different constant than MPI_INTEGER. Putting MPI_INT in mpif.h is easy and it has been there since day one. MPI_TYPE_C2F( MPI_INT )has no work to do. Are there MPI implementations that do something that makes it complicated to satisfy the following statements? 1) All predefined datatype handles must be defined in all languages (C, C++ and Fortran) 2) The value of a C handle as defined in mpif.h must be that same as is returned when MPI_TYPE_C2F( handle ) is used in C 3) Having a C handle in mpif.h does not imply that the Fortran compiler supports a corresponding Fortran datatype It could be argued that point 3 is too obvious to mention. Dick Treumann - MPI Team/TCEM IBM Systems & Technology Group Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 mpi-22-bounces_at_[hidden] wrote on 07/17/2008 10:03:35 AM: > To make this perfectly clear, should the standard state that the > values of the predefined datatypes from another language are exactly > the same as the value produced by the handle conversion function? > Â E.g., in Fortran, the value of MPI_INT is what you would get from > MPI_TYPE_C2F( MPI_INT ) Â (where MPI_INT is the C version). Â It > should also state that just because Fortran defines MPI_LONG_LONG, > that does not imply that Fortran support an integer type that > corresponds to the C long long type. > > Bill > > On Jul 17, 2008, at 4:03 AM, Rolf Rabenseifner wrote: > > Hi all, > > The argument-chain was: > > William Gropp wrote: > One piece of relevant text in MPI 2.0 is in section 4.12.6 (in > MPI-2.0) says that "All predefined datatypes can be used in > datatype constructors in any language." > [....] > > This text is supported also by: > MPI-2.0 Chap. 10.1.6 page 276 and > MPI-2.0 Annex B.2, page 344 define for all Fortran predefined > datatype handles as C++ counter-part. > > In the meeting, there was a consensus (?) that it is a bug > if an MPI implementation does not support, e.g. MPI_INT > in the mpif.h Fortran header file. > (This bug can be found, e.g., in MPICH-2 and will be fixed, > when I understood correctly) > > The value (not the name!!) of MPI_INT in mpif.h and mpi.h may be > different, as stated already in MPI-2.0, Sect. 4.12.9. > MPI_INT from C mpi.h cannot be used in a Fortran CALL MPI_SEND(...). > You need to convert, or you must use MPI_INT from Fortran mpif.h. > > (I.e. one may distiguish between mixed languages in > one MPI executable [addressed by MPI-2.0 Section 4.12.9], > and sending a message from a Fortran MPI executable to a C MPI > executable and vice versa [see MPI 2.0 Section 4.12.6].) > > Because this is already "clearly" defined in MPI-2.0, > you will not find any remark about this in the Change-Log > of MPI-2.1. > > MPI-2.2 may make it more clear in the revisiting of datatypes. > > Best regards > Rolf > > On Thu, 17 Jul 2008 10:20:28 +0200 > Â  Hubert Ritzdorf <ritzdorf_at_it.neclab.eu> wrote: > No, we didn't have them. The request to provide all C datatypes in > Fortran was specified in one of the last meetings. When I remember > correctly, it was specified in the last meeting in Chicago or > the meeting before (I think it was specified together with item 33 > of the change log). I implemented it together with the changes > for MPI 2.1 since I assumed that it was contained also in the > change log. After your mail, I recognized that it is only implicitly > mentioned by item 33. > > Hubert > > Jeff Squyres wrote: > What does NEC MPI do -- do you have MPI_INT and MPI_FLOAT (etc.) in > mpif.h? > > On Jul 16, 2008, at 12:57 PM, Hubert Ritzdorf wrote: > > What's about the C++ datatypes for complex ? > MPI_COMPLEX and MPI_Double_Complex are already defined for Fortran > datatypes. The complex Fortran datatypesÂ  within C++Â  have a special > name in order to avoid a name collision. > > Hubert > > William Gropp wrote: > One piece of relevant text in MPI 2.0 is in section 4.12.6 (in > MPI-2.0) says that "All predefined datatypes can be used in datatype > constructors in any language."Â  However, the example uses > MPI_Type_f2c ton convert the Fortran handle to the C version before > passing it into the MPI_Type_create_struct routine, so this text > could be interpreted as allowing the use of those datatypes through > the handle conversion mechanism without requiring them to be defined > in each languages header file.Â  Presumably the requirement is that > they be predefined with the value that you'd get from the handle > conversion function? > > Bill > > On Jul 16, 2008, at 8:18 AM, Hubert Ritzdorf wrote: > > Hi, > > when I remember correctly, it was decided to provide the C MPI > datatypes > in Fortran since > the Fortran datatypes are supported in C and C++. > > Hubert > > Jeff Squyres wrote: > I will file a proposal about this if there is a problem, but I > wanted > to ask the group before I did so.Â  In the changelog for MPI-2.1: > > 2. Section 3.2.2 on page 27, Section 16.1.6 on page 453, and Annex > A.1 > on page 491. > MPI_LONG_LONG_INT, MPI_LONG_LONG (as synonym), > MPI_UNSIGNED_LONG_LONG, > MPI_SIGNED_CHAR, and MPI_WCHAR are moved from optional to oï¬cial > and they > are therefore deï¬ned for all three language bindings. > > Note that it says that these C datatype names must be in all three > language bindings. > > Are C MPI datatypes supposed to be available in Fortran?Â  I looked > in > mpif.h for Open MPI, MPICH2, HP MPI, and Intel MPI, and I didn't > see C > MPI datatypes in there (e.g., MPI_INT and MPI_FLOAT). > > So: > > - is there language somewhere in MPI that says that C datatypes are > not supposed to be in mpif.h? (and therefore the MPI-2.1 changelog > is > wrong) > > or > > - are all 4 of the above MPI's wrong for not including the C > datatypes > in mpif.h? > > --Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] <mailto:mpi-22_at_[hidden]> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > <smime.p7s><ATT00001.txt> > > William Gropp > Paul and Cynthia Saylor Professor of Computer Science > University of Illinois Urbana-Champaign > > ------------------------------------------------------------------------ > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > --Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > WilliamÂ Gropp > Paul and Cynthia Saylor Professor of Computer Science > University of Illinois Urbana-Champaign > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 *

1 0

Re: [Mpi-22] MPI-2.1 ambiguity?
by unknown＠example.com 17 Jul '08

17 Jul '08

My primary oal is: We should make clarifications which state that each predefined handle must be available in every language binding. People may be confused by current wording in several places: - MPI-2.1 (June 23, 2008) Section 16.3.6 MPI Opaque Objects, page 483, lines 46-47: "All predefined datatypes can be used in datatype constructors in any language." - MPI-2.1 (June 23, 2008) Section 16.3.9 Constants, page 488, lines 33-35: "MPI constants have the same value in all languages, unless specified otherwise. This does not apply to constant handles (MPI_INT, MPI_COMM_WORLD, MPI_ERRORS_RETURN, MPI_SUM, etc.) These handles need to be converted, as explained in Section 16.3.4." - MPI-2.1 (June 23, 2008) Annex A.1.1 Defined Constants, page 491, lines 22-23: "The C and Fortran name is listed in the left column and the C++ name is listed in the middle or right column." Proposal: ========= MPI-2.1 p. 488, lines 33-35 reads: "MPI constants have the same value in all languages, unless specified otherwise. This does not apply to constant handles (MPI_INT, MPI_COMM_WORLD, MPI_ERRORS_RETURN, MPI_SUM, etc.) These handles need to be converted, as explained in Section 16.3.4." but should read: "MPI constants have the same value in all languages, unless specified otherwise. This does not apply to constant handles (MPI_INT, MPI_COMM_WORLD, MPI_ERRORS_RETURN, MPI_SUM, etc.) Although these handles (e.g. predefined datatypes) must exist in all language bindings, their values may be different in each language binding. If one wants to use a constant handle from one language binding (e.g., MPI_DOUBLE from mpi.h) in a call to an MPI function in another language binding (e.g., in Fortran MPI_SEND), then these handles need to be converted, as explained in Section 16.3.4." Does this help? Best regards Rolf On Thu, 17 Jul 2008 09:03:35 -0500 William Gropp <wgropp_at_[hidden]> wrote: > To make this perfectly clear, should the standard state that the > values of the predefined datatypes from another language are exactly > the same as the value produced by the handle conversion function? > E.g., in Fortran, the value of MPI_INT is what you would get from > MPI_TYPE_C2F( MPI_INT ) (where MPI_INT is the C version). It >should also state that just because Fortran defines MPI_LONG_LONG, >that does not imply that Fortran support an integer type that >corresponds to the C long long type. > > Bill > > On Jul 17, 2008, at 4:03 AM, Rolf Rabenseifner wrote: > >> Hi all, >> >> The argument-chain was: >> >>>>> William Gropp wrote: >>>>>> One piece of relevant text in MPI 2.0 is in section 4.12.6 (in >>>>>> MPI-2.0) says that "All predefined datatypes can be used in >>>>>> datatype constructors in any language." >> [....] >> >> This text is supported also by: >> MPI-2.0 Chap. 10.1.6 page 276 and >> MPI-2.0 Annex B.2, page 344 define for all Fortran predefined >> datatype handles as C++ counter-part. >> >> In the meeting, there was a consensus (?) that it is a bug >> if an MPI implementation does not support, e.g. MPI_INT >> in the mpif.h Fortran header file. >> (This bug can be found, e.g., in MPICH-2 and will be fixed, >> when I understood correctly) >> >> The value (not the name!!) of MPI_INT in mpif.h and mpi.h may be >> different, as stated already in MPI-2.0, Sect. 4.12.9. >> MPI_INT from C mpi.h cannot be used in a Fortran CALL MPI_SEND(...). >> You need to convert, or you must use MPI_INT from Fortran mpif.h. >> >> (I.e. one may distiguish between mixed languages in >> one MPI executable [addressed by MPI-2.0 Section 4.12.9], >> and sending a message from a Fortran MPI executable to a C MPI >> executable and vice versa [see MPI 2.0 Section 4.12.6].) >> >> Because this is already "clearly" defined in MPI-2.0, >> you will not find any remark about this in the Change-Log >> of MPI-2.1. >> >> MPI-2.2 may make it more clear in the revisiting of datatypes. >> >> Best regards >> Rolf >> >> On Thu, 17 Jul 2008 10:20:28 +0200 >> Hubert Ritzdorf <ritzdorf_at_it.neclab.eu> wrote: >>> No, we didn't have them. The request to provide all C datatypes in >>> Fortran was specified in one of the last meetings. When I remember >>> correctly, it was specified in the last meeting in Chicago or >>> the meeting before (I think it was specified together with item 33 >>> of the change log). I implemented it together with the changes >>> for MPI 2.1 since I assumed that it was contained also in the >>> change log. After your mail, I recognized that it is only implicitly >>> mentioned by item 33. >>> >>> Hubert >>> >>> Jeff Squyres wrote: >>>> What does NEC MPI do -- do you have MPI_INT and MPI_FLOAT (etc.) in >>>> mpif.h? >>>> >>>> >>>> On Jul 16, 2008, at 12:57 PM, Hubert Ritzdorf wrote: >>>> >>>>> What's about the C++ datatypes for complex ? >>>>> MPI_COMPLEX and MPI_Double_Complex are already defined for Fortran >>>>> datatypes. The complex Fortran datatypes within C++ have a >>>>> special >>>>> name in order to avoid a name collision. >>>>> >>>>> Hubert >>>>> >>>>> William Gropp wrote: >>>>>> One piece of relevant text in MPI 2.0 is in section 4.12.6 (in >>>>>> MPI-2.0) says that "All predefined datatypes can be used in >>>>>> datatype >>>>>> constructors in any language." However, the example uses >>>>>> MPI_Type_f2c ton convert the Fortran handle to the C version >>>>>> before >>>>>> passing it into the MPI_Type_create_struct routine, so this text >>>>>> could be interpreted as allowing the use of those datatypes >>>>>> through >>>>>> the handle conversion mechanism without requiring them to be >>>>>> defined >>>>>> in each languages header file. Presumably the requirement is that >>>>>> they be predefined with the value that you'd get from the handle >>>>>> conversion function? >>>>>> >>>>>> Bill >>>>>> >>>>>> On Jul 16, 2008, at 8:18 AM, Hubert Ritzdorf wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> when I remember correctly, it was decided to provide the C MPI >>>>>>> datatypes >>>>>>> in Fortran since >>>>>>> the Fortran datatypes are supported in C and C++. >>>>>>> >>>>>>> Hubert >>>>>>> >>>>>>> Jeff Squyres wrote: >>>>>>>> I will file a proposal about this if there is a problem, but I >>>>>>>> wanted >>>>>>>> to ask the group before I did so. In the changelog for MPI-2.1: >>>>>>>> >>>>>>>> 2. Section 3.2.2 on page 27, Section 16.1.6 on page 453, and >>>>>>>> Annex >>>>>>>> A.1 >>>>>>>> on page 491. >>>>>>>> MPI_LONG_LONG_INT, MPI_LONG_LONG (as synonym), >>>>>>>> MPI_UNSIGNED_LONG_LONG, >>>>>>>> MPI_SIGNED_CHAR, and MPI_WCHAR are moved from optional to >>>>>>>> oï¬cial >>>>>>>> and they >>>>>>>> are therefore deï¬ned for all three language bindings. >>>>>>>> >>>>>>>> Note that it says that these C datatype names must be in all >>>>>>>> three >>>>>>>> language bindings. >>>>>>>> >>>>>>>> Are C MPI datatypes supposed to be available in Fortran? I >>>>>>>> looked >>>>>>>> in >>>>>>>> mpif.h for Open MPI, MPICH2, HP MPI, and Intel MPI, and I didn't >>>>>>>> see C >>>>>>>> MPI datatypes in there (e.g., MPI_INT and MPI_FLOAT). >>>>>>>> >>>>>>>> So: >>>>>>>> >>>>>>>> - is there language somewhere in MPI that says that C >>>>>>>> datatypes are >>>>>>>> not supposed to be in mpif.h? (and therefore the MPI-2.1 >>>>>>>> changelog >>>>>>>> is >>>>>>>> wrong) >>>>>>>> >>>>>>>> or >>>>>>>> >>>>>>>> - are all 4 of the above MPI's wrong for not including the C >>>>>>>> datatypes >>>>>>>> in mpif.h? >>>>>>>> >>>>>>>> --Jeff Squyres >>>>>>>> Cisco Systems >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> mpi-22 mailing list >>>>>>>> mpi-22_at_[hidden] <mailto:mpi-22_at_[hidden]> >>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >>>>>>>> >>>>>>>> <smime.p7s><ATT00001.txt> >>>>>> >>>>>> William Gropp >>>>>> Paul and Cynthia Saylor Professor of Computer Science >>>>>> University of Illinois Urbana-Champaign >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------ >>>>>> ------ >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> mpi-22 mailing list >>>>>> mpi-22_at_[hidden] >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >>>>>> >>>>> _______________________________________________ >>>>> mpi-22 mailing list >>>>> mpi-22_at_[hidden] >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >>>> >>>> >>>> --Jeff Squyres >>>> Cisco Systems >>>> >>>> >>>> _______________________________________________ >>>> mpi-22 mailing list >>>> mpi-22_at_[hidden] >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >>>> >> >> Dr. Rolf Rabenseifner . . . . . . . . . .. email >>rabenseifner_at_[hidden] >> High Performance Computing Center (HLRS) . phone >>++49(0)711/685-65530 >> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / >>685-65832 >> Head of Dpmt Parallel Computing . . . >>www.hlrs.de/people/rabenseifner >> Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) >> _______________________________________________ >> mpi-22 mailing list >> mpi-22_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > William Gropp > Paul and Cynthia Saylor Professor of Computer Science > University of Illinois Urbana-Champaign > > > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)

1 0

Re: [Mpi-22] MPI-2.1 ambiguity?
by unknown＠example.com 17 Jul '08

17 Jul '08

On Jul 17, 2008, at 10:03 AM, William Gropp wrote: > To make this perfectly clear, should the standard state that the > values of the predefined datatypes from another language are exactly > the same as the value produced by the handle conversion function? > E.g., in Fortran, the value of MPI_INT is what you would get from > MPI_TYPE_C2F( MPI_INT ) (where MPI_INT is the C version). It > should also state that just because Fortran defines MPI_LONG_LONG, > that does not imply that Fortran support an integer type that > corresponds to the C long long type. I think I agree with the idea (you can use MPI_INT in Fortran just like you would use MPI_INT in C just like you would use MPI::INT in C+ +), but your exact idea doesn't seem to work for C++. For example, what about MPI::INTEGER? I had assumed that the only use of MPI_INT in Fortran would be used for Fortran to pass a buffer to an MPI function that was pre-filled with int's in C (and other similar cases like this). Is that consistent with what you're suggesting? -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-22] MPI-2.1 ambiguity?
by unknown＠example.com 17 Jul '08

17 Jul '08

To make this perfectly clear, should the standard state that the values of the predefined datatypes from another language are exactly the same as the value produced by the handle conversion function? E.g., in Fortran, the value of MPI_INT is what you would get from MPI_TYPE_C2F( MPI_INT ) (where MPI_INT is the C version). It should also state that just because Fortran defines MPI_LONG_LONG, that does not imply that Fortran support an integer type that corresponds to the C long long type. Bill On Jul 17, 2008, at 4:03 AM, Rolf Rabenseifner wrote: > Hi all, > > The argument-chain was: > >>>> William Gropp wrote: >>>>> One piece of relevant text in MPI 2.0 is in section 4.12.6 (in >>>>> MPI-2.0) says that "All predefined datatypes can be used in >>>>> datatype constructors in any language." > [....] > > This text is supported also by: > MPI-2.0 Chap. 10.1.6 page 276 and > MPI-2.0 Annex B.2, page 344 define for all Fortran predefined > datatype handles as C++ counter-part. > > In the meeting, there was a consensus (?) that it is a bug > if an MPI implementation does not support, e.g. MPI_INT > in the mpif.h Fortran header file. > (This bug can be found, e.g., in MPICH-2 and will be fixed, > when I understood correctly) > > The value (not the name!!) of MPI_INT in mpif.h and mpi.h may be > different, as stated already in MPI-2.0, Sect. 4.12.9. > MPI_INT from C mpi.h cannot be used in a Fortran CALL MPI_SEND(...). > You need to convert, or you must use MPI_INT from Fortran mpif.h. > > (I.e. one may distiguish between mixed languages in > one MPI executable [addressed by MPI-2.0 Section 4.12.9], > and sending a message from a Fortran MPI executable to a C MPI > executable and vice versa [see MPI 2.0 Section 4.12.6].) > > Because this is already "clearly" defined in MPI-2.0, > you will not find any remark about this in the Change-Log > of MPI-2.1. > > MPI-2.2 may make it more clear in the revisiting of datatypes. > > Best regards > Rolf > > On Thu, 17 Jul 2008 10:20:28 +0200 > Hubert Ritzdorf <ritzdorf_at_it.neclab.eu> wrote: >> No, we didn't have them. The request to provide all C datatypes in >> Fortran was specified in one of the last meetings. When I remember >> correctly, it was specified in the last meeting in Chicago or >> the meeting before (I think it was specified together with item 33 >> of the change log). I implemented it together with the changes >> for MPI 2.1 since I assumed that it was contained also in the >> change log. After your mail, I recognized that it is only implicitly >> mentioned by item 33. >> >> Hubert >> >> Jeff Squyres wrote: >>> What does NEC MPI do -- do you have MPI_INT and MPI_FLOAT (etc.) in >>> mpif.h? >>> >>> >>> On Jul 16, 2008, at 12:57 PM, Hubert Ritzdorf wrote: >>> >>>> What's about the C++ datatypes for complex ? >>>> MPI_COMPLEX and MPI_Double_Complex are already defined for Fortran >>>> datatypes. The complex Fortran datatypes within C++ have a >>>> special >>>> name in order to avoid a name collision. >>>> >>>> Hubert >>>> >>>> William Gropp wrote: >>>>> One piece of relevant text in MPI 2.0 is in section 4.12.6 (in >>>>> MPI-2.0) says that "All predefined datatypes can be used in >>>>> datatype >>>>> constructors in any language." However, the example uses >>>>> MPI_Type_f2c ton convert the Fortran handle to the C version >>>>> before >>>>> passing it into the MPI_Type_create_struct routine, so this text >>>>> could be interpreted as allowing the use of those datatypes >>>>> through >>>>> the handle conversion mechanism without requiring them to be >>>>> defined >>>>> in each languages header file. Presumably the requirement is that >>>>> they be predefined with the value that you'd get from the handle >>>>> conversion function? >>>>> >>>>> Bill >>>>> >>>>> On Jul 16, 2008, at 8:18 AM, Hubert Ritzdorf wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> when I remember correctly, it was decided to provide the C MPI >>>>>> datatypes >>>>>> in Fortran since >>>>>> the Fortran datatypes are supported in C and C++. >>>>>> >>>>>> Hubert >>>>>> >>>>>> Jeff Squyres wrote: >>>>>>> I will file a proposal about this if there is a problem, but I >>>>>>> wanted >>>>>>> to ask the group before I did so. In the changelog for MPI-2.1: >>>>>>> >>>>>>> 2. Section 3.2.2 on page 27, Section 16.1.6 on page 453, and >>>>>>> Annex >>>>>>> A.1 >>>>>>> on page 491. >>>>>>> MPI_LONG_LONG_INT, MPI_LONG_LONG (as synonym), >>>>>>> MPI_UNSIGNED_LONG_LONG, >>>>>>> MPI_SIGNED_CHAR, and MPI_WCHAR are moved from optional to >>>>>>> oï¬cial >>>>>>> and they >>>>>>> are therefore deï¬ned for all three language bindings. >>>>>>> >>>>>>> Note that it says that these C datatype names must be in all >>>>>>> three >>>>>>> language bindings. >>>>>>> >>>>>>> Are C MPI datatypes supposed to be available in Fortran? I >>>>>>> looked >>>>>>> in >>>>>>> mpif.h for Open MPI, MPICH2, HP MPI, and Intel MPI, and I didn't >>>>>>> see C >>>>>>> MPI datatypes in there (e.g., MPI_INT and MPI_FLOAT). >>>>>>> >>>>>>> So: >>>>>>> >>>>>>> - is there language somewhere in MPI that says that C >>>>>>> datatypes are >>>>>>> not supposed to be in mpif.h? (and therefore the MPI-2.1 >>>>>>> changelog >>>>>>> is >>>>>>> wrong) >>>>>>> >>>>>>> or >>>>>>> >>>>>>> - are all 4 of the above MPI's wrong for not including the C >>>>>>> datatypes >>>>>>> in mpif.h? >>>>>>> >>>>>>> --Jeff Squyres >>>>>>> Cisco Systems >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> mpi-22 mailing list >>>>>>> mpi-22_at_[hidden] <mailto:mpi-22_at_[hidden]> >>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >>>>>>> >>>>>>> <smime.p7s><ATT00001.txt> >>>>> >>>>> William Gropp >>>>> Paul and Cynthia Saylor Professor of Computer Science >>>>> University of Illinois Urbana-Champaign >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------ >>>>> ------ >>>>> >>>>> >>>>> _______________________________________________ >>>>> mpi-22 mailing list >>>>> mpi-22_at_[hidden] >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >>>>> >>>> _______________________________________________ >>>> mpi-22 mailing list >>>> mpi-22_at_[hidden] >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >>> >>> >>> --Jeff Squyres >>> Cisco Systems >>> >>> >>> _______________________________________________ >>> mpi-22 mailing list >>> mpi-22_at_[hidden] >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >>> > > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 William Gropp Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign *

1 0

Re: [Mpi-22] MPI-2.1 ambiguity?
by unknown＠example.com 17 Jul '08

17 Jul '08

Hi all, The argument-chain was: >>> William Gropp wrote: >>>> One piece of relevant text in MPI 2.0 is in section 4.12.6 (in >>>> MPI-2.0) says that "All predefined datatypes can be used in >>>> datatype constructors in any language." [....] This text is supported also by: MPI-2.0 Chap. 10.1.6 page 276 and MPI-2.0 Annex B.2, page 344 define for all Fortran predefined datatype handles as C++ counter-part. In the meeting, there was a consensus (?) that it is a bug if an MPI implementation does not support, e.g. MPI_INT in the mpif.h Fortran header file. (This bug can be found, e.g., in MPICH-2 and will be fixed, when I understood correctly) The value (not the name!!) of MPI_INT in mpif.h and mpi.h may be different, as stated already in MPI-2.0, Sect. 4.12.9. MPI_INT from C mpi.h cannot be used in a Fortran CALL MPI_SEND(...). You need to convert, or you must use MPI_INT from Fortran mpif.h. (I.e. one may distiguish between mixed languages in one MPI executable [addressed by MPI-2.0 Section 4.12.9], and sending a message from a Fortran MPI executable to a C MPI executable and vice versa [see MPI 2.0 Section 4.12.6].) Because this is already "clearly" defined in MPI-2.0, you will not find any remark about this in the Change-Log of MPI-2.1. MPI-2.2 may make it more clear in the revisiting of datatypes. Best regards Rolf On Thu, 17 Jul 2008 10:20:28 +0200 Hubert Ritzdorf <ritzdorf_at_it.neclab.eu> wrote: > No, we didn't have them. The request to provide all C datatypes in >Fortran was specified in one of the last meetings. When I remember > correctly, it was specified in the last meeting in Chicago or > the meeting before (I think it was specified together with item 33 > of the change log). I implemented it together with the changes > for MPI 2.1 since I assumed that it was contained also in the > change log. After your mail, I recognized that it is only implicitly > mentioned by item 33. > > Hubert > > Jeff Squyres wrote: >> What does NEC MPI do -- do you have MPI_INT and MPI_FLOAT (etc.) in >> mpif.h? >> >> >> On Jul 16, 2008, at 12:57 PM, Hubert Ritzdorf wrote: >> >>> What's about the C++ datatypes for complex ? >>> MPI_COMPLEX and MPI_Double_Complex are already defined for Fortran >>> datatypes. The complex Fortran datatypes within C++ have a special >>> name in order to avoid a name collision. >>> >>> Hubert >>> >>> William Gropp wrote: >>>> One piece of relevant text in MPI 2.0 is in section 4.12.6 (in >>>> MPI-2.0) says that "All predefined datatypes can be used in datatype >>>> constructors in any language." However, the example uses >>>> MPI_Type_f2c ton convert the Fortran handle to the C version before >>>> passing it into the MPI_Type_create_struct routine, so this text >>>> could be interpreted as allowing the use of those datatypes through >>>> the handle conversion mechanism without requiring them to be defined >>>> in each languages header file. Presumably the requirement is that >>>> they be predefined with the value that you'd get from the handle >>>> conversion function? >>>> >>>> Bill >>>> >>>> On Jul 16, 2008, at 8:18 AM, Hubert Ritzdorf wrote: >>>> >>>>> Hi, >>>>> >>>>> when I remember correctly, it was decided to provide the C MPI >>>>> datatypes >>>>> in Fortran since >>>>> the Fortran datatypes are supported in C and C++. >>>>> >>>>> Hubert >>>>> >>>>> Jeff Squyres wrote: >>>>>> I will file a proposal about this if there is a problem, but I >>>>>>wanted >>>>>> to ask the group before I did so. In the changelog for MPI-2.1: >>>>>> >>>>>> 2. Section 3.2.2 on page 27, Section 16.1.6 on page 453, and Annex >>>>>> A.1 >>>>>> on page 491. >>>>>> MPI_LONG_LONG_INT, MPI_LONG_LONG (as synonym), >>>>>> MPI_UNSIGNED_LONG_LONG, >>>>>> MPI_SIGNED_CHAR, and MPI_WCHAR are moved from optional to oï¬cial >>>>>> and they >>>>>> are therefore deï¬ned for all three language bindings. >>>>>> >>>>>> Note that it says that these C datatype names must be in all three >>>>>> language bindings. >>>>>> >>>>>> Are C MPI datatypes supposed to be available in Fortran? I looked >>>>>>in >>>>>> mpif.h for Open MPI, MPICH2, HP MPI, and Intel MPI, and I didn't >>>>>> see C >>>>>> MPI datatypes in there (e.g., MPI_INT and MPI_FLOAT). >>>>>> >>>>>> So: >>>>>> >>>>>> - is there language somewhere in MPI that says that C datatypes are >>>>>> not supposed to be in mpif.h? (and therefore the MPI-2.1 changelog >>>>>>is >>>>>> wrong) >>>>>> >>>>>> or >>>>>> >>>>>> - are all 4 of the above MPI's wrong for not including the C >>>>>> datatypes >>>>>> in mpif.h? >>>>>> >>>>>> --Jeff Squyres >>>>>> Cisco Systems >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> mpi-22 mailing list >>>>>> mpi-22_at_[hidden] <mailto:mpi-22_at_[hidden]> >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >>>>>> >>>>>> <smime.p7s><ATT00001.txt> >>>> >>>> William Gropp >>>> Paul and Cynthia Saylor Professor of Computer Science >>>> University of Illinois Urbana-Champaign >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> _______________________________________________ >>>> mpi-22 mailing list >>>> mpi-22_at_[hidden] >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >>>> >>> _______________________________________________ >>> mpi-22 mailing list >>> mpi-22_at_[hidden] >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >> >> >> --Jeff Squyres >> Cisco Systems >> >> >> _______________________________________________ >> mpi-22 mailing list >> mpi-22_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)

1 0