[MPI3 Fortran] MPI Fortran bindings

Supalov, Alexander alexander.supalov at intel.com
Thu Jun 4 14:02:02 CDT 2009


It does and I believe this is said in the standard. My point is that adding yet another binding that looks "nicer" but does not resolve any of the fundamental issues already experienced by the existing Fortran interface is basically an exercise in futility.

-----Original Message-----
From: mpi3-fortran-bounces at lists.mpi-forum.org [mailto:mpi3-fortran-bounces at lists.mpi-forum.org] On Behalf Of Lionel, Steve
Sent: Thursday, June 04, 2009 8:51 PM
To: MPI-3 Fortran working group
Subject: Re: [MPI3 Fortran] MPI Fortran bindings

Well, this is why I am in favor of a C_PTR argument, as that avoids the copy in/out issue.  I think there is value in pressing ahead rather than waiting for some future feature.  If said feature becomes widely available, we can perhaps improve/revise the bindings at that time.  

As for code motion, that issue exists even with the F77 bindings, doesn't it?

Steve

-----Original Message-----
From: mpi3-fortran-bounces at lists.mpi-forum.org [mailto:mpi3-fortran-bounces at lists.mpi-forum.org] On Behalf Of Supalov, Alexander
Sent: Thursday, June 04, 2009 2:35 PM
To: MPI-3 Fortran working group
Subject: Re: [MPI3 Fortran] MPI Fortran bindings
Importance: Low

Hi,

I'm not sure the new Fortran bindings will justify any investment into them until the <any type and shape> has a commonly agreed and universally supported syntax in Fortran.

For me this is also connected to the copy-in/out issue, especially in the asynchronous calls. As far as I can see now, none of the proposed binding will be able to handle the MPI_STARTALL correctly, as an request array section passed to it will most likely suffer from copy-in/out and won't be usable in any completion call.

Not to mention that the completion call itself may well be moved above the MPI_STARTALL until the code motion issue is adequately resolved.

Maybe I'm overly pessimistic here, but as long as those three things are not addressed in a new Fortran binding, we can be just as well off with the ancient but popular Fortran 77 binding that openly suffers from those problems.

Best regards.

Alexander

-----Original Message-----
From: mpi3-fortran-bounces at lists.mpi-forum.org [mailto:mpi3-fortran-bounces at lists.mpi-forum.org] On Behalf Of Lionel, Steve
Sent: Thursday, June 04, 2009 8:06 PM
To: MPI-3 Fortran working group
Subject: Re: [MPI3 Fortran] MPI Fortran bindings

For publication in the document, even though I included "import" in the code I sent, I would remove it here. It distracts from the documentation, though it would be included in the actual module along with interface/end interface.

The:

<type>, dimension(*), intent(IN) :: BUF

Would have to be replaced with something real.  In the distant future, perhaps TYPE(*) would be available for this, but not now.  Most vendors do have an extension to disregard type and shape checking for arguments in an interface, but maybe not all do. It could be documented as <any type and shape> (without the dimension(*)) with a note that the actual mechanics of this are implementation-specific.  I know there is a modest argument against using C_PTR here because of the language's restriction that the argument of C_LOC be interoperable.

Coming up with other "kind" values for some of the arguments might also be in order.  If all you're looking for is formatting issues, then this doesn't matter.

Steve Lionel
Intel Developer Support
Nashua, NH



-----Original Message-----
From: mpi3-fortran-bounces at lists.mpi-forum.org [mailto:mpi3-fortran-bounces at lists.mpi-forum.org] On Behalf Of Jeff Squyres
Sent: Thursday, June 04, 2009 1:20 PM
To: MPI-3 Fortran working group
Subject: [MPI3 Fortran] MPI Fortran bindings
Importance: Low

I've made up some examples of how to list the Fortran bindings in the MPI spec based on the feedback I asked for a week or two ago.  I want to show these examples to the Forum, but before I do, can you all check them for correctness?

Page 1: the existing bindings as they appear in the existing spec Page 2: one version of the listing of new forms of bindings Page 3: another version of the listing of new forms of bindings

Pages 2 and 3 should have the same content, but slightly different Latex formatting.

Thanks.

--
Jeff Squyres
Cisco Systems

_______________________________________________
mpi3-fortran mailing list
mpi3-fortran at 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.


_______________________________________________
mpi3-fortran mailing list
mpi3-fortran at lists.mpi-forum.org
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran

_______________________________________________
mpi3-fortran mailing list
mpi3-fortran at 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.





More information about the mpiwg-fortran mailing list