Re: [OMPI users] OMPI users] Fortran vs C reductions
Sorry to spoil the fun here, but this proposal is a very bad idea. It is
mandated by the MPI standard, page 25 line 27 (v3.1), not only to provide
all predefined datatypes, but to have support for them. There are optional
datatypes, but MPI_DOUBLE_PRECISION (which is explicitly the base
predefined datatype for MPI_2DOUBLE_PRECISION) is not one of them.
Now we can argue if DOUBLE PRECISION in Fortran is a double in C. As these
languages are interoperable, and there is no explicit conversion function,
it is safe to assume this is the case. Thus, is seems to me absolutely
legal to provide the MPI-required support for DOUBLE PRECISION despite the
fact that Fortran support is not enabled.
Now taking a closer look at the op, I see nothing in the standard the would
require to provide the op if the corresponding language is not supported.
While it could be nice (as a convenience for the users and also because
there is no technical reason not to) to enable the loc op, on non native
datatypes, this is not mandatory. Thus, the current behavior exposed by
Open MPI is acceptable from the standard perspective.
George.
On Mon, Feb 8, 2016 at 4:35 PM, Jeff Squyres (jsquyres)
wrote:
> Awesome; thanks Gilles.
>
>
> > On Feb 8, 2016, at 9:29 AM, Gilles Gouaillardet <
> gilles.gouaillar...@gmail.com> wrote:
> >
> > ok, will do
> >
> > Cheers,
> >
> > Gilles
> >
> > On Monday, February 8, 2016, Jeff Squyres (jsquyres)
> wrote:
> > I like your suggestion better -- if we can somehow report during the
> compile/link that the reason for the error is because Open MPI was not
> compiled with Fortran support, that would definitely be preferable.
> >
> > FWIW: my suggestion was because I wanted to convey the *reason* for the
> error (i.e., that OMPI has no Fortran support), and a pragma-based solution
> didn't occur to me. I didn't want to follow Gilles' suggestion of just
> removing the symbols, because that will lead to other confusion (e.g.,
> "Hey, Open MPI is not compliant because it doesn't have Fortran datatypes
> available in C!").
> >
> > Gilles: do you want to poke around and see if you can make any of Jeff's
> suggestions work out nicely? (i.e., give some kind of compile/link error
> that states that Open MPI was not built with Fortran support?)
> >
> >
> > On Feb 8, 2016, at 8:55 AM, Jeff Hammond wrote:
> > >
> > > Waiting until runtime to issue this error is a terrible idea, because
> then the PETSc team (among others) will disparage you for allowing a user
> to successfully build against an unusable library. They are on-record
> numerous times in the past as to the evils of e.g. no-op symbols in MPI or
> other runtime libraries, since this means that compile- and link-based
> tests pass, even though nothing good will happen when the user employs them
> in an application.
> > >
> > > The right thing to do is what Gilles proposed: do not define the types
> in mpi.h so that it is impossible to compile C code with Fortran datatypes,
> if Fortran datatypes are not supported. There are more and less effective
> ways to do this, in terms of letting the user know what is happening. For
> example, you can just not define them, which might confuse novices who
> don't know how to read error messages (HPC users are frequent offenders).
> > >
> > > You could use e.g.:
> > >
> > > #define MPI_DOUBLE_PRECISION choke me No Fortran support when library
> was compiled!
> > >
> > > Unfortunately, Clang colorized output emphasizes the wrong problem
> here, and ICC doesn't even echo the message at all in its error message.
> GCC issues the same error four times, and makes it relatively hard to miss
> the message.
> > >
> > > If the following GCC extension is supported, along with C99/C++11, you
> could do this:
> > >
> > > #define MPI_DOUBLE_PRECISION _Pragma("GCC error \"MPI was not compiled
> with Fortran support\"")
> > >
> > > For the _functions_ that require Fortran support, you can use e.g.
> __attribute__((error("no Fortran"))) on the function declaration, although
> neither ICC nor Clang support this, and it ends up throwing two error
> messages when compiled (only one - the right one - when only preprocessed),
> which might confuse the same folks that it is trying to help.
> > >
> > > Best,
> > >
> > > Jeff
> > >
> > > On Mon, Feb 8, 2016 at 5:14 AM, Jeff Squyres (jsquyres) <
> jsquy...@cisco.com> wrote:
> > > The issue at hand is trying to help the user figure out that they have
> an open MPI built without fortran support.
> > >
> > > Perhaps we should improve the error reporting at run time to display
> something about the fact that you used a fortran data type but have an OMPI
> that was compiled without fortran support.
> > >
> > > Sent from my phone. No type good.
> > >
> > > On Feb 8, 2016, at 4:00 AM, Gilles Gouaillardet <
> gilles.gouaillar...@gmail.com> wrote:
> > >
> > >> That being said, should we remove these fortran types from include
> files and libs when ompi is configure'd without fortran support ?
>
Re: [OMPI users] OMPI users] Fortran vs C reductions
George Bosilca writes: > Now we can argue if DOUBLE PRECISION in Fortran is a double in C. As these > languages are interoperable, and there is no explicit conversion function, > it is safe to assume this is the case. Thus, is seems to me absolutely > legal to provide the MPI-required support for DOUBLE PRECISION despite the > fact that Fortran support is not enabled. Isn't that entirely dependent on the Fortran compiler? There is no universal requirement that there be a relationship between Fortran INTEGER and C int, for example. > Now taking a closer look at the op, I see nothing in the standard the would > require to provide the op if the corresponding language is not supported. > While it could be nice (as a convenience for the users and also because > there is no technical reason not to) to enable the loc op, on non native > datatypes, this is not mandatory. Thus, the current behavior exposed by > Open MPI is acceptable from the standard perspective. I believe the question is not whether it's standard-compliant to define the types when they are not supported (the OP's usage doesn't sound valid anyway because they are using the Fortran MPI datatypes to refer to C types). Rather, the question is: if those types are non-functional, can/should they be removed from the header. This, for example, allows a configure script to test whether those datatypes exist. Feature tests are far more reliable, accurate, and lower maintenance than platform/version tests. When a package defines macros/symbols that fail at run-time, it makes feature tests much more expensive. Even more so when cross-compiling, where run-time tests require batch submission. The fact is that if a package makes it impractical to test features, the end-user experience reflects poorly on that package and all of its dependencies (though which user support passes). It's the sort of thing that drives users and developers away from the platform. Since I don't think you can make the Fortran types reliable without access to a Fortran compiler, my suggestion would be remove the symbols when Fortran is not available. signature.asc Description: PGP signature
Re: [OMPI users] OMPI users] Fortran vs C reductions
Jed, my 0.02US$ we recently had a kind of similar discussion about MPI_DATATYPE_NULL, and we concluded ompi should do its best to implement the MPI standard, and not what some of us think the standard should be. in your configure script, you can simply try to compile a simple fortran MPI hello world. if it fails, then you can assume fortran bindings are not available, and not use fortran types in your application. Cheers, Gilles On Tuesday, February 9, 2016, Jed Brown wrote: > George Bosilca > writes: > > > Now we can argue if DOUBLE PRECISION in Fortran is a double in C. As > these > > languages are interoperable, and there is no explicit conversion > function, > > it is safe to assume this is the case. Thus, is seems to me absolutely > > legal to provide the MPI-required support for DOUBLE PRECISION despite > the > > fact that Fortran support is not enabled. > > Isn't that entirely dependent on the Fortran compiler? There is no > universal requirement that there be a relationship between Fortran > INTEGER and C int, for example. > > > Now taking a closer look at the op, I see nothing in the standard the > would > > require to provide the op if the corresponding language is not supported. > > While it could be nice (as a convenience for the users and also because > > there is no technical reason not to) to enable the loc op, on non native > > datatypes, this is not mandatory. Thus, the current behavior exposed by > > Open MPI is acceptable from the standard perspective. > > I believe the question is not whether it's standard-compliant to define > the types when they are not supported (the OP's usage doesn't sound > valid anyway because they are using the Fortran MPI datatypes to refer > to C types). Rather, the question is: if those types are > non-functional, can/should they be removed from the header. This, for > example, allows a configure script to test whether those datatypes > exist. > > Feature tests are far more reliable, accurate, and lower maintenance > than platform/version tests. When a package defines macros/symbols that > fail at run-time, it makes feature tests much more expensive. Even more > so when cross-compiling, where run-time tests require batch submission. > > The fact is that if a package makes it impractical to test features, the > end-user experience reflects poorly on that package and all of its > dependencies (though which user support passes). It's the sort of thing > that drives users and developers away from the platform. > > Since I don't think you can make the Fortran types reliable without > access to a Fortran compiler, my suggestion would be remove the symbols > when Fortran is not available. >
Re: [OMPI users] OMPI users] Fortran vs C reductions
Jed Brown writes: > George Bosilca writes: > >> Now we can argue if DOUBLE PRECISION in Fortran is a double in C. As these >> languages are interoperable, and there is no explicit conversion function, >> it is safe to assume this is the case. Thus, is seems to me absolutely >> legal to provide the MPI-required support for DOUBLE PRECISION despite the >> fact that Fortran support is not enabled. > > Isn't that entirely dependent on the Fortran compiler? There is no > universal requirement that there be a relationship between Fortran > INTEGER and C int, for example. In case it's not generally obvious: the compiler _and its options_. You can typically change the width of real and double precision, as with gfortran -default-real-8, and similarly for integer. (It seems unKIND if the MPI standard specifically enshrines double precision, but anyhow...) > Feature tests are far more reliable, accurate, and lower maintenance > than platform/version tests. When a package defines macros/symbols that > fail at run-time, it makes feature tests much more expensive. Even more > so when cross-compiling, where run-time tests require batch submission. Right, but isn't the existence of the compiler wrapper the appropriate test for Fortran support, and don't you really need it to run Fortran-related feature tests? I have an "integer*8" build of OMPI, for instance. It's a pain generally when build systems for MPI stuff avoid compiler wrappers, and I'd hope that using them could make possibly-unfortunate standards requirements like this moot. Would there be a problem with that in this case?
Re: [OMPI users] Help with OpenMPI and Univa Grid Engine
Rahul Pisharody writes: > Hello all, > > I'm trying to get a simple program (print the hostname of the executing > machine) compiled with openmpi run across multiple machines on Univa Grid > Engine. > > This particular configuration has many of the ports blocked. My run command > has the mca options necessary to limit the ports to the known open ports. > > However, when I launch the program with mpirun, I get the following error > messages: > > + >> error: executing task of job 23 failed: execution daemon on host >> "" didn't accept task So you have a grid engine problem and you're paying Univa a load of money (with one of the selling points being MPI support, if I recall correctly)...
Re: [OMPI users] OMPI users] Fortran vs C reductions
On Feb 9, 2016, at 12:21 AM, George Bosilca wrote:
>
> Sorry to spoil the fun here, but this proposal is a very bad idea. It is
> mandated by the MPI standard, page 25 line 27 (v3.1), not only to provide all
> predefined datatypes, but to have support for them. There are optional
> datatypes, but MPI_DOUBLE_PRECISION (which is explicitly the base predefined
> datatype for MPI_2DOUBLE_PRECISION) is not one of them.
I don't quite follow the logic here.
The mpif.h interface is mandated by The MPI spec. If you're building Open MPI
on a platform without a Fortran compiler, then by definition, you don't get a
compliant MPI implementation because you're missing a key requirement (i.e., a
Fortran compiler). We -- the Open MPI developers -- have chosen to enable this
non-conformant scenario because there are valid use cases for it with our users.
Meaning: there is no question that this is not conformant behavior. Saying
that we can't do it because it is not conformat is tautological.
What we're discussing is how to make the behavior useful to end users in this
already-defined-to-be-non-conformant situation.
Also, note that Open MPI disables a bunch of other datatypes if they can't be
supported -- just search for the use of the macro UNAVAILABLE in
ompi/datatype/ompi_datatype_internal.h (which lead to run-time failures if they
can't be used). The question here is whether that should be a compile time vs.
run time failure. I think there's good arguments for making them be compile
time failures, if possible.
> Now we can argue if DOUBLE PRECISION in Fortran is a double in C.
FWIW:
1. MPI-3.1 Annex A p674 states that MPI_DOUBLE_PRECISION is a Fortran datatype
that corresponds to the Fortran type "DOUBLE PRECISION".
2. MPI-3.1 5.9.4 p180 declares MPI_2DOUBLE_PRECISION to be a pair of Fortran
DOUBLE PRECISION variables.
Whether or not DOUBLE PRECISION is exactly equivalent to a C double is an
entirely different question.
> As these languages are interoperable,
That's an extremely broad statement. :-)
To be pedantic: there are many things in each language that do not exactly
interoperate with each other. Indeed, F08 explicitly added a bunch of things
to the Fortran language to precisely allow interop between C and Fortran (e.g.,
continued enhancements to the definitions of BIND(C) and related things). But
there are still many things between that two that are not identical -- the two
languages do not have a 1-to-1 correspondence for every one of their features.
> and there is no explicit conversion function, it is safe to assume this is
> the case.
Whether or not Fortran's DOUBLE PRECISION is exactly equivalent to a C double
(and whether a pair of Fortran DOUBLE precision variables is exactly equivalent
to a pair of C double variables) is not something you can assume.
Easy case to pick on: what if the user compiles their Fortran program with -i
8? (i.e., integers are double their normal size) We tell Open MPI users that
this scenario is supported, but only if they configure Open MPI with
FCFLAGS="-i 8" so that Open MPI's configure can figure out that INTEGER is 8
bytes long (and therefore doesn't correspond to a C int). ...and so on.
There's a similar compiler flag for floating point values ("-d 8"? I don't
remember offhand), that makes the assumption that Fortran DOUBLE PRECISION ===
C double a bad one.
Also, we've definitely run into cases in the past where the alignments of
Fortran datatypes are different than the alignments of C datatypes.
In short: the only way that we can *know* that a Fortran datatype is equivalent
to a C datatype is to actually *test* it. Given that Open MPI already disables
a bunch of datatypes when it can't support them, it's not unreadable to
a) disable all Fortran types when Open MPI was not configure with a Fortran
compiler, and
--> OR Provide the option for the user to choose between
"You didn't configure with a Fortran compiler, so I'll assume C
types===Fortran types" (i.e., some of today's behavior), and
"You didn't configure with a Fortran compiler, so I'll disable all
Fortran types"
b) see if we can make unsupported datatypes be compile-time failures instead of
run-time failures.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [OMPI users] OMPI users] Fortran vs C reductions
Gilles Gouaillardet writes: > Jed, > > my 0.02US$ > > we recently had a kind of similar discussion about MPI_DATATYPE_NULL, and > we concluded > ompi should do its best to implement the MPI standard, and not what some of > us think the standard should be. Did anyone suggest violating the standard? > in your configure script, you can simply try to compile a simple fortran > MPI hello world. > if it fails, then you can assume fortran bindings are not available, and > not use fortran types in your application. With which compiler? Remember that we're talking about the C macros -- the user of those might not have any Fortran in their code. Like suppose I have a C library that implements a custom reduction. I'll need to be checking the datatype to dispatch to a concrete implementation. Must I compile in support for being called with MPI_DOUBLE_COMPLEX? signature.asc Description: PGP signature
Re: [OMPI users] OMPI users] Fortran vs C reductions
Dave Love writes: > Jed Brown writes: > >> Isn't that entirely dependent on the Fortran compiler? There is no >> universal requirement that there be a relationship between Fortran >> INTEGER and C int, for example. > > In case it's not generally obvious: the compiler _and its options_. > You can typically change the width of real and double precision, as with > gfortran -default-real-8, and similarly for integer. (It seems unKIND > if the MPI standard specifically enshrines double precision, but > anyhow...) Indeed. (Though such options are an abomination.) >> Feature tests are far more reliable, accurate, and lower maintenance >> than platform/version tests. When a package defines macros/symbols that >> fail at run-time, it makes feature tests much more expensive. Even more >> so when cross-compiling, where run-time tests require batch submission. > > Right, but isn't the existence of the compiler wrapper the appropriate > test for Fortran support, and don't you really need it to run > Fortran-related feature tests? The wrapper might not exist. It doesn't on many prominent platforms today. > I have an "integer*8" build of OMPI, for instance. It's a pain > generally when build systems for MPI stuff avoid compiler wrappers, > and I'd hope that using them could make possibly-unfortunate standards > requirements like this moot. Would there be a problem with that in > this case? In the example of my other reply, my library would not need to call MPI From Fortran, but needs to know whether it needs to compile support for decoding Fortran datatypes. My personal opinion is that compiler wrappers are gross (they don't compose), but systems like CMake that insist on circumventing compiler wrappers in a yet more error-prone way are worse. signature.asc Description: PGP signature
Re: [OMPI users] OMPI users] Fortran vs C reductions
"MPI-3.0 (and later) compliant Fortran bindings are not only a property of
the MPI library itself, but rather a property of an MPI library together
with the Fortran compiler suite for which it is compiled." (MPI 3.1 Section
17.1.7).
Of course, implementations can provide support in excess of the minimum
required by the standard, provided that support remains compliant with the
standard.
Jeff
On Mon, Feb 8, 2016 at 9:21 PM, George Bosilca wrote:
>
> Sorry to spoil the fun here, but this proposal is a very bad idea. It is
mandated by the MPI standard, page 25 line 27 (v3.1), not only to provide
all predefined datatypes, but to have support for them. There are optional
datatypes, but MPI_DOUBLE_PRECISION (which is explicitly the base
predefined datatype for MPI_2DOUBLE_PRECISION) is not one of them.
>
> Now we can argue if DOUBLE PRECISION in Fortran is a double in C. As
these languages are interoperable, and there is no explicit conversion
function, it is safe to assume this is the case. Thus, is seems to me
absolutely legal to provide the MPI-required support for DOUBLE PRECISION
despite the fact that Fortran support is not enabled.
>
> Now taking a closer look at the op, I see nothing in the standard the
would require to provide the op if the corresponding language is not
supported. While it could be nice (as a convenience for the users and also
because there is no technical reason not to) to enable the loc op, on non
native datatypes, this is not mandatory. Thus, the current behavior exposed
by Open MPI is acceptable from the standard perspective.
>
> George.
>
>
> On Mon, Feb 8, 2016 at 4:35 PM, Jeff Squyres (jsquyres) <
jsquy...@cisco.com> wrote:
>>
>> Awesome; thanks Gilles.
>>
>>
>> > On Feb 8, 2016, at 9:29 AM, Gilles Gouaillardet <
gilles.gouaillar...@gmail.com> wrote:
>> >
>> > ok, will do
>> >
>> > Cheers,
>> >
>> > Gilles
>> >
>> > On Monday, February 8, 2016, Jeff Squyres (jsquyres) <
jsquy...@cisco.com> wrote:
>> > I like your suggestion better -- if we can somehow report during the
compile/link that the reason for the error is because Open MPI was not
compiled with Fortran support, that would definitely be preferable.
>> >
>> > FWIW: my suggestion was because I wanted to convey the *reason* for
the error (i.e., that OMPI has no Fortran support), and a pragma-based
solution didn't occur to me. I didn't want to follow Gilles' suggestion of
just removing the symbols, because that will lead to other confusion (e.g.,
"Hey, Open MPI is not compliant because it doesn't have Fortran datatypes
available in C!").
>> >
>> > Gilles: do you want to poke around and see if you can make any of
Jeff's suggestions work out nicely? (i.e., give some kind of compile/link
error that states that Open MPI was not built with Fortran support?)
>> >
>> >
>> > On Feb 8, 2016, at 8:55 AM, Jeff Hammond
wrote:
>> > >
>> > > Waiting until runtime to issue this error is a terrible idea,
because then the PETSc team (among others) will disparage you for allowing
a user to successfully build against an unusable library. They are
on-record numerous times in the past as to the evils of e.g. no-op symbols
in MPI or other runtime libraries, since this means that compile- and
link-based tests pass, even though nothing good will happen when the user
employs them in an application.
>> > >
>> > > The right thing to do is what Gilles proposed: do not define the
types in mpi.h so that it is impossible to compile C code with Fortran
datatypes, if Fortran datatypes are not supported. There are more and less
effective ways to do this, in terms of letting the user know what is
happening. For example, you can just not define them, which might confuse
novices who don't know how to read error messages (HPC users are frequent
offenders).
>> > >
>> > > You could use e.g.:
>> > >
>> > > #define MPI_DOUBLE_PRECISION choke me No Fortran support when
library was compiled!
>> > >
>> > > Unfortunately, Clang colorized output emphasizes the wrong problem
here, and ICC doesn't even echo the message at all in its error message.
GCC issues the same error four times, and makes it relatively hard to miss
the message.
>> > >
>> > > If the following GCC extension is supported, along with C99/C++11,
you could do this:
>> > >
>> > > #define MPI_DOUBLE_PRECISION _Pragma("GCC error \"MPI was not
compiled with Fortran support\"")
>> > >
>> > > For the _functions_ that require Fortran support, you can use e.g.
__attribute__((error("no Fortran"))) on the function declaration, although
neither ICC nor Clang support this, and it ends up throwing two error
messages when compiled (only one - the right one - when only preprocessed),
which might confuse the same folks that it is trying to help.
>> > >
>> > > Best,
>> > >
>> > > Jeff
>> > >
>> > > On Mon, Feb 8, 2016 at 5:14 AM, Jeff Squyres (jsquyres) <
jsquy...@cisco.com> wrote:
>> > > The issue at hand is trying to help the user figure out that they
have an open MPI built without fortran support.
>> > >
>> > >
Re: [OMPI users] Help with OpenMPI and Univa Grid Engine
Hello Ralph, Dave, Thank you for your suggestions. Let me check on the nfs mounts. The problem is I am not the grid administrator. I'm working with the grid administrator to get it resolved. If I had my way, I would be probably using Sun Grid. Thank you Dave for pointing out something that I had missed. Let me ask the admin to check with the Univa guys as well. Thanks, Rahul On Tue, Feb 9, 2016 at 4:43 AM, Dave Love wrote: > Rahul Pisharody writes: > > > Hello all, > > > > I'm trying to get a simple program (print the hostname of the executing > > machine) compiled with openmpi run across multiple machines on Univa Grid > > Engine. > > > > This particular configuration has many of the ports blocked. My run > command > > has the mca options necessary to limit the ports to the known open ports. > > > > However, when I launch the program with mpirun, I get the following error > > messages: > > > > + > >> error: executing task of job 23 failed: execution daemon on host > >> "" didn't accept task > > So you have a grid engine problem and you're paying Univa a load of > money (with one of the selling points being MPI support, if I recall > correctly)... > ___ > users mailing list > us...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users > Link to this post: > http://www.open-mpi.org/community/lists/users/2016/02/28473.php >
Re: [OMPI users] OMPI users] Fortran vs C reductions
The text you pinpoint is clear about the target: the MPI bindings. The
question here is not about bindings, but about a predefined datatype, a
case where I don't think the text applies.
George.
On Tue, Feb 9, 2016 at 6:17 PM, Jeff Hammond wrote:
> "MPI-3.0 (and later) compliant Fortran bindings are not only a property of
> the MPI library itself, but rather a property of an MPI library together
> with the Fortran compiler suite for which it is compiled." (MPI 3.1 Section
> 17.1.7).
>
> Of course, implementations can provide support in excess of the minimum
> required by the standard, provided that support remains compliant with the
> standard.
>
> Jeff
>
>
> On Mon, Feb 8, 2016 at 9:21 PM, George Bosilca
> wrote:
> >
> > Sorry to spoil the fun here, but this proposal is a very bad idea. It is
> mandated by the MPI standard, page 25 line 27 (v3.1), not only to provide
> all predefined datatypes, but to have support for them. There are optional
> datatypes, but MPI_DOUBLE_PRECISION (which is explicitly the base
> predefined datatype for MPI_2DOUBLE_PRECISION) is not one of them.
> >
> > Now we can argue if DOUBLE PRECISION in Fortran is a double in C. As
> these languages are interoperable, and there is no explicit conversion
> function, it is safe to assume this is the case. Thus, is seems to me
> absolutely legal to provide the MPI-required support for DOUBLE PRECISION
> despite the fact that Fortran support is not enabled.
> >
> > Now taking a closer look at the op, I see nothing in the standard the
> would require to provide the op if the corresponding language is not
> supported. While it could be nice (as a convenience for the users and also
> because there is no technical reason not to) to enable the loc op, on non
> native datatypes, this is not mandatory. Thus, the current behavior exposed
> by Open MPI is acceptable from the standard perspective.
> >
> > George.
> >
> >
> > On Mon, Feb 8, 2016 at 4:35 PM, Jeff Squyres (jsquyres) <
> jsquy...@cisco.com> wrote:
> >>
> >> Awesome; thanks Gilles.
> >>
> >>
> >> > On Feb 8, 2016, at 9:29 AM, Gilles Gouaillardet <
> gilles.gouaillar...@gmail.com> wrote:
> >> >
> >> > ok, will do
> >> >
> >> > Cheers,
> >> >
> >> > Gilles
> >> >
> >> > On Monday, February 8, 2016, Jeff Squyres (jsquyres) <
> jsquy...@cisco.com> wrote:
> >> > I like your suggestion better -- if we can somehow report during the
> compile/link that the reason for the error is because Open MPI was not
> compiled with Fortran support, that would definitely be preferable.
> >> >
> >> > FWIW: my suggestion was because I wanted to convey the *reason* for
> the error (i.e., that OMPI has no Fortran support), and a pragma-based
> solution didn't occur to me. I didn't want to follow Gilles' suggestion of
> just removing the symbols, because that will lead to other confusion (e.g.,
> "Hey, Open MPI is not compliant because it doesn't have Fortran datatypes
> available in C!").
> >> >
> >> > Gilles: do you want to poke around and see if you can make any of
> Jeff's suggestions work out nicely? (i.e., give some kind of compile/link
> error that states that Open MPI was not built with Fortran support?)
> >> >
> >> >
> >> > On Feb 8, 2016, at 8:55 AM, Jeff Hammond
> wrote:
> >> > >
> >> > > Waiting until runtime to issue this error is a terrible idea,
> because then the PETSc team (among others) will disparage you for allowing
> a user to successfully build against an unusable library. They are
> on-record numerous times in the past as to the evils of e.g. no-op symbols
> in MPI or other runtime libraries, since this means that compile- and
> link-based tests pass, even though nothing good will happen when the user
> employs them in an application.
> >> > >
> >> > > The right thing to do is what Gilles proposed: do not define the
> types in mpi.h so that it is impossible to compile C code with Fortran
> datatypes, if Fortran datatypes are not supported. There are more and less
> effective ways to do this, in terms of letting the user know what is
> happening. For example, you can just not define them, which might confuse
> novices who don't know how to read error messages (HPC users are frequent
> offenders).
> >> > >
> >> > > You could use e.g.:
> >> > >
> >> > > #define MPI_DOUBLE_PRECISION choke me No Fortran support when
> library was compiled!
> >> > >
> >> > > Unfortunately, Clang colorized output emphasizes the wrong problem
> here, and ICC doesn't even echo the message at all in its error message.
> GCC issues the same error four times, and makes it relatively hard to miss
> the message.
> >> > >
> >> > > If the following GCC extension is supported, along with C99/C++11,
> you could do this:
> >> > >
> >> > > #define MPI_DOUBLE_PRECISION _Pragma("GCC error \"MPI was not
> compiled with Fortran support\"")
> >> > >
> >> > > For the _functions_ that require Fortran support, you can use e.g.
> __attribute__((error("no Fortran"))) on the function declaration, although
> neither ICC no
Re: [OMPI users] OMPI users] Fortran vs C reductions
The only agreement we have so far is that from the perspective of a user having a questionable usage of a particular datatype in a extremely particular reduction operation the situation can be perceived as unfriendly. Your argument is that if in a particular OMPI installation Fortran support is not provided, we should not provide any of the MPI Fortran datatypes because of possible mismatch between the different types and compilers involved. Allow me to turn this question around: In which language we provide (and always provided) support for all ops related to Fortran datatypes? Thus, your argument is fallacious, based on the uncertain expectation that only a Fortran function is able to correctly handle basic Fortran types. My argument is that support for Fortran datatype is trivial to provide (and mandated by the standard). To sustain my argument I claim that despite the fact that we provide all the operators for all the types in C, including for the predefined Fortran and CXX datatypes, we had zero complains about any potential issue with them. Taking in account the wild combination of platforms, compilers and configuration environments where Open MPI is deployed, from a pragmatic perspective this highly suggest that indeed DOUBLE PRECISION and double are more similar than you think they are, and that our original assumption when designing the datatype support was valid. I like pragmatic solutions, if it's not broken or fun to implement, I don't get excited. And honestly the issue at hand doesn't qualify for none of the above. You want a simple solution? Enable all ops for all basic predefined types, even when Fortran support is not provided. 10 lines of code, that will save everybody's time, and that based on prior experiences will always provide the correct outcome. The bonus here is that this will allow our users to reach the serendipity JeffH was talking about. George. On Tue, Feb 9, 2016 at 3:51 PM, Jeff Squyres (jsquyres) wrote: > On Feb 9, 2016, at 12:21 AM, George Bosilca wrote: > > > > Sorry to spoil the fun here, but this proposal is a very bad idea. It is > mandated by the MPI standard, page 25 line 27 (v3.1), not only to provide > all predefined datatypes, but to have support for them. There are optional > datatypes, but MPI_DOUBLE_PRECISION (which is explicitly the base > predefined datatype for MPI_2DOUBLE_PRECISION) is not one of them. > > I don't quite follow the logic here. > > The mpif.h interface is mandated by The MPI spec. If you're building Open > MPI on a platform without a Fortran compiler, then by definition, you don't > get a compliant MPI implementation because you're missing a key requirement > (i.e., a Fortran compiler). We -- the Open MPI developers -- have chosen > to enable this non-conformant scenario because there are valid use cases > for it with our users. > > Meaning: there is no question that this is not conformant behavior. > Saying that we can't do it because it is not conformat is tautological. > > What we're discussing is how to make the behavior useful to end users in > this already-defined-to-be-non-conformant situation. > > Also, note that Open MPI disables a bunch of other datatypes if they can't > be supported -- just search for the use of the macro UNAVAILABLE in > ompi/datatype/ompi_datatype_internal.h (which lead to run-time failures if > they can't be used). The question here is whether that should be a compile > time vs. run time failure. I think there's good arguments for making them > be compile time failures, if possible. > > > Now we can argue if DOUBLE PRECISION in Fortran is a double in C. > > FWIW: > > 1. MPI-3.1 Annex A p674 states that MPI_DOUBLE_PRECISION is a Fortran > datatype that corresponds to the Fortran type "DOUBLE PRECISION". > 2. MPI-3.1 5.9.4 p180 declares MPI_2DOUBLE_PRECISION to be a pair of > Fortran DOUBLE PRECISION variables. > > Whether or not DOUBLE PRECISION is exactly equivalent to a C double is an > entirely different question. > > > As these languages are interoperable, > > That's an extremely broad statement. :-) > > To be pedantic: there are many things in each language that do not exactly > interoperate with each other. Indeed, F08 explicitly added a bunch of > things to the Fortran language to precisely allow interop between C and > Fortran (e.g., continued enhancements to the definitions of BIND(C) and > related things). But there are still many things between that two that are > not identical -- the two languages do not have a 1-to-1 correspondence for > every one of their features. > > > and there is no explicit conversion function, it is safe to assume this > is the case. > > Whether or not Fortran's DOUBLE PRECISION is exactly equivalent to a C > double (and whether a pair of Fortran DOUBLE precision variables is exactly > equivalent to a pair of C double variables) is not something you can assume. > > Easy case to pick on: what if the user compiles their Fortran program with > -i 8? (i.e., integ
Re: [OMPI users] OMPI users] Fortran vs C reductions
Then we should clarify the spec, because it's unreasonable to require MPI support a Fortran type without being able to know its representation. Jeff On Tuesday, February 9, 2016, George Bosilca wrote: > The text you pinpoint is clear about the target: the MPI bindings. The > question here is not about bindings, but about a predefined datatype, a > case where I don't think the text applies. > > George. > > > On Tue, Feb 9, 2016 at 6:17 PM, Jeff Hammond > wrote: > >> "MPI-3.0 (and later) compliant Fortran bindings are not only a property >> of the MPI library itself, but rather a property of an MPI library together >> with the Fortran compiler suite for which it is compiled." (MPI 3.1 Section >> 17.1.7). >> >> Of course, implementations can provide support in excess of the minimum >> required by the standard, provided that support remains compliant with the >> standard. >> >> Jeff >> >> >> On Mon, Feb 8, 2016 at 9:21 PM, George Bosilca > > wrote: >> > >> > Sorry to spoil the fun here, but this proposal is a very bad idea. It >> is mandated by the MPI standard, page 25 line 27 (v3.1), not only to >> provide all predefined datatypes, but to have support for them. There are >> optional datatypes, but MPI_DOUBLE_PRECISION (which is explicitly the base >> predefined datatype for MPI_2DOUBLE_PRECISION) is not one of them. >> > >> > Now we can argue if DOUBLE PRECISION in Fortran is a double in C. As >> these languages are interoperable, and there is no explicit conversion >> function, it is safe to assume this is the case. Thus, is seems to me >> absolutely legal to provide the MPI-required support for DOUBLE PRECISION >> despite the fact that Fortran support is not enabled. >> > >> > Now taking a closer look at the op, I see nothing in the standard the >> would require to provide the op if the corresponding language is not >> supported. While it could be nice (as a convenience for the users and also >> because there is no technical reason not to) to enable the loc op, on non >> native datatypes, this is not mandatory. Thus, the current behavior exposed >> by Open MPI is acceptable from the standard perspective. >> > >> > George. >> > >> > >> > On Mon, Feb 8, 2016 at 4:35 PM, Jeff Squyres (jsquyres) < >> jsquy...@cisco.com > >> wrote: >> >> >> >> Awesome; thanks Gilles. >> >> >> >> >> >> > On Feb 8, 2016, at 9:29 AM, Gilles Gouaillardet < >> gilles.gouaillar...@gmail.com >> > wrote: >> >> > >> >> > ok, will do >> >> > >> >> > Cheers, >> >> > >> >> > Gilles >> >> > >> >> > On Monday, February 8, 2016, Jeff Squyres (jsquyres) < >> jsquy...@cisco.com > >> wrote: >> >> > I like your suggestion better -- if we can somehow report during the >> compile/link that the reason for the error is because Open MPI was not >> compiled with Fortran support, that would definitely be preferable. >> >> > >> >> > FWIW: my suggestion was because I wanted to convey the *reason* for >> the error (i.e., that OMPI has no Fortran support), and a pragma-based >> solution didn't occur to me. I didn't want to follow Gilles' suggestion of >> just removing the symbols, because that will lead to other confusion (e.g., >> "Hey, Open MPI is not compliant because it doesn't have Fortran datatypes >> available in C!"). >> >> > >> >> > Gilles: do you want to poke around and see if you can make any of >> Jeff's suggestions work out nicely? (i.e., give some kind of compile/link >> error that states that Open MPI was not built with Fortran support?) >> >> > >> >> > >> >> > On Feb 8, 2016, at 8:55 AM, Jeff Hammond > > wrote: >> >> > > >> >> > > Waiting until runtime to issue this error is a terrible idea, >> because then the PETSc team (among others) will disparage you for allowing >> a user to successfully build against an unusable library. They are >> on-record numerous times in the past as to the evils of e.g. no-op symbols >> in MPI or other runtime libraries, since this means that compile- and >> link-based tests pass, even though nothing good will happen when the user >> employs them in an application. >> >> > > >> >> > > The right thing to do is what Gilles proposed: do not define the >> types in mpi.h so that it is impossible to compile C code with Fortran >> datatypes, if Fortran datatypes are not supported. There are more and less >> effective ways to do this, in terms of letting the user know what is >> happening. For example, you can just not define them, which might confuse >> novices who don't know how to read error messages (HPC users are frequent >> offenders). >> >> > > >> >> > > You could use e.g.: >> >> > > >> >> > > #define MPI_DOUBLE_PRECISION choke me No Fortran support when >> library was compiled! >> >> > > >> >> > > Unfortunately, Clang colorized output emphasizes the wrong problem >> here, and ICC doesn't even echo the message at all in its error message. >> GCC issues the same error four times, and makes it relatively hard to miss >> the message. >> >> > > >> >> > > If the following GCC extension is supported, alon
Re: [OMPI users] OMPI users] Fortran vs C reductions
Jed, On 2/10/2016 12:18 AM, Jed Brown wrote: Did anyone suggest violating the standard? if i understand correctly what George wrote earlier, then yes, removing predefined datatypes from the header files can be seen as a violation of the standard in your configure script, you can simply try to compile a simple fortran MPI hello world. if it fails, then you can assume fortran bindings are not available, and not use fortran types in your application. With which compiler? Remember that we're talking about the C macros -- the user of those might not have any Fortran in their code. Like suppose I have a C library that implements a custom reduction. I'll need to be checking the datatype to dispatch to a concrete implementation. Must I compile in support for being called with MPI_DOUBLE_COMPLEX? does that really matter ? i assume your library and the user code are built with the same OpenMPI. if there is no Fortran support, then you are compiling code that cannot be invoked (e.g. dead code), and though that is not the most elegant thing to do, that does not sound like a showstopper to me. so yes, compile in support for being called with Fortran predefined datatypes, worst case scenario is you generate broken dead code. Cheers, Gilles
