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

Re: [MPI3 Fortran] Argument data sizes
by Aleksandar Donev 18 Sep '08

18 Sep '08

On Thursday 18 September 2008 13:57, Jeff Squyres 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. Aleks

1 0

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

18 Sep '08

On Sep 18, 2008, at 4:42 PM, 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 > > 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. I also vote #1, but I'm probably the least informed on this thread as to what real Fortran programmers want. :-) -- Jeff Squyres Cisco Systems

1 0

Re: [MPI3 Fortran] Argument data sizes
by Aleksandar Donev 18 Sep '08

18 Sep '08

On Thursday 18 September 2008 13:42, Craig Rasmussen wrote: > 4. Use default integer, write the wrapper in Fortran, and use ï¿½ > assignment to cast the integer to C_INT. I vote for this, but please delete everything after the first comma. Your OpenMPI implementation can do that under the covers---we are talking about a standard here and all it says is "default integer" (deal with it somehow please). > 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. Not really. Fortran does not have stronly-typed type-aliases. So if MPI_SIZE_KIND happens to be equal to default integer, a code will work. It will break with -i8. It does force a careful programmer to write the kind explicitly, but bad programmers and existing codes will still be just as "stupid". Best, Aleks

1 0

Re: [MPI3 Fortran] Argument data sizes
by Craig Rasmussen 18 Sep '08

18 Sep '08

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

1 0

Re: [MPI3 Fortran] Non-contiguous arrays (was Re: Argument data sizes)
by Aleksandar Donev 18 Sep '08

18 Sep '08

On Thursday 18 September 2008 10:44, Aleksandar Donev wrote: > For the non-blocking, a copy is technically allowed (and > should be) I meant blocking in this sentence. Aleks

1 0

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

18 Sep '08

Jeff Squyres 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. > > Let's be fair -- *parallel programming* is hard. Yes, certainly true. > MPI fits some kinds of parallel program models very well; MPI is a bad > match for other kinds of parallel program models. The same can be > said for all parallel programming systems. I think the last 20+ years > have shown that there is no one-size-fits-all for parallel programming. After many years of attrition, the still standing parallel models seem to be shared memory (OpenMP, which works for small numbers of processors) and SPMD (overwhelmingly MPI, which scales to large systems). The hardest part of an SPMD program is designing the data layout and synchronizing the processors. For a Fortran programmer like me, MPI is still an awkward way to express the resulting design. But that's the best option most people have at this point. 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] Non-contiguous arrays (was Re: Argument data sizes)
by Aleksandar Donev 18 Sep '08

18 Sep '08

On Thursday 18 September 2008 10:35, Supalov, Alexander wrote: > I think, technically, copy-in/out might occur on the subroutine boundary > in this case. A copy in/out can formally be disallowed by adding the TARGET, VOLATILE, or ASYNCHRONOUS attribute on the dummy and on the actual. For the non-blocking calls, this is what we should do (I would argue for both TARGET and VOLATILE---it is only in the interface so it doesn't affect any optimization). For the non-blocking, a copy is technically allowed (and should be), but no sane compiler would do it for a 32GB array (or if it does, it will stop doing that when the customers call). Also note that Fortran 2008 has a new CONTIGUOUS attribute which may be useful in the MPI interface (or the "Modern Fortran MPI Interface" that Craig and I mentioned already)... 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

Re: [MPI3 Fortran] Non-contiguous arrays (was Re: Argument data sizes)
by Bill Long 18 Sep '08

18 Sep '08

Iain Bason wrote: > > On Sep 18, 2008, at 1:13 PM, Jeff Squyres wrote: > >> How else would you do it efficiently for non-contiguous datatypes >> without a copy (which would be quite Bad for multiple reasons, >> especially for very large datasets)? Such issues are certainly not >> unique to C (even in very large Fortran arrays, particularly if you >> want to send just a plane from the middle of a 3D array, or >> somesuch). As another example of where datatypes are useful: with >> the Fortran equivalent of C structs, you need to build up a composed >> datatype to describe the message that you want to send/receive. > > Didn't this come up in another thread? 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. The extensions being proposed for Fortran/C interoperability help with this. The user can specify bind(c) on an interface with an assumed-shape argument. Or an assumed-rank argument, with the dimension(..) syntax. The argument gets passed as a descriptor (the address of the descriptor for the C folk) and the vendor supplies C library routines that let the C callee extract information from the descriptor about the described array, like base address, element size, rank, bounds/strides.... A C wrapper could decode this information and send/receive the data in as many contiguous chunks as required, all hidden from the Fortran user. Cheers, Bill > > Iain > -- 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] Non-contiguous arrays (was Re: Argument data sizes)
by Aleksandar Donev 18 Sep '08

18 Sep '08

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. Best, Aleks

1 0

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

18 Sep '08

I think, technically, copy-in/out might occur on the subroutine boundary in this case. This is one of the big problems, especially for the nonblocking calls like MPI_Isend/Irecv. -----Original Message----- From: mpi3-fortran-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Iain Bason Sent: Thursday, September 18, 2008 7:28 PM To: MPI-3 Fortran working group Subject: [MPI3 Fortran] Non-contiguous arrays (was Re: Argument data sizes) On Sep 18, 2008, at 1:13 PM, Jeff Squyres wrote: > How else would you do it efficiently for non-contiguous datatypes > without a copy (which would be quite Bad for multiple reasons, > especially for very large datasets)? Such issues are certainly not > unique to C (even in very large Fortran arrays, particularly if you > want to send just a plane from the middle of a 3D array, or > somesuch). As another example of where datatypes are useful: with > the Fortran equivalent of C structs, you need to build up a composed > datatype to describe the message that you want to send/receive. Didn't this come up in another thread? 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. Iain _______________________________________________ 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