September 2008 - mpiwg-fortran - mailman3.cels.anl.gov

Re: [MPI3 Fortran] Higher-level libraries (was: Non-contiguous arrays)
by Aleksandar Donev 19 Sep '08

19 Sep '08

On Friday 19 September 2008 08:48, Jeff Squyres wrote: > Putting this stuff in the MPI standard was not seen as suitable ï¿½ > because it effectively defines a new/second MPI standard that is ï¿½ > specific to a single language. ï¿½I still agree with this decision. Sure. But that does not preclude the committee from supporting additional documents, e.g., technical reports describing side components. > Instead, the idea is to provide building blocks in the bindings, and > provide enough hooks for upper-layer library and language authors to > be able to do whatever higher-level concepts they want to do That is all fine, but I think you are missing an important point that many C/C++ programmers do. C/C++ may have been designed to do "low-level" libraries (thus C++ has all that expressive but untamed power). Fortran is not a low-level language, nor was it ever (F77 is simply old, so it may seem low-level, but at the time it was high-level). It is not meant to shift around memory ala C pointers. So while > avoid requiring > specifying the MPI datatype when it's easy/cheap for the library to > figure it out itself may seem to you like a convenience, it is actually a requirement in statically-typed and mostly type-safe Fortran. One does not just pass memory addresses and then move around bits in Fortran and do wild type-casts. I understand that MPI does not need to be implemented in Fortran and it can do these things internally. But worse than that, a model for MPI based on the C machine model (linear memory etc.) does not fit Fortran, which by design is higher level than that. So it may simply be impossible to design a Fortran interface that is in accord with the Fortran standard AND looks like the C binding. You can of course fake it, as people have for a long time... Best, Aleks -- Aleksandar Donev, Ph.D. Lawrence Postdoctoral Fellow @ Lawrence Livermore National Laboratory High Performance Computational Materials Science and Chemistry E-mail: donev1(a)llnl.gov Phone: (925) 424-6816 Fax: (925) 423-0785 Address: P.O.Box 808, L-367, Livermore, CA 94551-9900 Web: http://cherrypit.princeton.edu/donev

1 0

[MPI3 Fortran] Higher-level libraries (was: Non-contiguous arrays)
by Jeff Squyres 19 Sep '08

19 Sep '08

On Sep 19, 2008, at 11:31 AM, Supalov, Alexander wrote: > I don't think taking advanced interface discussion to another list > will > help that interface in the end. However beautiful the result will be, > until it's blessed by the Forum, it'll have fundamental handicap. > > If that's practicable, it would be better to draw the OOMPI and Boost > MPI C++ into the fold and finally drive into the standard something > that > looks like a good C++ interface for MPI. Same with Fortran. There was significant resistance to this idea in 1995-6 -- it's the reason that OOMPI was not blessed as the official C++ MPI bindings, and instead, we went with bindings that are pretty much a 1:1 match for the C bindings. The reason is that OOMPI / Boost.MPI / etc. add different definitions and semantics over the bottom layer MPI bindings. As such, it's basically a different communications package -- it has [sometimes significantly] different rules and behavior than "core" MPI. Putting this stuff in the MPI standard was not seen as suitable because it effectively defines a new/second MPI standard that is specific to a single language. I still agree with this decision. Instead, the idea is to provide building blocks in the bindings, and provide enough hooks for upper-layer library and language authors to be able to do whatever higher-level concepts they want to do (like OOMPI, Boost.MPI, ...etc.). Remember that one of MPI's primary objectives is to be a foundation for higher-level libraries. I think that the same ideas would also be appropriate for an advanced Fortran MPI library -- use some of the power of the language to do things that a) programmers of that language expect (e.g., avoid requiring specifying the MPI datatype when it's easy/cheap for the library to figure it out itself) and b) are outside the scope of the definitions that MPI provides. FWIW: bringing these libraries under the umbrella of the MPI Forum (even if they're not in the One True MPI Standard) may be difficult because of the nature of the communities that develop them. Boost is a huge community with its own set of rules, guidelines, and goals -- they're not necessarily the same as the MPI Forum's rules, guidelines, and goals. All that being said, I do understand your point of "if it's not in the [or "a"] standard, it'll prevent wide adoption." -- Jeff Squyres Cisco Systems

1 0

Re: [MPI3 Fortran] Argument data sizes
by Jeff Squyres 19 Sep '08

19 Sep '08

On Sep 18, 2008, at 2:02 PM, Bill Long wrote: >> Let's also acknowledge that a significant "artificial constraint" >> is backwards compatibility for existing applications. We can't >> just change all the C bindings to make the millions of lines of MPI >> code out there no longer be compilable. > > I agree that backward compatibility is a good thing. However, are > not the C bindings insulated from this? If the new interface > specifies intptr_t for the count argument, and the existing program > supplies an int (conforming to the old standard) the argument will > be automatically promoted in the caller. I guess I don't see a > problem there. I am happy to talk about backward compatibility and why it can be a problem in the context of the larger MPI Forum discussion about this issue. -- Jeff Squyres Cisco Systems

1 0

Re: [MPI3 Fortran] Non-contiguous arrays (was Re: Argument datasizes)
by Supalov, Alexander 19 Sep '08

19 Sep '08

Hi, I don't think taking advanced interface discussion to another list will help that interface in the end. However beautiful the result will be, until it's blessed by the Forum, it'll have fundamental handicap. If that's practicable, it would be better to draw the OOMPI and Boost MPI C++ into the fold and finally drive into the standard something that looks like a good C++ interface for MPI. Same with Fortran. Best regards. Alexander -----Original Message----- From: mpi3-fortran-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Craig Rasmussen Sent: Friday, September 19, 2008 5:25 PM To: MPI-3 Fortran working group Subject: Re: [MPI3 Fortran] Non-contiguous arrays (was Re: Argument datasizes) On Sep 18, 2008, at 11:40 AM, Aleksandar Donev wrote: > On Thursday 18 September 2008 10:28, Iain Bason wrote: > >> Didn't this come up in another thread? > Yes :-) >> In Fortran, you can use >> assumed shape arrays to pass these sorts of data without copying. It >> would be nice if MPI could take advantage of that in order to make >> life easier for Fortran programmers. > It can, after we publish the Interop TR currently being worked on by > J3. It > would allow for declarations such as: > > TYPE(*), DIMENSION(..) :: buffer > > which would pass an array descriptor for buffer that can then be > parsed even > by third-party libraries and a copy avoided. This would, however, as > Jeff > said, be new *functionality* that we would be adding on top of the > base MPI > standard. As such, it should probably be in addition or on top of > the basic > Fortran binding which merely translates the MPI standard. Jeff Squyres and I also had a long talk about a higher-level MPI API for Fortran. I think this is a good thing to consider and I'm interesting in helping to write a reference implementation. However, it is really outside of the scope of this committee. Our current goal is to provide new Fortran bindings that resolve problems with the current Fortran bindings, but in doing so, don't stray too far off from the MPI spec. However, regarding high-level Fortran interfaces, I'm planning on scheduling a teleconference with Douglas Gregor who in involved with the Boost MPI C++ library. I announce more details when I get it set up. If needs be we can take discussion of this high-level interface to another email group. Cheers, Craig _______________________________________________ mpi3-fortran mailing list mpi3-fortran(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

1 0

Re: [MPI3 Fortran] Non-contiguous arrays (was Re: Argument data sizes)
by Craig Rasmussen 19 Sep '08

19 Sep '08

On Sep 18, 2008, at 11:40 AM, Aleksandar Donev wrote: > On Thursday 18 September 2008 10:28, Iain Bason wrote: > >> Didn't this come up in another thread? > Yes :-) >> In Fortran, you can use >> assumed shape arrays to pass these sorts of data without copying. It >> would be nice if MPI could take advantage of that in order to make >> life easier for Fortran programmers. > It can, after we publish the Interop TR currently being worked on by > J3. It > would allow for declarations such as: > > TYPE(*), DIMENSION(..) :: buffer > > which would pass an array descriptor for buffer that can then be > parsed even > by third-party libraries and a copy avoided. This would, however, as > Jeff > said, be new *functionality* that we would be adding on top of the > base MPI > standard. As such, it should probably be in addition or on top of > the basic > Fortran binding which merely translates the MPI standard. Jeff Squyres and I also had a long talk about a higher-level MPI API for Fortran. I think this is a good thing to consider and I'm interesting in helping to write a reference implementation. However, it is really outside of the scope of this committee. Our current goal is to provide new Fortran bindings that resolve problems with the current Fortran bindings, but in doing so, don't stray too far off from the MPI spec. However, regarding high-level Fortran interfaces, I'm planning on scheduling a teleconference with Douglas Gregor who in involved with the Boost MPI C++ library. I announce more details when I get it set up. If needs be we can take discussion of this high-level interface to another email group. Cheers, Craig

1 0

Re: [MPI3 Fortran] Argument data sizes
by Bill Long 18 Sep '08

18 Sep '08

Craig Rasmussen wrote: > > However, it is within our purview to discuss how to best represent > this size in Fortran. I'm going to take a straw poll on this matter. > Please choose one of the following choices: > > 1. A constant kind value defined by the implementation, e.g., > MPI_SIZE_KIND, > integer(MPI_SIZE_KIND) :: count > It is expected that MPI_SIZE_KIND be the same kind as a default > integer > This one is appealing, except I'd prefer that the "it is expected" bit specify C_intptr_t. ------------------------------------------- On Sep 18, 2008, at 5:10 PM, Jeff Squyres wrote: >What do Fortran app developers / usually do in this case? Do they ship multiple versions of their libraries? Or do they tend to only support either -i4 or >-i8 (but not both)? I've seen both ways used. As noted earlier, if the user specifies -i8, the compiler can automatically find the right library if it is part of the programming environment package. (Actually, we only allow the case where both -r8 and -i8 are specified, not just one.) The library I'm personally involved with is more rigid. All of the dummy arguments have explicit kind values and there is a module that the user has to use (since the library procedures are module procedures). If the user supplies the wrong kind of argument, he gets an error. >Does it happen often/ever that there's multiple libraries that must be linked together in a single application, and not all of them are available at the same -iX >value? The compiler can detect if a module was compiled with different -i8 / -r8 switches compared to the procedure using the module. This catches a lot of errors up front. If the program is linked with -i8 -r8, the load path is automatically adjusted to point to the 64-bit versions of vendor supplied libraries. Apart from that, the user is responsible for linking in the right library if there are multiple versions. In general, the use of switches like -i8 and -r8 is mainly a legacy issue. Newer codes tend to have a 'precision' module that defines symbolic names for the desired integer and real kinds, and all the declarations use these. They also use IMPLICIT NONE to avoid missing a variable declaration. Cheers, Bill -- Bill Long longb(a)cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120

1 0

Re: [MPI3 Fortran] Argument data sizes
by Supalov, Alexander 18 Sep '08

18 Sep '08

Hi, I'm afraid that the proposed straw vote mixes up two things: 1) The need to handle 64-bit integers (say, if the user says -i8) 2) The need to handle 64-bit count arguments (which may be necessary even if other ints are 32-bit) For purpose 1), it looks like option 4) - default integers - are the best way, as Aleks said, whatever happens under the hood. For purpose 2), I'm voting for option 1). Note however that this is actually a part of another discussion that we should wait the Forum decision upon, and offer our opinion on the most appropriate Fortran interface. Best regards. Alexander -----Original Message----- From: mpi3-fortran-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Craig Rasmussen Sent: Thursday, September 18, 2008 10:42 PM To: longb(a)cray.com; MPI-3 Fortran working group Subject: Re: [MPI3 Fortran] Argument data sizes On Sep 18, 2008, at 9:15 AM, Bill Long wrote: > > > Jeff Squyres wrote: >> On Sep 18, 2008, at 9:36 AM, Iain Bason wrote: >> >>>> So it isn't that we need the count to be able to convey a huge >>>> number, it's that the absence of an interface that accepts an 8 >>>> byte count makes it more difficult to write portable programs. >> >> Yes, I understand that, but if MPI itself doesn't accept counts >> (and other parameter values) larger than what can be represented by >> a C int, what does allowing an INTEGER*8 in the MPI Fortran >> interface mean? > > But essentially all modern processors use 64-bit addressing. If a C > int is 32 bits, then this restriction is a basic design flaw in MPI > that needs to be fixed. Either that or a C int needs to be 64 > bits. (The earlier discussion about default64 switches originated > with legacy supercomputers where, indeed, the default integer in > Fortran AND C int were 64 bits, so there was no internal > inconsistency.) Getting MPI to force a change on the C standard is > probably out of scope. However, fixing the MPI spec to mandate that > count arguments be of type int64_t, or perhaps better, intptr_t, is > quite reasonable, and recognizes modern reality. > Jeff and I had a talk about several of the issues on the table and I've agreed to summarize. I'll do this by responding to the various threads directly. Bill raises an excellent point regarding the size of something that essentially reflects the amount of memory on a machine. However, this is not in the scope of this group. So any discussion regarding this should be taken up with the wider forum who is considering this topic. However, it is within our purview to discuss how to best represent this size in Fortran. I'm going to take a straw poll on this matter. Please choose one of the following choices: 1. A constant kind value defined by the implementation, e.g., MPI_SIZE_KIND, integer(MPI_SIZE_KIND) :: count It is expected that MPI_SIZE_KIND be the same kind as a default integer 2. Similar to 1. expect the kind value is C_INT 3. Use overloading to select use either (effectively) a C int or a C long. I don't think this will work with default integer dummies 4. Use default integer, write the wrapper in Fortran, and use assignment to cast the integer to C_INT. I vote #1 as it provides the most flexibility to the implementer and the compiler will give an error if the programmer does something stupid. Cheers, Craig _______________________________________________ mpi3-fortran mailing list mpi3-fortran(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

1 0

Re: [MPI3 Fortran] Argument data sizes
by Lionel, Steve 18 Sep '08

18 Sep '08

Most Fortran libraries I have seen support only one size of integer. My personal preference is for an MPI_xxx kind value that (typically) maps to C_INTPTR_T. Steve Lionel Developer Products Division Intel Corporation Nashua, NH > -----Original Message----- > From: mpi3-fortran-bounces(a)lists.mpi-forum.org [mailto:mpi3-fortran- > bounces(a)lists.mpi-forum.org] On Behalf Of Jeff Squyres > Sent: Thursday, September 18, 2008 5:17 PM > To: MPI-3 Fortran working group > Subject: Re: [MPI3 Fortran] Argument data sizes > Importance: Low > > On Sep 18, 2008, at 5:10 PM, Jeff Squyres wrote: > > > It seems like this comes back down to the whole "multiple language > > interoperability" set of issues again. :-) > > > I take that back -- this is not a multi-language issue. You have the > same issue if you compile a Fortran library with -i8 and you compile > you app (that uses that library) without -i8. > > What do Fortran app developers / usually do in this case? Do they > ship multiple versions of their libraries? Or do they tend to only > support either -i4 or -i8 (but not both)? > > Does it happen often/ever that there's multiple libraries that must be > linked together in a single application, and not all of them are > available at the same -iX value? > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran

1 0

Re: [MPI3 Fortran] Argument data sizes
by Jeff Squyres 18 Sep '08

18 Sep '08

On Sep 18, 2008, at 5:10 PM, Jeff Squyres wrote: > It seems like this comes back down to the whole "multiple language > interoperability" set of issues again. :-) I take that back -- this is not a multi-language issue. You have the same issue if you compile a Fortran library with -i8 and you compile you app (that uses that library) without -i8. What do Fortran app developers / usually do in this case? Do they ship multiple versions of their libraries? Or do they tend to only support either -i4 or -i8 (but not both)? Does it happen often/ever that there's multiple libraries that must be linked together in a single application, and not all of them are available at the same -iX value? -- Jeff Squyres Cisco Systems

1 0

Re: [MPI3 Fortran] Argument data sizes
by Jeff Squyres 18 Sep '08

18 Sep '08

On Sep 18, 2008, at 5:02 PM, Aleksandar Donev wrote: >> I also vote #1, but I'm probably the least informed on this thread as >> to what real Fortran programmers want. > Perhaps this straw vote should use preference-based ranking. I am > not opposed > to #1. I don't see the difference between 1 and 2. I dislike 3--- > generic > overloading should be reserved for meaningful uses (such as changing > argument > lists), not this kind of silliness, IMO. Fair enough. I agree; #1 and #2 are pretty much the same. I prefer the MPI_* prefix on the name, but only because we have a precedent for that already. I like the fact that implementations would have a mechanism to increase the size in future versions, probably without harming user codes (this is part of the problem with increasing the count size in the C bindings). #3 is also icky, but it would prevent providers having to ship 2 libraries. I dislike #4 (i.e., the current state of today) because it effectively introduces an ambiguity in the interface (because compilers can adjust the default size of INTEGER). Sure, we providers *can* ship multiple libraries, but it's pretty weird that we would have to do so. Fixing the width to some value -- any value -- would remove this ambiguity and create firm interface contracts that don't change with specific compiler options. It seems like this comes back down to the whole "multiple language interoperability" set of issues again. :-) Just my $0.00000000001. -- Jeff Squyres Cisco Systems

1 0