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

Re: [MPI3 Fortran] Con call?
by Lionel, Steve 27 Feb '08

27 Feb '08

Meeting??? Steve > I didn't get much feedback on an attempt at a conference call last week > and it didn't happen. We could do something next week, although that > is > just one week before the meeting so I'd rather just wait for the > meeting > where we can draw stuff up on paper. I have two trial implementations > for > MPI handles we can look at then.

1 0

Re: [MPI3 Fortran] Con call?
by Craig E. Rasmussen 27 Feb '08

27 Feb '08

I'm now in my bi-weekly travel mode, mostly out of email connectivity, and totally behind in email (how's that for irresponsibility?). I didn't get much feedback on an attempt at a conference call last week and it didn't happen. We could do something next week, although that is just one week before the meeting so I'd rather just wait for the meeting where we can draw stuff up on paper. I have two trial implementations for MPI handles we can look at then. Cheers, Craig > Craig -- > > Where are we on having a teleconf? > > Thanks. > > -- > 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

[MPI3 Fortran] Con call?
by Jeff Squyres 27 Feb '08

27 Feb '08

Craig -- Where are we on having a teleconf? Thanks. -- Jeff Squyres Cisco Systems

1 0

Re: [MPI3 Fortran] Start discussing new Fortran binding
by Jeff Squyres 21 Feb '08

21 Feb '08

On Feb 19, 2008, at 10:27 AM, Craig Rasmussen wrote: > Don't know if there are implementations where the MPI handle is not > an integer of size of an address. Would your suggestion work if it > were? Actually, does it matter? In the MPI spec, we can just mandate this part: type, BIND(C) :: MPI_HANDLE_TYPE private ....something.... end type MPI_HANDLE_TYPE So that MPI_HANDLE_TYPE is required to be available in Fortran. What exactly it contains and how it is implemented is up to each MPI implementation. They can make it an equivalent of a C pointer, or a C int, or whatever they need. Let's take two obvious concrete examples: 1. Open MPI defines C MPI communicators as typedef struct ompi_comm_t * MPI_Comm; As such, Open MPI's F03 interface for communicators would be: type, BIND(C) :: MPI_COMMUNICATOR private type(C_PTR) :: handle end type MPI_COMMUNICATOR 2. MPICH2 defines C MPI communicators as ints. Hence, MPICH2's F03 interface for communicators would be: type, BIND(C) :: MPI_COMMUNICATOR private type(C_INT) :: handle end type MPI_COMMUNICATOR Is that right? If so, my only concern is that the compiler can automatically translate between the F03 and C values without the need for a translation layer provided by the MPI implementation. That is, a Fortran function of MPI_SEND that takes an MPI_COMMUNICATOR type parameter (as described above) can be automatically translated to the appropriate MPI_Comm type in C. That is one of the goals of this interface, after all. The reason that I mention this is because I'm a C guy, not a Fortran guy, and the above "type, BIND(C)..." stuff looks analogous to a struct to me. If it is, and if that binding contains more than one member, are we ok on the "compiler will automatically translate it" front as long as there is only one member in the binding? An excellent topic for the teleconference! :-) -- Jeff Squyres Cisco Systems

1 0

Re: [MPI3 Fortran] Start discussing new Fortran binding
by Jeff Squyres 21 Feb '08

21 Feb '08

Sorry, I am on travel this week and missed the bit about a possible teleconf this week. I'm more-or-less available tomorrow (Friday) after noon Pacific time. Next week is overall sketchy, but I could probably make a call if necessary. Here's my estimated availability next week (all times Eastern): Mon Feb 25: not noon-2pm Tue: not 11-noon or 2-3pm Wed: any time is fine Thu: not 12:30-1:30pm Fri: not 2-3pm On Feb 20, 2008, at 8:01 AM, Lionel, Steve wrote: >> I think this should be the main topic for conversation in our telecon >> this week. Agree? > > Is there a telecom this week? Please send me details if so. Thanks. > > > Steve Lionel > Developer Products Division > Intel Corporation > Nashua, NH > > > > > _______________________________________________ > 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] Start discussing new Fortran binding
by Lionel, Steve 20 Feb '08

20 Feb '08

> I think this should be the main topic for conversation in our telecon > this week. Agree? Is there a telecom this week? Please send me details if so. Thanks. Steve Lionel Developer Products Division Intel Corporation Nashua, NH

1 0

Re: [MPI3 Fortran] Start discussing new Fortran binding
by Craig Rasmussen 19 Feb '08

19 Feb '08

Don't know if there are implementations where the MPI handle is not an integer of size of an address. Would your suggestion work if it were? Cheers, Craig On Feb 19, 2008, at 9:32 AM, Lionel, Steve wrote: >> Jeff and I tried to make this work out in our paper but thought there >> might be problems interfacing with exiting MPI implementations. >> However, I agree this would be a better approach if it can be made to >> work with MPI implementations that work with both integers and >> pointers to structs. I'll think some more about how to use your >> approach, perhaps you could add you brain power to it as well. >> >> I think this should be the main topic for conversation in our telecon >> this week. Agree? > > I will admit that I am not steeped in MPI to anywhere near the > degree I > am in Fortran. If you're saying that there are MPI implementations > where the handle is an integer that is NOT also the size of an > address, > then that would be tricky and would have to be handled as an > implementation-dependent named constant giving the proper kind value > based on the equivalent C type. (An irritant is that Fortran KIND > values are implementation-dependent, so what may be kind 4 for one > compiler is kind 3 for another. But using the values in ISO_C_BINDING > would be the way around that.) > > I'll be glad to help as best I can. I agree that this is a fundamental > issue that needs to be resolved before you can get much further. I > would argue for an opaque type regardless - you can change what's > inside > it on a per-implementation basis. > > I have not participated in the con calls before, so please point me to > the details when they become available. > > Steve Lionel > Developer Products Division > Intel Corporation > Nashua, NH > > > > > _______________________________________________ > 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] Start discussing new Fortran binding
by Lionel, Steve 19 Feb '08

19 Feb '08

> Jeff and I tried to make this work out in our paper but thought there > might be problems interfacing with exiting MPI implementations. > However, I agree this would be a better approach if it can be made to > work with MPI implementations that work with both integers and > pointers to structs. I'll think some more about how to use your > approach, perhaps you could add you brain power to it as well. > > I think this should be the main topic for conversation in our telecon > this week. Agree? I will admit that I am not steeped in MPI to anywhere near the degree I am in Fortran. If you're saying that there are MPI implementations where the handle is an integer that is NOT also the size of an address, then that would be tricky and would have to be handled as an implementation-dependent named constant giving the proper kind value based on the equivalent C type. (An irritant is that Fortran KIND values are implementation-dependent, so what may be kind 4 for one compiler is kind 3 for another. But using the values in ISO_C_BINDING would be the way around that.) I'll be glad to help as best I can. I agree that this is a fundamental issue that needs to be resolved before you can get much further. I would argue for an opaque type regardless - you can change what's inside it on a per-implementation basis. I have not participated in the con calls before, so please point me to the details when they become available. Steve Lionel Developer Products Division Intel Corporation Nashua, NH

1 0

Re: [MPI3 Fortran] Start discussing new Fortran binding
by Craig Rasmussen 19 Feb '08

19 Feb '08

On Feb 19, 2008, at 8:38 AM, Lionel, Steve wrote: >> >> 2. Is there a way to use a preprocessor to replace something like >> this >> >> integer(MPI_HANDLE_TYPE), value, intent(in) :: datatype >> >> with either C_INT or C_PTR, depending on what the implementation >> requires? > > The proper (IMO) way to do this in Fortran is as follows: > > type, BIND(C) :: MPI_HANDLE_TYPE > private > type(C_PTR) :: handle > end type MPI_HANDLE_TYPE > > This allows the user to declare things of type(MPI_HANDLE_TYPE) but > makes the contents inaccessible other than passing, storing or > fetching. > The BIND(C) tells the Fortran compiler that this is an interoperable > type and it is not allowed to pad it or rearrange the contents. >> Jeff and I tried to make this work out in our paper but thought there might be problems interfacing with exiting MPI implementations. However, I agree this would be a better approach if it can be made to work with MPI implementations that work with both integers and pointers to structs. I'll think some more about how to use your approach, perhaps you could add you brain power to it as well. I think this should be the main topic for conversation in our telecon this week. Agree? Cheers, Craig

1 0

Re: [MPI3 Fortran] Start discussing new Fortran binding
by Lionel, Steve 19 Feb '08

19 Feb '08

Hi, folks. This is Steve Lionel from the Intel Fortran development team. I've asked to join this list to help with the Fortran bindings to MPI-3. Here's my comments on the current discussion. > Not being a fortran guy, here's a few options that jump to mind (some/ > all of these make be senseless in Fortran): > > 1. Can there be a fortran integer equivalent than can map to either of > those, given an appropriate KIND? Yes, this would be INTEGER(C_INTPTR_T) which is an integer kind that is the size of a pointer for the companion processor. This is equivalent to C's intptr_t type. Note that it isn't guaranteed that there is such an integer kind, though I'd expect that there would be. C_PTR is a type on its own and not a KIND value. It is an "opaque" type that can be manipulated by functions such as C_F_POINTER which "converts" a value of type C_PTR to a Fortran pointer. For MPI arguments that are "handles" - that is, values that are simply fetched, stored and passed and not used arithmetically, then type(C_PTR) would be appropriate. But there's a better option - see below. > > 2. Is there a way to use a preprocessor to replace something like this > > integer(MPI_HANDLE_TYPE), value, intent(in) :: datatype > > with either C_INT or C_PTR, depending on what the implementation > requires? The proper (IMO) way to do this in Fortran is as follows: type, BIND(C) :: MPI_HANDLE_TYPE private type(C_PTR) :: handle end type MPI_HANDLE_TYPE This allows the user to declare things of type(MPI_HANDLE_TYPE) but makes the contents inaccessible other than passing, storing or fetching. The BIND(C) tells the Fortran compiler that this is an interoperable type and it is not allowed to pad it or rearrange the contents. > 3. Does F03 have the equivalent to C's "typedef" such that we could > create handle types that map to integer(C_INT) or type(C_PTR) (and the > user doesn't need to know)? See above. Steve Lionel Developer Products Division Intel Corporation Nashua, NH

1 0