Open MPI logo

Open MPI User's Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Open MPI User's mailing list

Subject: Re: [OMPI users] Regression: Fortran derived types with newer MPI module
From: Jed Brown (jedbrown_at_[hidden])
Date: 2014-01-07 23:23:12


"Jeff Squyres (jsquyres)" <jsquyres_at_[hidden]> writes:

> Yes, I can explain what's going on here. The short version is that a
> change was made with the intent to provide maximum Fortran code
> safety, but with a possible backwards compatibility issue. If this
> change is causing real problems, we can probably change this, but I'd
> like a little feedback from the Fortran MPI dev community first.

On page 610, I see text disallowing the explicit interfaces in
ompi/mpi/fortran/use-mpi-tkr:

  In S2 and S3: Without such extensions, routines with choice buffers should
  be provided with an implicit interface, instead of overloading with a different
  MPI function for each possible buffer type (as mentioned in Section 17.1.11 on
  page 625). Such overloading would also imply restrictions for passing Fortran
  derived types as choice buffer, see also Section 17.1.15 on page 629.

Why did OMPI decide that this (presumably non-normative) text in the
standard was not worth following? (Rejecting something in the standard
indicates stronger convictions than would be independently weighing the
benefits of each approach.)

> c) The design of the MPI-2 "mpi" module has multiple flaws that are
> identified in the MPI-3 text (but were not recognized back in MPI-2.x
> days). Here's one: until F2008+addendums, there was no Fortran
> equivalent of "void *". Hence, the mpi module has to overload
> MPI_Send() and have a prototype *for every possible type and
> dimension*.

And this is not possible, thus the text saying not to do it.

I don't call MPI from Fortran, but someone on a Fortran project that I
watch mentioned that the compiler would complain about such and such a
use (actually relating to types for MPI_Status in MPI_Recv rather than
buffer types). My immediate response was "they can't do that because
without nonstandard or post-F08 extensions (or exposing the user to
c_loc), the type system cannot express those functions and thus you
cannot have explicit interfaces". But then I looked at latest OMPI and
indeed, it was enumerating types, thus my email.

> Here's another fatal flaw: it's not possible for an MPI implementation
> to provide MPI_Send() prototypes for user-defined Fortran datatypes.
> Hence, the example you cite is a pipe dream for the "mpi" module
> because there's no way to specify a (void*)-like argument for the
> choice buffer.

F2003 has c_loc, which is a sufficient stop-gap until TS 29113 is widely
available. I have long-advocated that the best way to write extensible
libraries for Fortran2003 callers (even if the library is implemented
entirely in Fortran) involves some use of c_loc (e.g., for context
arguments).

This annoys the Fortran programmers and they usually write perl scripts
to generate interfaces that enumerate the types they need and give up on
extensibility. ;-)

It's nice to know that after 60 years (when Fortran 201x is released,
including TS 29113), there will be a Fortran standard with an analogue
of void*.

> Craig Rasmussen and I debated long and hard about whether to change
> the default from "small" to "medium" or not. We finally ended up
> doing it with the following rationale:
>
> - very few codes use the "mpi" module

FWIW, I've noticed a few projects transition to it in the last few years.

> - but those who do should have the maximum amount of compile-time protection
>
> ...but we always knew that someone may come complaining some day. And that day has now come.
>
> So my question to you / the Fortran MPI dev community is: what do you want (for gfortran)?
>
> Do you want us to go back to the "small" size by default, or do you
> want more compile-time protection by default? (with the obvious
> caveat that you can't use user-defined Fortran datatypes as choice
> buffers; you might be able to use something like c_loc, but I haven't
> thought deeply about this and don't know offhand if that works)

I can't answer this as a Fortran developer, but I know that a lot of
projects want some modicum of portability and in practice, it takes
almost 10 years to flush the old compilers out of production
environments. Either the upgrade problem will need to be fixed [1] so
that nearly all existing machines have new compilers or Fortran projects
will be wrestling with this for a long time yet.

Most Fortran packages I know use homogeneous arrays, which also means
that they don't call MPI_Type_create_struct or similar functions. If
those functions are going to be provided by the module, I think they
should be able to use them (e.g., examples in the Standard should work)
and the Standard's advice about implicit interfaces should be followed.

[1] Also, there are still production machines without MPI-2.0 and I get
email if I make a mistake in providing MPI-1 fallback paths.



  • application/pgp-signature attachment: stored