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

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

13 Mar '10

Rolf Rabenseifner wrote: > Hi all, > > I expect, that in our special case, the alignment problems cannot > cause problems, because all is Fortran INTEGER and therefore > at least 4-byte-aligned. > With intentionally misaligned handles, the new derived type handle > seems to work better (but not worse) than integer handles. > > I've attached a small test code to solve the question, whether > - INTEGER and > - TYPE handle; SEQUENCE INTEGER :: val; END TYPE handle > is passed to a C back-end in the same way. > > Does it produce the expected results on all compilers: > > IBM (several compilers) > Cray (ditto?) We let you get by with this code (to the extent that 24 is OK for "expected 25"). However.... > NAG Fortran > Intel > gfortran > Oracle/Sun > Pathscale > Portland Group > Possibly g95 > > I checked with Intel: > > cc -c handle_test_c.c > ifort -o handle_test handle_test.f90 handle_test_c.o > > fortcom: Warning: handle_test.f90, line 42: The structure contains one or more misaligned fields. [SEQUENCE_A] > TYPE sequence_A > -------^ > fortcom: Warning: handle_test.f90, line 49: The structure contains one or more misaligned fields. [SEQUENCE_B] > TYPE sequence_B > -------^ These objections are allowable. Have you tried the same program with all of the sequence types replaced with bind(c) types? I'm guessing that the messages will go away if you make that change. And you get the desired output. Cheers, Bill > > ./handle_test > > hd_1 = 12, hd_2 = 13 (expected: 12, 13) > hd_i=112, hd_t%val=113 (expected: 112, 113) > > hd_1 = 14, hd_2 = 15 (expected: 14, 15) > strA%handle=114, strB%handle%val=115 (expected: 114, 115) > > hd_1 = 24, hd_2 = 75 (expected: 25, 75) > strA%handle=225, seqB%handle%val=775 (expected: 225, 775) > > handle_test(12868): unaligned access to 0x600000000000cf29, ip=0x4000000000003530 > hd_1 = 84, hd_2 = 35 (expected: 84, 35) > handle_test(12868): unaligned access to 0x600000000000cf29, ip=0x4000000000003571 > seqA%handle=884, strB%handle%val=335 (expected: 884, 335) > > handle_test(12868): unaligned access to 0x600000000000cf29, ip=0x4000000000003530 > hd_1 = 94, hd_2 = 95 (expected: 94, 95) > handle_test(12868): unaligned access to 0x600000000000cf29, ip=0x4000000000003571 > seqA%handle=994, seqB%handle%val=995 (expected: 994, 995) > > Result: > All works, but there is really a small difference: > - With misaligned INTEGER handle seqA, some runtime warnings occur > - With new derive-type handle seqB, **NO** runtime warnings occur > > It would be helpful, if you can check with some other compilers. > > If you find another alignment problem with some other tests for > exactly these two types (no other derived types), > then please can you report. > > The test program should test, whether internally the Fortran > compiler produces a subroutine call with an argument list > for both handle types that fits to the same C back-end: int*. > > Rolf > > ----- "N.M. Maclaren" <nmm1(a)cam.ac.uk> wrote: > >> Sorry. Posted in haste, and I forgot a critical paragraph. >> >> With those structures, also try seeing what they do when you remove >> each of 'x' and 'y' in turn. Specifically, does 'z' continue to be >> in the same location? >> >> In the SPECIFIC example of a single default integer in a sequence >> type, it will a rare compiler that lays it out differently. But >> all of the INTEGER, INTEGER BIND(C), sequence type and derived type >> without the SEQUENCE may have different sizes and alignments. And, >> on SOME systems, a pointer to one of those may not be usable as a >> pointer to another. >> >> >> >> _______________________________________________ >> mpi3-fortran mailing list >> mpi3-fortran(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran > -- 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 Bill Long 13 Mar '10

13 Mar '10

Rolf Rabenseifner wrote: > Hi, > > a short question: If an MPI library implementation declares the > MPI routines as bind C, is then the internal call mechanism > standardized? It is between the Fortran compiler and its companion C compiler, as long as each argument is "interoperable" as specified in the Fortran standard. The limitation of compatibility only between companion processors is key. It is not required (or even practical) that a Fortran compiler be compatible with a C compiler it does not know about. Typically, this results in two camps: 1) The Fortran compiler vendor also supplies a C compiler, in which case the companion C compiler is its own. This is common, and the most robust option since the vendor controls both compilers, and probably uses a common compiler back-end. Such a vendor may choose to support additional companion C processors, as long as there is some mechanism to specify which one at compile time. 2) The Fortran compiler vendor does not supply its own C compiler, in which case the usual selection of the companion C compiler is gcc. This selection is not required by the standard - but it is practical. Normally, vendor-supplied MPI libraries will have been compiled with a known companion C compiler, so things should work. Cheers, Bill > Or identical with all C compilers because the handle call by > reference for integers and structurs identical? > > Best regards > Rolf > > ----- "Aleksandar Donev" <adonev(a)lbl.gov> wrote: > >> Hi, >> >>> I hope that these citations are correct in relation to the official >>> Fortran 2003 standard. >> Sure, it all is more or less right. >> >>> Based on this, for use mpi and use mpi3, only one identical >>> backend (written in C) should be necessary. >> OK, fine, but that is not implied by the words you quoted. For >> example, >> it is perfectly possible (plausible) for an integer and a struct to be >> >> passed differently (e.g., integer goes in register, the struct on the >> >> stack), and adding SEQUENCE does nothing to change that. If you are >> relying on some "backend" (meaning, really, ABI) property, say so, do >> >> not pretend that the Fortran standard guarantees something it does >> not. >> >> This is not to say that it will not be possible to still use one >> backend >> even if the interface says TYPE(MPI_Comm) instead of INTEGER---but >> that >> is outside the scope of the Fortran standard. One should instead look >> at >> ABIs and conventions compilers use to pass such arguments around. >> >> Best, >> Aleks >> _______________________________________________ >> mpi3-fortran mailing list >> mpi3-fortran(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran > -- 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 Rolf Rabenseifner 13 Mar '10

13 Mar '10

Hi all, I expect, that in our special case, the alignment problems cannot cause problems, because all is Fortran INTEGER and therefore at least 4-byte-aligned. With intentionally misaligned handles, the new derived type handle seems to work better (but not worse) than integer handles. I've attached a small test code to solve the question, whether - INTEGER and - TYPE handle; SEQUENCE INTEGER :: val; END TYPE handle is passed to a C back-end in the same way. Does it produce the expected results on all compilers: IBM (several compilers) Cray (ditto?) NAG Fortran Intel gfortran Oracle/Sun Pathscale Portland Group Possibly g95 I checked with Intel: cc -c handle_test_c.c ifort -o handle_test handle_test.f90 handle_test_c.o fortcom: Warning: handle_test.f90, line 42: The structure contains one or more misaligned fields. [SEQUENCE_A] TYPE sequence_A -------^ fortcom: Warning: handle_test.f90, line 49: The structure contains one or more misaligned fields. [SEQUENCE_B] TYPE sequence_B -------^ ./handle_test hd_1 = 12, hd_2 = 13 (expected: 12, 13) hd_i=112, hd_t%val=113 (expected: 112, 113) hd_1 = 14, hd_2 = 15 (expected: 14, 15) strA%handle=114, strB%handle%val=115 (expected: 114, 115) hd_1 = 24, hd_2 = 75 (expected: 25, 75) strA%handle=225, seqB%handle%val=775 (expected: 225, 775) handle_test(12868): unaligned access to 0x600000000000cf29, ip=0x4000000000003530 hd_1 = 84, hd_2 = 35 (expected: 84, 35) handle_test(12868): unaligned access to 0x600000000000cf29, ip=0x4000000000003571 seqA%handle=884, strB%handle%val=335 (expected: 884, 335) handle_test(12868): unaligned access to 0x600000000000cf29, ip=0x4000000000003530 hd_1 = 94, hd_2 = 95 (expected: 94, 95) handle_test(12868): unaligned access to 0x600000000000cf29, ip=0x4000000000003571 seqA%handle=994, seqB%handle%val=995 (expected: 994, 995) Result: All works, but there is really a small difference: - With misaligned INTEGER handle seqA, some runtime warnings occur - With new derive-type handle seqB, **NO** runtime warnings occur It would be helpful, if you can check with some other compilers. If you find another alignment problem with some other tests for exactly these two types (no other derived types), then please can you report. The test program should test, whether internally the Fortran compiler produces a subroutine call with an argument list for both handle types that fits to the same C back-end: int*. Rolf ----- "N.M. Maclaren" <nmm1(a)cam.ac.uk> wrote: > Sorry. Posted in haste, and I forgot a critical paragraph. > > With those structures, also try seeing what they do when you remove > each of 'x' and 'y' in turn. Specifically, does 'z' continue to be > in the same location? > > In the SPECIFIC example of a single default integer in a sequence > type, it will a rare compiler that lays it out differently. But > all of the INTEGER, INTEGER BIND(C), sequence type and derived type > without the SEQUENCE may have different sizes and alignments. And, > on SOME systems, a pointer to one of those may not be usable as a > pointer to another. > > > > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)

1 0

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

13 Mar '10

Sorry. Posted in haste, and I forgot a critical paragraph. With those structures, also try seeing what they do when you remove each of 'x' and 'y' in turn. Specifically, does 'z' continue to be in the same location? In the SPECIFIC example of a single default integer in a sequence type, it will a rare compiler that lays it out differently. But all of the INTEGER, INTEGER BIND(C), sequence type and derived type without the SEQUENCE may have different sizes and alignments. And, on SOME systems, a pointer to one of those may not be usable as a pointer to another.

1 0

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

13 Mar '10

On Mar 12 2010, Rolf Rabenseifner wrote: > > I want to cite > http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/index.jsp?topic=/c… You would be better off citing the Fortran standard directly. >I hope that these citations are correct in relation to the official >Fortran 2003 standard. Probably. I haven't checked them. >Based on this, the original INTEGER handles and the proposed >derived sequence type with default integer and without any bind(c) >have exactly the same content and storage association. You have misunderstood the specification. In particular, there is no requirement for the alignment rules to be the same for most of those, and they quite often aren't. In particular, unless there is a way IN CONFORMING FORTRAN that you can access a variable of one type as the other, there is no requirement for the compiler to treat them identically. And there isn't. If you want to experiment, I recommend playing around with structures of the form: struct {int x; float y; double z;} and: TYPE :: Fred SEQUENCE INTEGER :: x REAL :: y DOUBLE PRECISION :: z END TYPE Fred You may be surprised by what you find :-) Regards, Nick Maclaren.

1 0

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

13 Mar '10

On Mar 13 2010, Rolf Rabenseifner wrote: > >a short question: If an MPI library implementation declares the >MPI routines as bind C, is then the internal call mechanism >standardized? Not at present, because the current BIND(C) mechanism isn't powerful enough. >Or identical with all C compilers because the handle call by >reference for integers and structurs identical? Not necessarily. In particular, you bring in the dreaded alignment issue. While it does not say so, the C standard requires the alignment of all structures to be a multiple of that of integers. So a pointer to a structure starting with an integer can be cast to a pointer to an integer, but not conversely. Regards, Nick Maclaren.

1 0

Re: [MPI3 Fortran] Results of San Jose Forum meeting
by Rolf Rabenseifner 13 Mar '10

13 Mar '10

Hi, a short question: If an MPI library implementation declares the MPI routines as bind C, is then the internal call mechanism standardized? Or identical with all C compilers because the handle call by reference for integers and structurs identical? Best regards Rolf ----- "Aleksandar Donev" <adonev(a)lbl.gov> wrote: > Hi, > > > I hope that these citations are correct in relation to the official > > Fortran 2003 standard. > Sure, it all is more or less right. > > > Based on this, for use mpi and use mpi3, only one identical > > backend (written in C) should be necessary. > OK, fine, but that is not implied by the words you quoted. For > example, > it is perfectly possible (plausible) for an integer and a struct to be > > passed differently (e.g., integer goes in register, the struct on the > > stack), and adding SEQUENCE does nothing to change that. If you are > relying on some "backend" (meaning, really, ABI) property, say so, do > > not pretend that the Fortran standard guarantees something it does > not. > > This is not to say that it will not be possible to still use one > backend > even if the interface says TYPE(MPI_Comm) instead of INTEGER---but > that > is outside the scope of the Fortran standard. One should instead look > at > ABIs and conventions compilers use to pass such arguments around. > > Best, > Aleks > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)

1 0

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

12 Mar '10

Hi, > I hope that these citations are correct in relation to the official > Fortran 2003 standard. Sure, it all is more or less right. > Based on this, for use mpi and use mpi3, only one identical > backend (written in C) should be necessary. OK, fine, but that is not implied by the words you quoted. For example, it is perfectly possible (plausible) for an integer and a struct to be passed differently (e.g., integer goes in register, the struct on the stack), and adding SEQUENCE does nothing to change that. If you are relying on some "backend" (meaning, really, ABI) property, say so, do not pretend that the Fortran standard guarantees something it does not. This is not to say that it will not be possible to still use one backend even if the interface says TYPE(MPI_Comm) instead of INTEGER---but that is outside the scope of the Fortran standard. One should instead look at ABIs and conventions compilers use to pass such arguments around. Best, Aleks

1 0

Re: [MPI3 Fortran] Results of San Jose Forum meeting
by Rolf Rabenseifner 12 Mar '10

12 Mar '10

Hi, I want to cite http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/index.jsp?topic=/c… "By default, no storage sequence is implied by the order of the component definitions. However, if you specify the SEQUENCE statement, the derived type becomes a sequence derived type. For a sequence derived type, the order of the components specifies a storage sequence for objects declared with this derived type. If a component of a sequence derived type is of a derived type, that derived type must also be a sequence derived type. ... The size of a sequence derived type declared using a s tandard derived type declaration is equal to the sum of the number of bytes required to hold all of its components." I hope, that this text is based on the Fortran standard. Other text from the Fortran 95/2003 book http://books.google.de/books?id=iLj_xAmxscgC&pg=PA331&lpg=PA331&dq=derived+… "A sequence type is a numeric sequence type if it has no type parameters, no component is a pointer or allocatable, and each component is of type default integer, default real, double precision real, default complex, or default logical. A component may also be of a previously defined numeric sequence type. This implies that the ultimate components occupy numeric storage units and the type itself has numeric storage association." I hope that these citations are correct in relation to the official Fortran 2003 standard. Based on this, the original INTEGER handles and the proposed derived sequence type with default integer and without any bind(c) have exactly the same content and storage association. Based on this, for use mpi and use mpi3, only one identical backend (written in C) should be necessary. Of course, this backend must handle Fortran INTEGER and not C int. These Fortran derived sequence types have been chosen - to allow strong typing and argument checking that detects interchanges of count or tag values with datatype and communicator handles. - witout the need of additional handle value conversion routines. Convertion, if needed, can be done very simple INTEGER :: comm_mpi22 TYPE(MPI_Comm) :: comm_mpi30 comm_mpi22 = comm_mpi30%val and comm_mpi30%val = comm_mpi22 - And only one backend for use mpi and use mpi3 Rolf ----- "Aleksandar Donev" <adonev(a)lbl.gov> wrote: > 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/ > > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)

1 0

Re: [MPI3 Fortran] Results of San Jose Forum meeting
by Malcolm Cohen 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. NAG has the -wmismatch=procname-list option. When the TR is published we will enable its syntax. Cheers, -- ................................Malcolm Cohen, Nihon NAG, Tokyo.

1 0