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

Re: [MPI3 Fortran] Proposing changes to Fortran 2008
by Jeff Squyres 20 Mar '08

20 Mar '08

On Mar 20, 2008, at 11:13 AM, Craig Rasmussen wrote: > Yes, but the same size hole would exist for the "companion" C struct > as well. So however you calculate stride information for C would > work for an interoperable derived type in Fortran as well. Suppose > foo were, > > struct foo { > char a; > char b; > int i; > char c; > char d; > } Ok, but you said everything in Fortran had to be contiguous. With a hole, by definition, it's not contiguous (and, per my other mails, you can be much more arbitrary, such as skipping the "b" field in the struct above). Does Fortran have a different definition of "contiguous" than C? :-) > Don't you have to worry about the C compiler reordering the elements > of foo? With C++, perhaps. With C, no. Regardless, if you construct the MPI datatype (map) at run-time, then MPI will get the Right values for offsets into the memory map because you actually measure the distances/offsets at run-time (vs. compile- time). -- Jeff Squyres Cisco Systems

1 0

Re: [MPI3 Fortran] Proposing changes to Fortran 2008
by Craig Rasmussen 20 Mar '08

20 Mar '08

Yes, but the same size hole would exist for the "companion" C struct as well. So however you calculate stride information for C would work for an interoperable derived type in Fortran as well. Suppose foo were, struct foo { char a; char b; int i; char c; char d; } Don't you have to worry about the C compiler reordering the elements of foo? Cheers, Craig On Mar 19, 2008, at 6:26 PM, Jeff Squyres wrote: > Isn't there likely to be a "hole" between c and d? > > On Mar 19, 2008, at 12:22 PM, Craig Rasmussen wrote: > >> I'm not sure your example is relevant for a Fortran API though. In >> Fortran we like to be safer than using NULL as a valid reference >> point :-). >> >> Seriously though, we have been discussing using the Fortran intrinsic >> C_LOC to obtain the address of a Fortran object to pass to C. In the >> description of C_LOC is requires that the variable "shall either be a >> contiguous variable with interoperable type and type parameters, or >> be a scalar, ...". >> >> I believe your example: >> >> struct foo { >> char c; >> double d; >> } >> >> then passing the address of foo_instance[0].c should work fine in >> Fortran as well under the following restraints: >> 1. foo_instance in a contiguous array >> 2. foo in of interoperable type >> >> Cheers, >> Craig >> >> >> On Mar 18, 2008, at 7:16 PM, Jeff Squyres wrote: >> >>> On Mar 18, 2008, at 11:02 AM, Craig Rasmussen wrote: >>> >>>>> No. >>>> >>>> Yes! (sorry, couldn't resist Jeff :-) >>>> >>>> What you say below is as I expected. If you have an array of foo, >>>> then foo must be contiguous in order for you to be able to stride >>>> though it to get at each (noncontiguous) char c. I don't think we >>>> disagree here. In Fortran, you can take a slice of an array so >>>> that >>>> the sliced elements aren't contiguous anymore. The compiler >>>> handles >>>> this by modifying the array meta-data (stride information), or if >>>> necessary when going to C, make a copy. So in Fortran we have >>>> to be >>>> a little more careful what we mean by contiguous (and I'm sure I >>>> don't fully understand it yet). >>> >>> >>> There is absolutely no requirement for contiguousness of user >>> buffers >>> in the C bindings for MPI. >>> >>> Indeed, you can construct an MPI datatype (map) based off an >>> arbitrary >>> reference point in memory (e.g., NULL) and use relative memory >>> offsets >>> to describe the layout of the data that you want to access. Hence, >>> the pointer that you pass to MPI_SEND may actually have a memory map >>> that spans all over actual memory. >>> >>> -- >>> 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 >> >> _______________________________________________ >> mpi3-fortran mailing list >> mpi3-fortran(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran > > > -- > 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] Proposing changes to Fortran 2008
by Jeff Squyres 19 Mar '08

19 Mar '08

Isn't there likely to be a "hole" between c and d? On Mar 19, 2008, at 12:22 PM, Craig Rasmussen wrote: > I'm not sure your example is relevant for a Fortran API though. In > Fortran we like to be safer than using NULL as a valid reference > point :-). > > Seriously though, we have been discussing using the Fortran intrinsic > C_LOC to obtain the address of a Fortran object to pass to C. In the > description of C_LOC is requires that the variable "shall either be a > contiguous variable with interoperable type and type parameters, or > be a scalar, ...". > > I believe your example: > > struct foo { > char c; > double d; > } > > then passing the address of foo_instance[0].c should work fine in > Fortran as well under the following restraints: > 1. foo_instance in a contiguous array > 2. foo in of interoperable type > > Cheers, > Craig > > > On Mar 18, 2008, at 7:16 PM, Jeff Squyres wrote: > >> On Mar 18, 2008, at 11:02 AM, Craig Rasmussen wrote: >> >>>> No. >>> >>> Yes! (sorry, couldn't resist Jeff :-) >>> >>> What you say below is as I expected. If you have an array of foo, >>> then foo must be contiguous in order for you to be able to stride >>> though it to get at each (noncontiguous) char c. I don't think we >>> disagree here. In Fortran, you can take a slice of an array so that >>> the sliced elements aren't contiguous anymore. The compiler handles >>> this by modifying the array meta-data (stride information), or if >>> necessary when going to C, make a copy. So in Fortran we have to be >>> a little more careful what we mean by contiguous (and I'm sure I >>> don't fully understand it yet). >> >> >> There is absolutely no requirement for contiguousness of user buffers >> in the C bindings for MPI. >> >> Indeed, you can construct an MPI datatype (map) based off an >> arbitrary >> reference point in memory (e.g., NULL) and use relative memory >> offsets >> to describe the layout of the data that you want to access. Hence, >> the pointer that you pass to MPI_SEND may actually have a memory map >> that spans all over actual memory. >> >> -- >> 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 > > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran -- Jeff Squyres Cisco Systems

1 0

Re: [MPI3 Fortran] Proposing changes to Fortran 2008
by Craig Rasmussen 19 Mar '08

19 Mar '08

I'm not sure your example is relevant for a Fortran API though. In Fortran we like to be safer than using NULL as a valid reference point :-). Seriously though, we have been discussing using the Fortran intrinsic C_LOC to obtain the address of a Fortran object to pass to C. In the description of C_LOC is requires that the variable "shall either be a contiguous variable with interoperable type and type parameters, or be a scalar, ...". I believe your example: struct foo { char c; double d; } then passing the address of foo_instance[0].c should work fine in Fortran as well under the following restraints: 1. foo_instance in a contiguous array 2. foo in of interoperable type Cheers, Craig On Mar 18, 2008, at 7:16 PM, Jeff Squyres wrote: > On Mar 18, 2008, at 11:02 AM, Craig Rasmussen wrote: > >>> No. >> >> Yes! (sorry, couldn't resist Jeff :-) >> >> What you say below is as I expected. If you have an array of foo, >> then foo must be contiguous in order for you to be able to stride >> though it to get at each (noncontiguous) char c. I don't think we >> disagree here. In Fortran, you can take a slice of an array so that >> the sliced elements aren't contiguous anymore. The compiler handles >> this by modifying the array meta-data (stride information), or if >> necessary when going to C, make a copy. So in Fortran we have to be >> a little more careful what we mean by contiguous (and I'm sure I >> don't fully understand it yet). > > > There is absolutely no requirement for contiguousness of user buffers > in the C bindings for MPI. > > Indeed, you can construct an MPI datatype (map) based off an arbitrary > reference point in memory (e.g., NULL) and use relative memory offsets > to describe the layout of the data that you want to access. Hence, > the pointer that you pass to MPI_SEND may actually have a memory map > that spans all over actual memory. > > -- > 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] Proposing changes to Fortran 2008
by Jeff Squyres 18 Mar '08

18 Mar '08

On Mar 18, 2008, at 11:02 AM, Craig Rasmussen wrote: >> No. > > Yes! (sorry, couldn't resist Jeff :-) > > What you say below is as I expected. If you have an array of foo, > then foo must be contiguous in order for you to be able to stride > though it to get at each (noncontiguous) char c. I don't think we > disagree here. In Fortran, you can take a slice of an array so that > the sliced elements aren't contiguous anymore. The compiler handles > this by modifying the array meta-data (stride information), or if > necessary when going to C, make a copy. So in Fortran we have to be > a little more careful what we mean by contiguous (and I'm sure I > don't fully understand it yet). There is absolutely no requirement for contiguousness of user buffers in the C bindings for MPI. Indeed, you can construct an MPI datatype (map) based off an arbitrary reference point in memory (e.g., NULL) and use relative memory offsets to describe the layout of the data that you want to access. Hence, the pointer that you pass to MPI_SEND may actually have a memory map that spans all over actual memory. -- Jeff Squyres Cisco Systems

1 0

Re: [MPI3 Fortran] Proposing changes to Fortran 2008
by Lionel, Steve 18 Mar '08

18 Mar '08

Please keep me involved in this discussion. I don't care if it's done in this list or through direct email. Steve Lionel Developer Products Division Intel Corporation Nashua, NH -----Original Message----- From: mpi3-fortran-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Craig Rasmussen Sent: Tuesday, March 18, 2008 11:04 AM To: MPI-3 Fortran working group Subject: Re: [MPI3 Fortran] Proposing changes to Fortran 2008 Importance: Low I'm going to take this offline as it probably involves more technical Fortran discussion that this group wants. If anyone disagrees, we can keep in online. Cheers, Craig On Mar 18, 2008, at 11:18 AM, Aleksandar Donev wrote: > On Tuesday 18 March 2008 06:56, Craig Rasmussen wrote: > >> Why can't c_void be used like c_ptr is now so that the interface is >> bi-directional (implementable in either C or Fortran)? > Because entities in Fortran must have a type----the standard > literally breaks > down otherwise. CLASS(*) is the Fortran (2003) "equivalent" to > void*, but it > does have a (dynamic) type. The type is passed in a "type > descriptor". If > there is no type info, but rather just an address, you can't do > anything to > it in Fortran and you cannot interpret the meaning of the standard. > And the > committee will never go along with changing the standard to allow > such a > thing and thus make Fortran look like C :-) > >> Unfortunately the integer declaration is just for show also. What is >> really meant in >> void :: buffer >> and everything else is just to get around the fact we can't have a >> void type in Fortran. > You are agreeing with me that one should not be specifying false > attributes > and fake types and then ignoring them. It is a hack unsuitable for > standardization. > > But, the problem I see with the above declaration (which I find > very nice) is > that it requires (significantly) more work to add to the standard. > One has to > specify a whole new section about argument matching for such "void" > arguments. This includes issues such as what the dummy is actually > associated > with (the whole of the actual in array-element order?), whether the > actual > needs to be an array or scalar or either, what type it may have, > whether it > has to be contiguous, whether copy in/out is ever allowed or not, > etc., etc. > I can help you write a draft of such rules. But, it won't be easy > to push it > through the committee, especially at this stage. > > My idea is to only allow type mismatch, much like we do for CLASS > (*) dummies > but just passing an address without a type descriptor. This is a > much more > localized change. Dealing with multiple ranks is also useful but > IMO not > crucial and requires more work. > > Or, one can propose both during the comment period and let J3 make > an opinion. > In any case, I strongly urge the MPI Forum Fortran group to come up > with a > proposal for the May J3 meeting to get the ball rolling early. > > 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 > > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran _______________________________________________ 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] Proposing changes to Fortran 2008
by Craig Rasmussen 18 Mar '08

18 Mar '08

I'm going to take this offline as it probably involves more technical Fortran discussion that this group wants. If anyone disagrees, we can keep in online. Cheers, Craig On Mar 18, 2008, at 11:18 AM, Aleksandar Donev wrote: > On Tuesday 18 March 2008 06:56, Craig Rasmussen wrote: > >> Why can't c_void be used like c_ptr is now so that the interface is >> bi-directional (implementable in either C or Fortran)? > Because entities in Fortran must have a type----the standard > literally breaks > down otherwise. CLASS(*) is the Fortran (2003) "equivalent" to > void*, but it > does have a (dynamic) type. The type is passed in a "type > descriptor". If > there is no type info, but rather just an address, you can't do > anything to > it in Fortran and you cannot interpret the meaning of the standard. > And the > committee will never go along with changing the standard to allow > such a > thing and thus make Fortran look like C :-) > >> Unfortunately the integer declaration is just for show also. What is >> really meant in >> void :: buffer >> and everything else is just to get around the fact we can't have a >> void type in Fortran. > You are agreeing with me that one should not be specifying false > attributes > and fake types and then ignoring them. It is a hack unsuitable for > standardization. > > But, the problem I see with the above declaration (which I find > very nice) is > that it requires (significantly) more work to add to the standard. > One has to > specify a whole new section about argument matching for such "void" > arguments. This includes issues such as what the dummy is actually > associated > with (the whole of the actual in array-element order?), whether the > actual > needs to be an array or scalar or either, what type it may have, > whether it > has to be contiguous, whether copy in/out is ever allowed or not, > etc., etc. > I can help you write a draft of such rules. But, it won't be easy > to push it > through the committee, especially at this stage. > > My idea is to only allow type mismatch, much like we do for CLASS > (*) dummies > but just passing an address without a type descriptor. This is a > much more > localized change. Dealing with multiple ranks is also useful but > IMO not > crucial and requires more work. > > Or, one can propose both during the comment period and let J3 make > an opinion. > In any case, I strongly urge the MPI Forum Fortran group to come up > with a > proposal for the May J3 meeting to get the ball rolling early. > > 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 > > _______________________________________________ > 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] What if Fortran is the primary interface?
by Supalov, Alexander 18 Mar '08

18 Mar '08

We should get those who know onto this list. Otherwise we run the danger of producing an academically elegant but absolutely impracticable result. -----Original Message----- From: mpi3-fortran-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Aleksandar Donev Sent: Tuesday, March 18, 2008 6:41 PM To: MPI-3 Fortran working group Subject: Re: [MPI3 Fortran] What if Fortran is the primary interface? On Tuesday 18 March 2008 10:26, Supalov, Alexander wrote: > Can you give an example of a platform/compiler that do this? No, I have little to no knowledge about what compilers/platforms do. That does not mean they are not around---someone should know :-\ Aleks _______________________________________________ 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] What if Fortran is the primary interface?
by Aleksandar Donev 18 Mar '08

18 Mar '08

On Tuesday 18 March 2008 10:26, Supalov, Alexander wrote: > Can you give an example of a platform/compiler that do this? No, I have little to no knowledge about what compilers/platforms do. That does not mean they are not around---someone should know :-\ Aleks

1 0

Re: [MPI3 Fortran] What if Fortran is the primary interface?
by Supalov, Alexander 18 Mar '08

18 Mar '08

Thanks. Can you give an example of a platform/compiler that do this? -----Original Message----- From: mpi3-fortran-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Aleksandar Donev Sent: Tuesday, March 18, 2008 6:23 PM To: MPI-3 Fortran working group Subject: Re: [MPI3 Fortran] What if Fortran is the primary interface? On Tuesday 18 March 2008 10:17, Supalov, Alexander wrote: > Can you give an example of a "peculiar" system? Integers are passed in registers but structs (even small ones containing only a single integer) are always passed on the stack. Aleks _______________________________________________ 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