Re: [OMPI devel] opal / fortran / Flogical
On Jun 2, 2009, at 10:24 AM, Rainer Keller wrote: no, that's not an issue. The comment is correct: For any Fortran integer*kind we need to have _some_ C-representation as well, otherwise we disregard the type (tm), see e.g. the old and resolved ticket #1094. The representation chosen is set in opal/util/arch.c and is conclusive as far as I can tell... Doesn't that mean that the comment is misleading? I interpret it as saying that a Fortran "default integer" is always the same as a C "int". I believe that you are saying that it really means that *any* kind of Fortran integer must be the same as one of C's integral types, or OpenMPI won't support it at all. Shouldn't the comment be clearer? Iain
Re: [OMPI devel] opal / fortran / Flogical
I'm not entirely sure what comment is being discussed. The comment in opal/util/arch.c (written by me long ago) should not be taken seriously - it was nothing more than a half-hearted attempt to appease the stormy controversy (mostly objections from George and a little from Brian) created by my moving this code to OPAL. It had no technical validity behind it at all. Somewhat amusing to see that comment now used as justification for leaving the code there by some of the same people. ;-) The question of whether or not we accurately deal with Fortran variable sizes was always present, even when this code was in the OMPI layer. It is a tad troublesome as Fortran advocates -do- occasionally set the flags that can cause the variables to differ from their C counterparts. Rather than some obscure comment in the source code, we should probably generate a warning and (hopefully) abort when someone uses those flags to avoid creating hard-to-debug errors. On Wed, Jun 3, 2009 at 10:58 AM, Iain Bason wrote: > > On Jun 2, 2009, at 10:24 AM, Rainer Keller wrote: > > no, that's not an issue. The comment is correct: For any Fortran >> integer*kind >> we need to have _some_ C-representation as well, otherwise we disregard >> the >> type (tm), see e.g. the old and resolved ticket #1094. >> The representation chosen is set in opal/util/arch.c and is conclusive as >> far >> as I can tell... >> > > Doesn't that mean that the comment is misleading? I interpret it as saying > that a Fortran "default integer" is always the same as a C "int". I believe > that you are saying that it really means that *any* kind of Fortran integer > must be the same as one of C's integral types, or OpenMPI won't support it > at all. Shouldn't the comment be clearer? > > Iain > > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel >
Re: [OMPI devel] opal / fortran / Flogical
On Jun 3, 2009, at 13:30 , Ralph Castain wrote: I'm not entirely sure what comment is being discussed. The comment in opal/util/arch.c (written by me long ago) should not be taken seriously - it was nothing more than a half-hearted attempt to appease the stormy controversy (mostly objections from George and a little from Brian) created by my moving this code to OPAL. It had no technical validity behind it at all. Somewhat amusing to see that comment now used as justification for leaving the code there by some of the same people. ;-) I think there is a misinterpretation of my justification. The architecture code was, from the beginning, specifically crafted for the datatype engine. Using it elsewhere, might make sense, however only the datatype engine can really take full advantage of it. Therefore, I believe this code should stay inside the datatype engine, whatever layer in Open MPI this engine will be. The question of whether or not we accurately deal with Fortran variable sizes was always present, even when this code was in the OMPI layer. It is a tad troublesome as Fortran advocates -do- occasionally set the flags that can cause the variables to differ from their C counterparts. Rather than some obscure comment in the source code, we should probably generate a warning and (hopefully) abort when someone uses those flags to avoid creating hard-to-debug errors. Most types existing in other programming languages will be supported to a certain extent. As an example, all Fortran integer types __WILL__ be supported. One notable exception will be the "QUAD" floating point type provided by the Fortran compiler. While there is a similar type in C, it is compiler and platform dependent, and the representation of the C and the Fortran type differs. As a result, even if we would like to support this type, we will not be able to do the conversions (by lack of knowledge about the internal representation). However, this is the only type I'm aware of that we will not be able to support. In fact, this type is not supported today in Open MPI, so there will be no lost of functionality. george. On Wed, Jun 3, 2009 at 10:58 AM, Iain Bason wrote: On Jun 2, 2009, at 10:24 AM, Rainer Keller wrote: no, that's not an issue. The comment is correct: For any Fortran integer*kind we need to have _some_ C-representation as well, otherwise we disregard the type (tm), see e.g. the old and resolved ticket #1094. The representation chosen is set in opal/util/arch.c and is conclusive as far as I can tell... Doesn't that mean that the comment is misleading? I interpret it as saying that a Fortran "default integer" is always the same as a C "int". I believe that you are saying that it really means that *any* kind of Fortran integer must be the same as one of C's integral types, or OpenMPI won't support it at all. Shouldn't the comment be clearer? Iain ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] opal / fortran / Flogical
Ah - thanks for clarifying, George, on both counts! :-) On Wed, Jun 3, 2009 at 11:43 AM, George Bosilca wrote: > > On Jun 3, 2009, at 13:30 , Ralph Castain wrote: > > I'm not entirely sure what comment is being discussed. The comment in >> opal/util/arch.c (written by me long ago) should not be taken seriously - it >> was nothing more than a half-hearted attempt to appease the stormy >> controversy (mostly objections from George and a little from Brian) created >> by my moving this code to OPAL. It had no technical validity behind it at >> all. >> >> Somewhat amusing to see that comment now used as justification for leaving >> the code there by some of the same people. ;-) >> > > I think there is a misinterpretation of my justification. The architecture > code was, from the beginning, specifically crafted for the datatype engine. > Using it elsewhere, might make sense, however only the datatype engine can > really take full advantage of it. Therefore, I believe this code should stay > inside the datatype engine, whatever layer in Open MPI this engine will be. > > The question of whether or not we accurately deal with Fortran variable >> sizes was always present, even when this code was in the OMPI layer. It is a >> tad troublesome as Fortran advocates -do- occasionally set the flags that >> can cause the variables to differ from their C counterparts. Rather than >> some obscure comment in the source code, we should probably generate a >> warning and (hopefully) abort when someone uses those flags to avoid >> creating hard-to-debug errors. >> > > Most types existing in other programming languages will be supported to a > certain extent. As an example, all Fortran integer types __WILL__ be > supported. One notable exception will be the "QUAD" floating point type > provided by the Fortran compiler. While there is a similar type in C, it is > compiler and platform dependent, and the representation of the C and the > Fortran type differs. As a result, even if we would like to support this > type, we will not be able to do the conversions (by lack of knowledge about > the internal representation). > > However, this is the only type I'm aware of that we will not be able to > support. In fact, this type is not supported today in Open MPI, so there > will be no lost of functionality. > > george. > > > >> >> On Wed, Jun 3, 2009 at 10:58 AM, Iain Bason wrote: >> >> On Jun 2, 2009, at 10:24 AM, Rainer Keller wrote: >> >> no, that's not an issue. The comment is correct: For any Fortran >> integer*kind >> we need to have _some_ C-representation as well, otherwise we disregard >> the >> type (tm), see e.g. the old and resolved ticket #1094. >> The representation chosen is set in opal/util/arch.c and is conclusive as >> far >> as I can tell... >> >> Doesn't that mean that the comment is misleading? I interpret it as >> saying that a Fortran "default integer" is always the same as a C "int". I >> believe that you are saying that it really means that *any* kind of Fortran >> integer must be the same as one of C's integral types, or OpenMPI won't >> support it at all. Shouldn't the comment be clearer? >> >> Iain >> >> >> ___ >> devel mailing list >> de...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/devel >> >> ___ >> devel mailing list >> de...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/devel >> > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel >
Re: [OMPI devel] opal / fortran / Flogical
Hello, On Wednesday 03 June 2009 12:58:50 pm Iain Bason wrote: > > no, that's not an issue. The comment is correct: For any Fortran > > integer*kind we need to have _some_ C-representation as well, otherwise we > > disregard the type (tm), see e.g. the old and resolved ticket #1094. > > The representation chosen is set in opal/util/arch.c and is > > conclusive as far as I can tell... > Doesn't that mean that the comment is misleading? I interpret it as > saying that a Fortran "default integer" is always the same as a C > "int". I believe that you are saying that it really means that *any* > kind of Fortran integer must be the same as one of C's integral types, > or OpenMPI won't support it at all. Shouldn't the comment be clearer? Yes, the comment (actually in opal/util/arch.h -- not arch.c) while being correct IMHO, one could clarify it. Here we are talking about Fortran's INTEGER vs. C's int. Now, the comment should say: ** The Fortran INTEGER is dismissed here, since there is no ** platform known to me, were Fortran INTEGER does not match any ** of the C-integral types. With best regards, Rainer -- Rainer Keller, PhD Tel: +1 (865) 241-6293 Oak Ridge National Lab Fax: +1 (865) 241-4811 PO Box 2008 MS 6164 Email: kel...@ornl.gov Oak Ridge, TN 37831-2008AIM/Skype: rusraink
Re: [OMPI devel] opal / fortran / Flogical
On Jun 3, 2009, at 1:30 PM, Ralph Castain wrote: I'm not entirely sure what comment is being discussed. Jeff said: I see the following comment: ** The fortran integer is dismissed here, since there is no ** platform known to me, were fortran and C-integer do not match You can tell the intel compiler (and maybe others?) to compile fortran with double-sized integers and reals. Are we disregarding this? I.e., does this make this portion of the datatype heterogeneity detection incorrect? Rainer said: no, that's not an issue. The comment is correct: For any Fortran integer*kind we need to have _some_ C-representation as well, otherwise we disregard the type (tm), see e.g. the old and resolved ticket #1094. I said: Doesn't that mean that the comment is misleading? I interpret it as saying that a Fortran "default integer" is always the same as a C "int". I believe that you are saying that it really means that *any* kind of Fortran integer must be the same as one of C's integral types, or OpenMPI won't support it at all. Shouldn't the comment be clearer? I believe that you are talking about a different comment: * RHC: technically, use of the ompi_ prefix is * an abstraction violation. However, this is actually * an error in our configure scripts that transcends * all the data types and eventually should be fixed. * The guilty part is f77_check.m4. Fixing it right * now is beyond a reasonable scope - this comment is * placed here to explain the abstraction break and * indicate that it will eventually be fixed I don't know whether anyone is using either of these comments to justify anything. Iain
