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

Re: [MPI3 Fortran] MPI-2.1: Fortran 90 bindings
by Lionel, Steve 06 Mar '08

06 Mar '08

Note that if you declare the argument in the binding to be DIMENSION(*) then the programmer can pass ANY dimension array using A(1,1,1), etc. Not quite natural. The different types and kinds is still an issue. Steve -----Original Message----- From: mpi3-fortran-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Jeff Squyres Sent: Thursday, March 06, 2008 12:35 PM To: MPI-3 Fortran working group Subject: Re: [MPI3 Fortran] MPI-2.1: Fortran 90 bindings Importance: Low On Mar 6, 2008, at 11:13 AM, Harald Klimach wrote: > I don't know how those 15 intrinsic types are coming from. As far as I > know there are 5 intrinsic types in Fortran 90: integer, real, > complex, > logical and character. Each of them can theoretically an unlimited > number of kinds. As far as I understand it MPI allows to use the > following: > integer*1, *2, *4, *8, *16 > real*4, *8, *16 > complex*4, *8, *16 > logical > character > Which adds up to 13 in total. But most propably I'm missing the > remaining 2. In the paper, we have a footnote: Assuming the compiler supports CHARACTER, LOGICAL{1,2,4,8}, INTEGER{1,2,4,8}, REAL{4,8,16}, and COMPLEX{8,16,32}. > Could you please explain why assumed shape arrays are necessary in the > interfaces? I don't see the benefit we are gaining compared to the > assumed size. I attached a little example using an assumed size array. I cannot -- Bill Saphir was the original author of the F90 bindings (Bill's no longer involved with the MPI Forum). I don't know why he chose assumed shape vs. assumed size. I've recently been involved in MPI Fortran issues even though I'm not really a Fortran programmer (I confess to always being confused by "assumed shape" and "assumed size" :-( ). In this effort, I'm trying to be a liason between the Fortran and MPI communities. Keep in mind that we cannot make huge changes to the existing MPI F90 bindings. They're more-or-less set in stone. What we can do is deprecate them in favor of newer, better bindings (E.g., stuff that takes advantage of more modern Fortran features, such as the C-to- Fortran interoperability compiler features). That's going on for MPI-3. My goal in posting this morning was the see if we could do a very minor fix for MPI-2.1 to make the existing MPI F90 bindings implementable. My point: I don't know if we can change from assumed shape to assumed size for MPI-2.1. Possibly for MPI-2.2...? (MPI-2.2 is allowed to have small changes that require a little implementation effort) I think I would need to understand much better what this change would mean: - for existing MPI F90 applications - for existing MPI F90 implementations - for the MPI-2.x standard This is probably worth discussing on the teleconference tomorrow. > I think the dimensional information of the assumed shape array is > discarded anyway, when it is handed over to the actual C-Function. Yes, we only get a pointer to the beginning of the data. > Which leaves us with 15*50 = 750 Interfaces for the functions with one > choice buffer. This is probably something I don't understand well in Fortran; the goal is to be able to pass any intrinsic type of any array shape/size/ whatever through the "choice" MPI buffers (e.g., the buffer argument to MPI_SEND). If we can reduce the number of subroutine signatures to 750 from 5250, that's a good thing (but may be a moot point, per above). > The calculation for the 25 functions with two choice buffers isn't > clear to me. > Shouldn't it read (15 * 7)^2 * 25 = 275625? Crud, I think you're right. Doh! Even so, it's too many. ;-) > If this is the case we would "only" have 15^2 * 25 = 5625 interfaces > for functions with two choice buffers. That's predicated on whether we can change the F90 bindings to use assumed size, right? -- 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] MPI-2.1: Fortran 90 bindings
by Harald Klimach 06 Mar '08

06 Mar '08

OK, sorry I should have done this earlier! I just had a look into openmpi, and how it's done there, and found, that there already assumed size is used. Looking at the standard I found it is also everywhere talking of assumed size only. For example in openmpi-1.2.5/ompi/mpi/f90/mpi_buffer_attach_f90.f90.sh a construct like this is used: for rank in $allranks do case "$rank" in 0) dim='' ; esac case "$rank" in 1) dim=', dimension(*)' ; esac case "$rank" in 2) dim=', dimension(1,*)' ; esac case "$rank" in 3) dim=', dimension(1,1,*)' ; esac case "$rank" in 4) dim=', dimension(1,1,1,*)' ; esac case "$rank" in 5) dim=', dimension(1,1,1,1,*)' ; esac case "$rank" in 6) dim=', dimension(1,1,1,1,1,*)' ; esac case "$rank" in 7) dim=', dimension(1,1,1,1,1,1,*)' ; esac The only 2 meaningful options are the first two. $rank = 0 provides the possibility to provide the routine with a scalar. $rank = 1 enables the routine to take an array of any rank. The rest is just not needed. At least to my understanding. I would even doubt, that the first option is really necessary, as the standard states buffer for MPI_BUFFER_ATTACH to be: <type> BUFFER(*) To my reading that would mean it has to be an array. From the options above $rank = 1 would then be the only one, that is really needed. The MPI-2 standard is talking about this issue on page 285 in the paragraph "Problems Due to Strong Typing". As I read it, it is expected to only use the array. The user can always just use an array of size 1. However it is very convenient to just put the scalar in the argument list ;) So it certainly is a nice thing to have the additional interface (but requires to double the work by the implementor). Actually you could even an explicit shape array: subroutine MPI_BUFFER_ATTACH(buffer, size, ierror) integer :: size, iError integer :: buffer(size) end subroutine MPI_BUFFER_ATTACH and call it with any integer array, that fits into size. Just try it with the sample program I sent in my first mail ;). This would ensure that the actual argument for buffer isn't larger than size. Regarding the functions with two choice parameters: Is there any function which actually would make it necessary to allow two different types? By a brief glance at the standard, I only found constructs like in MPI_Allreduce: MPI_ALLREDUCE(sendbuf, recvbuf, count, datatype, op, comm, ierror) <type> sendbuf(*), recvbuf(*) integer count, datatype, op, comm, ierror To my understanding this means, that sendbuf and recvbuf have to of the same type. It won't make any sense in the programs logic otherwise anyway. If they are really allowed to be of different types, I would expect them to be on two lines: <type> sendbuf(*) <type> recvbuf(*) But perhaps that's just a bad interpretation by me. No Fortran program should want to get different typed values then it sent. Are there really any MPI functions, where it is sensible to use two different types for the two choice parameters? Otherwise a thousand interfaces would be sufficient (just one logical from your list: 12*75 = 900, all logicals from your list: 15*75 = 1125) for the current MPI-Standard, as it is. Maybe a clarification could be useful for the case of two choice parameters, but maybe this is already clearly specified in the standard somewhere. Kind regards, Harald -- Dipl.-Ing. Harald Klimach email: klimach(a)hlrs.de HLRS, Uni Stuttgart http://www.hlrs.de/people/klimach Nobelstraße 19 phone: 0711-685 60300 70569 Stuttgart fax: 0711-685 65832

1 0

Re: [MPI3 Fortran] MPI-2.1: Fortran 90 bindings
by Harald Klimach 06 Mar '08

06 Mar '08

Hi, > > Assuming the compiler supports CHARACTER, LOGICAL{1,2,4,8}, > INTEGER{1,2,4,8}, > REAL{4,8,16}, and COMPLEX{8,16,32}. Fine, thank you. I think we can assume one kind of logical is sufficient. I never ran across different kinds of logicals. > Keep in mind that we cannot make huge changes to the existing MPI F90 > bindings. They're more-or-less set in stone. What we can do is > deprecate them in favor of newer, better bindings (E.g., stuff that > takes advantage of more modern Fortran features, such as the C-to- > Fortran interoperability compiler features). That's going on for MPI-3. The standard doesn't state anything about assumed shape/assumed size as far as I know. This is just a implementation detail. You could say, assumed size is the F77 way to do it. But as it is part of the F90 standard it is usable through explicit interfaces, so you don't loose the type checking and key words for parameters. > My goal in posting this morning was the see if we could do a very > minor fix for MPI-2.1 to make the existing MPI F90 bindings > implementable. My point: I don't know if we can change from assumed > shape to assumed size for MPI-2.1. Possibly for MPI-2.2...? (MPI-2.2 > is allowed to have small changes that require a little implementation > effort) I just wanted to point out, that there may be no need for as many interfaces as you summed up in your posting. I think the number of necessary interfaces for the functions with 2 choice parameters is embarrasing large, but as you said around 6000 may be doable, so there may not even be the need to change anything in the standard. > > I think I would need to understand much better what this change would > mean: > > - for existing MPI F90 applications The user shouldn't see any difference. > - for existing MPI F90 implementations If the implementation uses assumed shape it has to provide something like this: MPI_BUFFER_ATTACH1_TYPE(buffer, size, ierror) type :: buffer(:) integer :: size, ierror MPI_BUFFER_ATTACH2_TYPE(buffer, size, ierror) type :: buffer(:,:) integer :: size, ierror MPI_BUFFER_ATTACH3_TYPE(buffer, size, ierror) type :: buffer(:,:,:) integer :: size, ierror MPI_BUFFER_ATTACH4_TYPE(buffer, size, ierror) type :: buffer(:,:,:,:) integer :: size, ierror MPI_BUFFER_ATTACH5_TYPE(buffer, size, ierror) type :: buffer(:,:,:,:,:) integer :: size, ierror MPI_BUFFER_ATTACH6_TYPE(buffer, size, ierror) type :: buffer(:,:,:,:,:,:) integer :: size, ierror MPI_BUFFER_ATTACH7_TYPE(buffer, size, ierror) type :: buffer(:,:,:,:,:,:,:) integer :: size, ierror INTERFACE MPI_BUFFER_ATTACH module procedure MPI_BUFFER_ATTACH1_TYPE module procedure MPI_BUFFER_ATTACH2_TYPE module procedure MPI_BUFFER_ATTACH3_TYPE module procedure MPI_BUFFER_ATTACH4_TYPE module procedure MPI_BUFFER_ATTACH5_TYPE module procedure MPI_BUFFER_ATTACH6_TYPE module procedure MPI_BUFFER_ATTACH7_TYPE ... other types END INTERFACE With assumed shape you just have to do: MPI_BUFFER_ATTACH_TYPE(buffer, size, ierror) type, dimension(*) :: buffer integer :: size, ierror INTERFACE MPI_BUFFER_ATTACH module procedure MPI_BUFFER_ATTACH_TYPE ... other types END INTERFACE I don't really know, but I can't see any reason for the implementation to use the assumed shape here, as the buffer normally just has to be handed over to the C-Function. > - for the MPI-2.x standard It doesn't mean anything for the MPI-2.x standard. > > This is probably worth discussing on the teleconference tomorrow. I can't participate in the conference, sorry. > This is probably something I don't understand well in Fortran; the > goal is to be able to pass any intrinsic type of any array shape/size/ > whatever through the "choice" MPI buffers (e.g., the buffer argument > to MPI_SEND). If we can reduce the number of subroutine signatures to > 750 from 5250, that's a good thing (but may be a moot point, per above). By using assumed size, you don't have to care about the shape or the size anymore, what's left is the type. > > > If this is the case we would "only" have 15^2 * 25 = 5625 interfaces > > for functions with two choice buffers. > > > That's predicated on whether we can change the F90 bindings to use > assumed size, right? > Yes, but as said, this is a mere implementation detail, the standard doesn't state anything about how this. Every implementor is free to spent as much (unnecessary) effort as he likes to, as long as the interface for the user looks, like specified in the standard, right? I hope this helps a little bit to clarify some of the issues, Harald -- Dipl.-Ing. Harald Klimach email: klimach(a)hlrs.de HLRS, Uni Stuttgart http://www.hlrs.de/people/klimach Nobelstraße 19 phone: 0711-685 60300 70569 Stuttgart fax: 0711-685 65832

1 0

Re: [MPI3 Fortran] MPI-2.1: Fortran 90 bindings
by Jeff Squyres 06 Mar '08

06 Mar '08

On Mar 6, 2008, at 11:13 AM, Harald Klimach wrote: > I don't know how those 15 intrinsic types are coming from. As far as I > know there are 5 intrinsic types in Fortran 90: integer, real, > complex, > logical and character. Each of them can theoretically an unlimited > number of kinds. As far as I understand it MPI allows to use the > following: > integer*1, *2, *4, *8, *16 > real*4, *8, *16 > complex*4, *8, *16 > logical > character > Which adds up to 13 in total. But most propably I'm missing the > remaining 2. In the paper, we have a footnote: Assuming the compiler supports CHARACTER, LOGICAL{1,2,4,8}, INTEGER{1,2,4,8}, REAL{4,8,16}, and COMPLEX{8,16,32}. > Could you please explain why assumed shape arrays are necessary in the > interfaces? I don't see the benefit we are gaining compared to the > assumed size. I attached a little example using an assumed size array. I cannot -- Bill Saphir was the original author of the F90 bindings (Bill's no longer involved with the MPI Forum). I don't know why he chose assumed shape vs. assumed size. I've recently been involved in MPI Fortran issues even though I'm not really a Fortran programmer (I confess to always being confused by "assumed shape" and "assumed size" :-( ). In this effort, I'm trying to be a liason between the Fortran and MPI communities. Keep in mind that we cannot make huge changes to the existing MPI F90 bindings. They're more-or-less set in stone. What we can do is deprecate them in favor of newer, better bindings (E.g., stuff that takes advantage of more modern Fortran features, such as the C-to- Fortran interoperability compiler features). That's going on for MPI-3. My goal in posting this morning was the see if we could do a very minor fix for MPI-2.1 to make the existing MPI F90 bindings implementable. My point: I don't know if we can change from assumed shape to assumed size for MPI-2.1. Possibly for MPI-2.2...? (MPI-2.2 is allowed to have small changes that require a little implementation effort) I think I would need to understand much better what this change would mean: - for existing MPI F90 applications - for existing MPI F90 implementations - for the MPI-2.x standard This is probably worth discussing on the teleconference tomorrow. > I think the dimensional information of the assumed shape array is > discarded anyway, when it is handed over to the actual C-Function. Yes, we only get a pointer to the beginning of the data. > Which leaves us with 15*50 = 750 Interfaces for the functions with one > choice buffer. This is probably something I don't understand well in Fortran; the goal is to be able to pass any intrinsic type of any array shape/size/ whatever through the "choice" MPI buffers (e.g., the buffer argument to MPI_SEND). If we can reduce the number of subroutine signatures to 750 from 5250, that's a good thing (but may be a moot point, per above). > The calculation for the 25 functions with two choice buffers isn't > clear to me. > Shouldn't it read (15 * 7)^2 * 25 = 275625? Crud, I think you're right. Doh! Even so, it's too many. ;-) > If this is the case we would "only" have 15^2 * 25 = 5625 interfaces > for functions with two choice buffers. That's predicated on whether we can change the F90 bindings to use assumed size, right? -- Jeff Squyres Cisco Systems

1 0

Re: [MPI3 Fortran] MPI-2.1: Fortran 90 bindings
by Harald Klimach 06 Mar '08

06 Mar '08

Dear Jeff, I've been asked by Rainer Keller to follow this list. I've got some trouble understanding your suggestion completely: I don't know how those 15 intrinsic types are coming from. As far as I know there are 5 intrinsic types in Fortran 90: integer, real, complex, logical and character. Each of them can theoretically an unlimited number of kinds. As far as I understand it MPI allows to use the following: integer*1, *2, *4, *8, *16 real*4, *8, *16 complex*4, *8, *16 logical character Which adds up to 13 in total. But most propably I'm missing the remaining 2. Could you please explain why assumed shape arrays are necessary in the interfaces? I don't see the benefit we are gaining compared to the assumed size. I attached a little example using an assumed size array. I think the dimensional information of the assumed shape array is discarded anyway, when it is handed over to the actual C-Function. Which leaves us with 15*50 = 750 Interfaces for the functions with one choice buffer. The calculation for the 25 functions with two choice buffers isn't clear to me. Shouldn't it read (15 * 7)^2 * 25 = 275625? If this is the case we would "only" have 15^2 * 25 = 5625 interfaces for functions with two choice buffers. Best regards, Harald Am Mittwoch den 05.03.2008 schrieb Jeff Squyres <jsquyres(a)cisco.com> um 21:15: > The current MPI-2 F90 bindings are un-implementable because they > require almost 7 *million* interface functions: with 15 intrinsic > Fortran types, each with 7 possible dimensions, the current F90 > interface *requires*: > > - 50 MPI functions with one choice buffer: 15 * 7 * 50 = 5,250 functions > - 25 MPI functions with two choice buffers: (15 * 7 * 25)^2 = 6.8M > functions > - ...and a few hundred more MPI functions with no choice buffers > > This is clearly broken. > > An MPI-2.1-worthy solution could be to add a global statement saying > that MPI functions with two choice buffers are explicitly not included > in the F90 bindings. F90 MPI applications can transparently fall back > to the F77 bindings (although they won't get the strong type checking, > etc.). This idea therefore fits the requirement of not breaking any > existing MPI codes. > > Specifically: if we remove the requirement to provide all MPI > functions with two choice buffers, 5,000+ F90 interface functions is > [a pain but] implementable. I doubt that any current MPI > implementation provides more than the no-choice-buffers plus one- > choice-buffer functions anyway... > > If this seems like a good idea, I can write a proper proposal for it. > Comments? > -- Dipl.-Ing. Harald Klimach email: klimach(a)hlrs.de HLRS, Uni Stuttgart http://www.hlrs.de/people/klimach Nobelstraße 19 phone: 0711-685 60300 70569 Stuttgart fax: 0711-685 65832

1 0

Re: [MPI3 Fortran] Is the concall number working?
by Terry Dontje 06 Mar '08

06 Mar '08

Terry Dontje wrote: > I just tried the 866-736-2112 number Jeff sent out yesterday and it > seems to not work for me. > > --td > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran > Nevermind. I just saw Jeff's email. --td

1 0

[MPI3 Fortran] Is the concall number working?
by Terry Dontje 06 Mar '08

06 Mar '08

I just tried the 866-736-2112 number Jeff sent out yesterday and it seems to not work for me. --td

1 0

Re: [MPI3 Fortran] MPI-2.1: Fortran 90 bindings
by Jeff Squyres 06 Mar '08

06 Mar '08

Yes, this is the direction we are going for new Fortran bindings in MPI-3. My proposal is specifically for a small/incremental fix for MPI-2.1's existing MPI F90 bindings. The rule for MPI-2.1 is that changes cannot break existing MPI codes. As such, only "small" things are going into MPI-2.1. On Mar 6, 2008, at 8:25 AM, Lionel, Steve wrote: > I would recommend that for buffers of variable type and rank that the > Fortran interface make use of the Fortran 2003 C interoperability > features, supported by many compilers already, and make these > arguments > of type C_PTR passed by value. The programmer would then pass > C_LOC(buffer), where buffer can be of any type and rank. This is all > specifiable with standard-conforming syntax. > > If this is done, you don't need to have multiple interfaces just to > change type, and you're not giving up any type checking that you would > have had before, as any combination of type and rank would have > matched > some interface. Now you can have as many of these "variant" > arguments as > you like without a mind-numbing series of specific interfaces. > > A compiler using this choice must support the following Fortran 2003 > features: > - Intrinsic module ISO_C_BINDING > - The VALUE attribute > - The BIND(C) attribute > > And if the user chooses a compiler that does not support this, then > they > can use the F77 interfaces. > > 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 Jeff > Squyres > Sent: Wednesday, March 05, 2008 9:16 PM > To: Mailing list for discussion of MPI 2.1 > Cc: MPI-3 Fortran working group > Subject: [MPI3 Fortran] MPI-2.1: Fortran 90 bindings > Importance: Low > > The current MPI-2 F90 bindings are un-implementable because they > require almost 7 *million* interface functions: with 15 intrinsic > Fortran types, each with 7 possible dimensions, the current F90 > interface *requires*: > > - 50 MPI functions with one choice buffer: 15 * 7 * 50 = 5,250 > functions > - 25 MPI functions with two choice buffers: (15 * 7 * 25)^2 = 6.8M > functions > - ...and a few hundred more MPI functions with no choice buffers > > This is clearly broken. > > An MPI-2.1-worthy solution could be to add a global statement saying > that MPI functions with two choice buffers are explicitly not included > in the F90 bindings. F90 MPI applications can transparently fall back > to the F77 bindings (although they won't get the strong type checking, > etc.). This idea therefore fits the requirement of not breaking any > existing MPI codes. > > Specifically: if we remove the requirement to provide all MPI > functions with two choice buffers, 5,000+ F90 interface functions is > [a pain but] implementable. I doubt that any current MPI > implementation provides more than the no-choice-buffers plus one- > choice-buffer functions anyway... > > If this seems like a good idea, I can write a proper proposal for it. > Comments? > > -- > 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] MPI-2.1: Fortran 90 bindings
by Lionel, Steve 06 Mar '08

06 Mar '08

I would recommend that for buffers of variable type and rank that the Fortran interface make use of the Fortran 2003 C interoperability features, supported by many compilers already, and make these arguments of type C_PTR passed by value. The programmer would then pass C_LOC(buffer), where buffer can be of any type and rank. This is all specifiable with standard-conforming syntax. If this is done, you don't need to have multiple interfaces just to change type, and you're not giving up any type checking that you would have had before, as any combination of type and rank would have matched some interface. Now you can have as many of these "variant" arguments as you like without a mind-numbing series of specific interfaces. A compiler using this choice must support the following Fortran 2003 features: - Intrinsic module ISO_C_BINDING - The VALUE attribute - The BIND(C) attribute And if the user chooses a compiler that does not support this, then they can use the F77 interfaces. 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 Jeff Squyres Sent: Wednesday, March 05, 2008 9:16 PM To: Mailing list for discussion of MPI 2.1 Cc: MPI-3 Fortran working group Subject: [MPI3 Fortran] MPI-2.1: Fortran 90 bindings Importance: Low The current MPI-2 F90 bindings are un-implementable because they require almost 7 *million* interface functions: with 15 intrinsic Fortran types, each with 7 possible dimensions, the current F90 interface *requires*: - 50 MPI functions with one choice buffer: 15 * 7 * 50 = 5,250 functions - 25 MPI functions with two choice buffers: (15 * 7 * 25)^2 = 6.8M functions - ...and a few hundred more MPI functions with no choice buffers This is clearly broken. An MPI-2.1-worthy solution could be to add a global statement saying that MPI functions with two choice buffers are explicitly not included in the F90 bindings. F90 MPI applications can transparently fall back to the F77 bindings (although they won't get the strong type checking, etc.). This idea therefore fits the requirement of not breaking any existing MPI codes. Specifically: if we remove the requirement to provide all MPI functions with two choice buffers, 5,000+ F90 interface functions is [a pain but] implementable. I doubt that any current MPI implementation provides more than the no-choice-buffers plus one- choice-buffer functions anyway... If this seems like a good idea, I can write a proper proposal for it. Comments? -- 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] MPI-2.1: Fortran 90 bindings
by Jeff Squyres 05 Mar '08

05 Mar '08

The current MPI-2 F90 bindings are un-implementable because they require almost 7 *million* interface functions: with 15 intrinsic Fortran types, each with 7 possible dimensions, the current F90 interface *requires*: - 50 MPI functions with one choice buffer: 15 * 7 * 50 = 5,250 functions - 25 MPI functions with two choice buffers: (15 * 7 * 25)^2 = 6.8M functions - ...and a few hundred more MPI functions with no choice buffers This is clearly broken. An MPI-2.1-worthy solution could be to add a global statement saying that MPI functions with two choice buffers are explicitly not included in the F90 bindings. F90 MPI applications can transparently fall back to the F77 bindings (although they won't get the strong type checking, etc.). This idea therefore fits the requirement of not breaking any existing MPI codes. Specifically: if we remove the requirement to provide all MPI functions with two choice buffers, 5,000+ F90 interface functions is [a pain but] implementable. I doubt that any current MPI implementation provides more than the no-choice-buffers plus one- choice-buffer functions anyway... If this seems like a good idea, I can write a proper proposal for it. Comments? -- Jeff Squyres Cisco Systems

1 0