March 2010 - mpiwg-fortran - mailman3.cels.anl.gov

Re: [MPI3 Fortran] Results of San Jose Forum meeting
by Aleksandar Donev 11 Mar '10

11 Mar '10

Hi, You guys have been busy but unfortunately I do not see much progress, sorry. On Thursday 11 March 2010, Bill Long wrote: > type,bind(c) :: MPI_Comm > integer(c_int) :: val > end type MPI_Comm If indeed someone insists on specifying the internals, use: INTEGER(MPI_COMM) :: handle What on earth is wrong with that? Striving for type-safety and striving to: > One advantage of the integer flag values is that it avoids interface > issues when we change the pointer size. are at odds with one another. It is like saying a typealias provides type safety. It does not, only *subtyping* does, which Fortran does not have. A derived type with one integer component is, in Fortran, and almost in C, soo different from an integer that it is not worth trying to pretend they are the same thing. Sticking SEQUENCE will do nothing for a type of only one single component, either in practice or in theory. BIND(C), as Bill proposes, is infinitely better, if someone insists on a derived type (for type safety or whatever reasons). Best, Aleks -- Aleksandar Donev, Ph.D. Luis W. Alvarez Postdoctoral Fellow Center for Computational Sciences and Engineering (https://ccse.lbl.gov) Lawrence Berkeley National Laboratory (http://www.lbl.gov) E-mail: adonev(a)lbl.gov Phone: (510) 486-5782 Fax: (510) 486-6900 Address: MS 50A-1148, LBL, 1 Cyclotron Rd., Berkeley, CA 94720 Web: http://cims.nyu.edu/~donev/

1 0

Re: [MPI3 Fortran] Results of San Jose Forum meeting
by Bill Long 11 Mar '10

11 Mar '10

Iain Bason wrote: > On Mar 11, 2010, at 11:59 AM, N.M. Maclaren wrote: >> In particular, Rolf and Craig, what are the facilities for doing that >> in NAG, gfortran, Intel, Sun and Pathscale? I can check all of those. > > Sun has the IGNORE_TKR pragma: > > http://docs.sun.com/app/docs/doc/820-7600/aevph?a=view > Cray has the same directive (most likely because I pointed the Sun J3 rep to our documentation for this several years ago). Pathscale also uses this directive, having inherited their front end from us a decade ago. 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] Results of San Jose Forum meeting
by Jeff Squyres 11 Mar '10

11 Mar '10

On Mar 11, 2010, at 9:41 AM, N.M. Maclaren wrote: > > There certainly is an elegance to having no MPI handle conversion > > functions between use mpi/use mpi3/mpif.h. It would have been nice to > > avoid the lookup, but a) the cost really doesn't matter, and b) I think > > the usability issue is nice (i.e., assignment), even if none of the other > > benefits work out. But I'm not tied strongly to either way. > > I don't find that having to define the internals of a derived type any > more elegant than defining two functions (or a single subroutine). It's not 2 functions/1 subroutine -- it's probably twice that because there's now 3 types of handles: - mpif.h / use mpi: INTEGER - use mpi3: some derived type - C Keeping the underlying Fortran handle type as INTEGER was simple, but encasing it in a derived type provided the type safety. Additionally, Rolf thought that using SEQUENCE with no other fields might allow us to have 2 interface files but one back-end implementation for both the mpi and mpi3 modules. Per a prior question on this thread, the thought was to use BIND(C) to bind both routines to a back-end C routine, but still have an INTEGER type for the member so that Fortran codes could do the assignment from mpif.h/use mpi handles with no funky casting. The C function would then simply ensure to use a C integer type that was compatible with INTEGER (Open MPI, for example, uses configure tests to setup MPI_Fint to be the Right size). Then the C routine would do the lookup on the INTEGER (MPI_Fint) to get the appropriate C MPI handle and then go on from there. -- 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] Results of San Jose Forum meeting
by Lionel, Steve 11 Mar '10

11 Mar '10

> In particular, Rolf and Craig, what are the facilities for doing that > in NAG, gfortran, Intel, Sun and Pathscale? I can check all of those. Intel has the ATTRIBUTES NO_ARG_CHECK directive. Steve Lionel Developer Products Division Systems and Solutions Group Intel Corporation Nashua, NH

1 0

Re: [MPI3 Fortran] Results of San Jose Forum meeting
by Iain Bason 11 Mar '10

11 Mar '10

On Mar 11, 2010, at 11:59 AM, N.M. Maclaren wrote: > On Mar 11 2010, Jeff Squyres wrote: >>> > - Make the explicit interfaces in "use mpi" be *required* by >>> MPI >>> > implementations (they are optional right now). This is now >>> > possible because of the (void*)-like behavior that is >>> available >>> > in all Fortran compilers. >>> Are you SURE? I am pretty sure that many don't, and won't do for a >>> while. >> >> Rolf and Craig assured me that this was so -- so I defer to you >> experts. Keep in mind that their assurance to me was predicated >> that compilers may have *vendor-specific* mechanisms; they may not >> be the standard/blessed mechanism (yet). >> >> But if this is not true, then the whole plan is suspect. > > Indeed. I doubt very much that NAG has, and I can't find such a > facility > in the several vendors' documentation I have looked at, which doesn't > mean that it's not there and undocumented. But relying on > undocumented > facilities is risky, even if they all had it. > > In particular, Rolf and Craig, what are the facilities for doing that > in NAG, gfortran, Intel, Sun and Pathscale? I can check all of those. Sun has the IGNORE_TKR pragma: http://docs.sun.com/app/docs/doc/820-7600/aevph?a=view Iain

1 0

Re: [MPI3 Fortran] Results of San Jose Forum meeting
by Bill Long 11 Mar '10

11 Mar '10

Jeff Squyres wrote: > On Mar 11, 2010, at 8:59 AM, N.M. Maclaren wrote: > >>> That being said, this is definitely an engineering tradeoff. As I >>> mentioned, the current OMPI prototype implementation has a Fortran >>> derived type that includes the corresponding OMPI C handle as a member >>> (which is a pointer). I was a bit unhappy to give this up, but Rolf >>> convinced me that the other benefits outweigh this. >> Does it still hold true, if it doesn't do what he though that it did? > > (I'm stepping back and letting you Fortran guys debate all the other points) > > There certainly is an elegance to having no MPI handle conversion functions between use mpi/use mpi3/mpif.h. It would have been nice to avoid the lookup, but a) the cost really doesn't matter, and b) I think the usability issue is nice (i.e., assignment), even if none of the other benefits work out. But I'm not tied strongly to either way. > One advantage of the integer flag values is that it avoids interface issues when we change the pointer size. This happened many years ago when we switched from 32 bits to 64 bits for addresses (and in truly ancient history from 16 to 32), and the 128-bit address train is rapidly approaching. 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] Results of San Jose Forum meeting
by N.M. Maclaren 11 Mar '10

11 Mar '10

On Mar 11 2010, Jeff Squyres wrote: > > There certainly is an elegance to having no MPI handle conversion > functions between use mpi/use mpi3/mpif.h. It would have been nice to > avoid the lookup, but a) the cost really doesn't matter, and b) I think > the usability issue is nice (i.e., assignment), even if none of the other > benefits work out. But I'm not tied strongly to either way. I don't find that having to define the internals of a derived type any more elegant than defining two functions (or a single subroutine). Regards, Nick Maclaren.

1 0

Re: [MPI3 Fortran] Results of San Jose Forum meeting
by Jeff Squyres 11 Mar '10

11 Mar '10

On Mar 11, 2010, at 8:59 AM, N.M. Maclaren wrote: > > That being said, this is definitely an engineering tradeoff. As I > > mentioned, the current OMPI prototype implementation has a Fortran > > derived type that includes the corresponding OMPI C handle as a member > > (which is a pointer). I was a bit unhappy to give this up, but Rolf > > convinced me that the other benefits outweigh this. > > Does it still hold true, if it doesn't do what he though that it did? (I'm stepping back and letting you Fortran guys debate all the other points) There certainly is an elegance to having no MPI handle conversion functions between use mpi/use mpi3/mpif.h. It would have been nice to avoid the lookup, but a) the cost really doesn't matter, and b) I think the usability issue is nice (i.e., assignment), even if none of the other benefits work out. But I'm not tied strongly to either way. -- 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] Results of San Jose Forum meeting
by N.M. Maclaren 11 Mar '10

11 Mar '10

On Mar 11 2010, Bill Long wrote: > >I think this is only ensured if the type is a bind(c) type. If you use > >type,bind(c) :: MPI_Comm > integer(c_int) :: val >end type MPI_Comm > >which corresponds to a C structure with one member of type int. The C >standard requires that "A pointer to a structure object, suitable >converted, points to its initial member ...". Unnamed padding at the >beginning of a C struct is prohibited. And Fortran is required to >follow the C rules for layout of a bind(c) type. So, if something like >this is passed by address, then the address of the struct and the >address of the integer will be the same, and you get your "same memory >layout" requirement satisfied. You also have something that can be >legally passed to a C routine. Yes and no. Firstly, it is important to note that it is only true if a pointer to the object is passed - those can be (and often are) of different lengths. Secondly, casting a pointer to an integer to a pointer to such a structure may be illegal (alignment). So, while that can be made to work, it's not easy to walk through the minefield. Regards, Nick Maclaren.

1 0

Re: [MPI3 Fortran] Results of San Jose Forum meeting
by N.M. Maclaren 11 Mar '10

11 Mar '10

On Mar 11 2010, Jeff Squyres wrote: >> > - Make the explicit interfaces in "use mpi" be *required* by MPI >> > implementations (they are optional right now). This is now >> > possible because of the (void*)-like behavior that is available >> > in all Fortran compilers. >> >> Are you SURE? I am pretty sure that many don't, and won't do for a >> while. > > Rolf and Craig assured me that this was so -- so I defer to you experts. > Keep in mind that their assurance to me was predicated that compilers may > have *vendor-specific* mechanisms; they may not be the standard/blessed > mechanism (yet). > >But if this is not true, then the whole plan is suspect. Indeed. I doubt very much that NAG has, and I can't find such a facility in the several vendors' documentation I have looked at, which doesn't mean that it's not there and undocumented. But relying on undocumented facilities is risky, even if they all had it. In particular, Rolf and Craig, what are the facilities for doing that in NAG, gfortran, Intel, Sun and Pathscale? I can check all of those. >> Yuck. You're not planning on playing tricks with EQUIVALENCE, are you? >> If not, why a sequence type? > > I don't know what EQUIVALENCE is; there was no mention of it in the > discussion. That's good. It was the only reason that I could see for putting it in. > Rolf explained the SEQUENCE as meaning that this would guarantee that an > instance of the derived type in memory would be exactly the same as a > single INTEGER. Others have answered that one. > That being said, this is definitely an engineering tradeoff. As I > mentioned, the current OMPI prototype implementation has a Fortran > derived type that includes the corresponding OMPI C handle as a member > (which is a pointer). I was a bit unhappy to give this up, but Rolf > convinced me that the other benefits outweigh this. Does it still hold true, if it doesn't do what he though that it did? >> > call MPI_Send(A(3:9:3, 4:8:2), any_mpi_datatype, ...) >> >> Sorry, but it won't, as I keep saying, unless you are making >> incompatible changes to MPI that will affect a very large number of >> programs. In particular, it will be no longer possible to pass an >> assumed-size array or an array element. To see this, try: > > I'll let you Fortran experts debate this... (this is out of my expertise; > Rolf and Craig told me it would work and I had no reason to disbelieve > them) Sorry, but it won't. Not a hope. Regards, Nick Maclaren.

1 0