Re: [OMPI devel] opal / fortran / Flogical
It looks like Rainer reverted the stuff in r21342. Rainer -- is it safe for Ralph to move the arch.c stuff back up into OMPI, or will that conflict with your stuff? On Jun 1, 2009, at 11:12 PM, Ralph Castain wrote: Just to throw some $0.002 into this overall discussion... Not knowing this was going to be happening, I was actually about to propose moving the opal/util/arch.c code back to the ompi layer. The original move had caused quite a bit of angst due to the fortran stuff. Originally, I had needed to make the move because the design for modex-less operations needed to know the architecture prior to launching the app. However, as things evolved, it turns out that this isn't necessary at all - in fact, the launch system doesn't actually take advantage of the ORTE layer knowing the arch. So from the point of view of the current system, there is no value in having the opal/util/arch.c code - it can be restored to the original datatype area. I realize that Rainer is pursuing a different objective, and that's fine. My point here is that the original motivation for breaking the abstraction barrier no longer exists, so whatever we do here is free to reflect that change in requirement. I would personally like to see OPAL retain its original objective and avoid having Fortran knowledge down there. Ralph On Jun 1, 2009, at 3:02 PM, Rainer Keller wrote: > Thanks, Jeff! > > > On Monday 01 June 2009 04:53:19 pm Jeff Squyres wrote: >> Per the MPI_Flogical issue -- I think Rainer just exposed some old >> ugliness. We've apparently had MPI_Flogical defined in >> ompi_config.h.in for a long, long time -- we used it in some places >> and used ompi_fortran_logical_t in other places. >> >> Even though I *may* be responsible for this particular bit of >> ugliness >> way back in the past :-), I think the #define for MPI_Flogical should >> be removed if for no other reason than 6-12 months from now when >> someone else re-discovers it, they'll have to go lookup to see if >> it's >> a real MPI type -- which it's not. Even though it's longer, we >> should >> use ompi_fortran_logical_t everywhere. >> >> My $0.02. >> >> On Jun 1, 2009, at 1:23 PM, Brian W. Barrett wrote: >>> Well, this may just be another sign that the push of the DDT to OPAL >>> is a >>> bad idea. That's been my opinion from the start, so I'm biased. >>> But OPAL >>> was intended to be single process systems portability, not MPI crud. >>> >>> Brian >>> >>> On Mon, 1 Jun 2009, Rainer Keller wrote: Hmm, OK, I see. However, I do see potentially a problem with work getting ddt on >>> >>> the OPAL >>> layer when we do have a fortran compiler with different alignment >>> >>> requirements >>> for the same-sized basic types... As far as I understand the OPAL layer to abstract away from >>> >>> underlying system >>> portability, libc-quirks, and compiler information. But I am perfectly fine with reverting this! Let's discuss, maybe phone? Thanks, Rainer On Monday 01 June 2009 10:38:51 am Jeff Squyres wrote: > Hmm. I'm not sure that I like this commit. > > George, Brian, and I specifically kept Fortran out of (the non- > generated code in) opal because the MPI layer is the *only* layer >>> >>> that >>> > uses Fortran. There was one or two minor abstraction breaks (you > cited opal/util/arch.c), but now we have Fortran all throughout >>> >>> Opal. >>> > Hmmm... :-\ > > Is MPI_Flogical a real type? I don't see it defined in the > MPI-2.2 > latex sources, but I could be missing it. I *thought* we used > ompi_fortran_logical_t internally because there was no officially > sanctioned MPI_ type for it...? > > -- > > 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 > > > ___ > 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 -- Jeff Squyres Cisco Systems
Re: [OMPI devel] opal / fortran / Flogical
On Tuesday 02 June 2009 07:48:02 am Jeff Squyres wrote: > It looks like Rainer reverted the stuff in r21342. Yes. > Rainer -- is it safe for Ralph to move the arch.c stuff back up into > OMPI, or will that conflict with your stuff? Yes, we use it. Please leave it at the OPAL layer. We need a way to describe and store the remote architecture at the OPAL layer. Thanks, Rainer > On Jun 1, 2009, at 11:12 PM, Ralph Castain wrote: > > Just to throw some $0.002 into this overall discussion... > > > > Not knowing this was going to be happening, I was actually about to > > propose moving the opal/util/arch.c code back to the ompi layer. The > > original move had caused quite a bit of angst due to the fortran > > stuff. Originally, I had needed to make the move because the design > > for modex-less operations needed to know the architecture prior to > > launching the app. However, as things evolved, it turns out that this > > isn't necessary at all - in fact, the launch system doesn't actually > > take advantage of the ORTE layer knowing the arch. > > > > So from the point of view of the current system, there is no value in > > having the opal/util/arch.c code - it can be restored to the original > > datatype area. > > > > I realize that Rainer is pursuing a different objective, and that's > > fine. My point here is that the original motivation for breaking the > > abstraction barrier no longer exists, so whatever we do here is free > > to reflect that change in requirement. > > > > I would personally like to see OPAL retain its original objective and > > avoid having Fortran knowledge down there. > > Ralph > > > > On Jun 1, 2009, at 3:02 PM, Rainer Keller wrote: > > > Thanks, Jeff! > > > > > > On Monday 01 June 2009 04:53:19 pm Jeff Squyres wrote: > > >> Per the MPI_Flogical issue -- I think Rainer just exposed some old > > >> ugliness. We've apparently had MPI_Flogical defined in > > >> ompi_config.h.in for a long, long time -- we used it in some places > > >> and used ompi_fortran_logical_t in other places. > > >> > > >> Even though I *may* be responsible for this particular bit of > > >> ugliness > > >> way back in the past :-), I think the #define for MPI_Flogical > > > > should > > > > >> be removed if for no other reason than 6-12 months from now when > > >> someone else re-discovers it, they'll have to go lookup to see if > > >> it's > > >> a real MPI type -- which it's not. Even though it's longer, we > > >> should > > >> use ompi_fortran_logical_t everywhere. > > >> > > >> My $0.02. > > >>Just to throw some $0.002 into this overall discussion... Not knowing this was going to be happening, I was actually about to propose moving the opal/util/arch.c code back to the ompi layer. The original move had caused quite a bit of angst due to the fortran stuff. Originally, I had needed to make the move because the design for modex-less operations needed to know the architecture prior to launching the app. However, as things evolved, it turns out that this isn't necessary at all - in fact, the launch system doesn't actually take advantage of the ORTE layer knowing the arch. So from the point of view of the current system, there is no value in having the opal/util/arch.c code - it can be restored to the original datatype area. I realize that Rainer is pursuing a different objective, and that's fine. My point here is that the original motivation for breaking the abstraction barrier no longer exists, so whatever we do here is free to reflect that change in requirement. I would personally like to see OPAL retain its original objective and avoid having Fortran knowledge down there. Ralph > > >> On Jun 1, 2009, at 1:23 PM, Brian W. Barrett wrote: > > >>> Well, this may just be another sign that the push of the DDT to > > > > OPAL > > > > >>> is a > > >>> bad idea. That's been my opinion from the start, so I'm biased. > > >>> But OPAL > > >>> was intended to be single process systems portability, not MPI > > > > crud. > > > > >>> Brian > > >>> > > >>> On Mon, 1 Jun 2009, Rainer Keller wrote: > > Hmm, OK, I see. > > However, I do see potentially a problem with work getting ddt on > > >>> > > >>> the OPAL > > >>> > > layer when we do have a fortran compiler with different alignment > > >>> > > >>> requirements > > >>> > > for the same-sized basic types... > > > > As far as I understand the OPAL layer to abstract away from > > >>> > > >>> underlying system > > >>> > > portability, libc-quirks, and compiler information. > > > > But I am perfectly fine with reverting this! > > Let's discuss, maybe phone? > > > > Thanks, > > Rainer > > > > On Monday 01 June 2009 10:38:51 am Jeff Squyres wrote: > > > Hmm. I'm not sure that I like this commit. > > > > > > George, Brian, and I specifically kept Fortran out of (the non- > > > generated code in) opal because the MPI layer is the *only* > > > > layer > > > >
Re: [OMPI devel] opal / fortran / Flogical
On Jun 2, 2009, at 9:08 AM, Rainer Keller wrote: > Rainer -- is it safe for Ralph to move the arch.c stuff back up into > OMPI, or will that conflict with your stuff? Yes, we use it. Please leave it at the OPAL layer. We need a way to describe and store the remote architecture at the OPAL layer. Question about the fortran stuff in opal/util/arch.c... 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? -- Jeff Squyres Cisco Systems
Re: [OMPI devel] opal / fortran / Flogical
Hi Jeff, 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... We do however still have a buglet with FCFLAGS='-i8 -r16', but that's with our internal storage of [cdw]_f_to_c_index, so it's a different issue (ticket #1812). CU, Rainer PS: I especially like the comment in opal/util/arch.c ;-): /* sizeof fortran logical * * 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 */ On Tuesday 02 June 2009 09:57:46 am Jeff Squyres wrote: > On Jun 2, 2009, at 9:08 AM, Rainer Keller wrote: > > > Rainer -- is it safe for Ralph to move the arch.c stuff back up into > > > OMPI, or will that conflict with your stuff? > > > > Yes, we use it. > > Please leave it at the OPAL layer. We need a way to describe and > > store the > > remote architecture at the OPAL layer. > > Question about the fortran stuff in opal/util/arch.c... > > 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 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
The datatype engine (where the arch code was originally from), needs a way to describe the architectures in order to know how to convert the data. Therefore I will advocate the return of the opal/util/arch.h back in the datatype. george. On Jun 2, 2009, at 07:24 , Rainer Keller wrote: Hi Jeff, 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... We do however still have a buglet with FCFLAGS='-i8 -r16', but that's with our internal storage of [cdw]_f_to_c_index, so it's a different issue (ticket #1812). CU, Rainer PS: I especially like the comment in opal/util/arch.c ;-): /* sizeof fortran logical * * 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 */ On Tuesday 02 June 2009 09:57:46 am Jeff Squyres wrote: On Jun 2, 2009, at 9:08 AM, Rainer Keller wrote: Rainer -- is it safe for Ralph to move the arch.c stuff back up into OMPI, or will that conflict with your stuff? Yes, we use it. Please leave it at the OPAL layer. We need a way to describe and store the remote architecture at the OPAL layer. Question about the fortran stuff in opal/util/arch.c... 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 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 ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] opal / fortran / Flogical
Please feel free to do so, George, as far as I'm concerned. I will modify the ORTE code in anticipation of it by removing the arch-related calls. Should have that for you later today or tomorrow. If it doesn't move, no harm done - like I said, I really don't need it any more, but was suggesting the move only to finally clear that abstraction break we all hated when I originally did it (apologies in hindsight). :-) On Tue, Jun 2, 2009 at 9:45 AM, George Bosilca wrote: > The datatype engine (where the arch code was originally from), needs a way > to describe the architectures in order to know how to convert the data. > Therefore I will advocate the return of the opal/util/arch.h back in the > datatype. > > george. > > > On Jun 2, 2009, at 07:24 , Rainer Keller wrote: > > Hi Jeff, >> 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... >> >> We do however still have a buglet with FCFLAGS='-i8 -r16', but that's with >> our >> internal storage of [cdw]_f_to_c_index, so it's a different issue (ticket >> #1812). >> >> CU, >> Rainer >> >> PS: I especially like the comment in opal/util/arch.c ;-): >> /* sizeof fortran logical >>* >>* 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 >>*/ >> >> >> >> On Tuesday 02 June 2009 09:57:46 am Jeff Squyres wrote: >> >>> On Jun 2, 2009, at 9:08 AM, Rainer Keller wrote: >>> Rainer -- is it safe for Ralph to move the arch.c stuff back up into > OMPI, or will that conflict with your stuff? > Yes, we use it. Please leave it at the OPAL layer. We need a way to describe and store the remote architecture at the OPAL layer. >>> >>> Question about the fortran stuff in opal/util/arch.c... >>> >>> 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 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 >> >> >> ___ >> 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
Quick question, George - are you planning on leaving that arch computation in OPAL, but just moving it to the new opal/datatype area? If so, then I won't worry about removing the arch-related calls from ORTE right away. If you are planning on moving it back to OMPI, then I'll put my efforts at a higher priority. Thanks Ralph On Tue, Jun 2, 2009 at 10:30 AM, Ralph Castain wrote: > Please feel free to do so, George, as far as I'm concerned. I will modify > the ORTE code in anticipation of it by removing the arch-related calls. > Should have that for you later today or tomorrow. > > If it doesn't move, no harm done - like I said, I really don't need it any > more, but was suggesting the move only to finally clear that abstraction > break we all hated when I originally did it (apologies in hindsight). :-) > > > > On Tue, Jun 2, 2009 at 9:45 AM, George Bosilca wrote: > >> The datatype engine (where the arch code was originally from), needs a way >> to describe the architectures in order to know how to convert the data. >> Therefore I will advocate the return of the opal/util/arch.h back in the >> datatype. >> >> george. >> >> >> On Jun 2, 2009, at 07:24 , Rainer Keller wrote: >> >> Hi Jeff, >>> 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... >>> >>> We do however still have a buglet with FCFLAGS='-i8 -r16', but that's >>> with our >>> internal storage of [cdw]_f_to_c_index, so it's a different issue (ticket >>> #1812). >>> >>> CU, >>> Rainer >>> >>> PS: I especially like the comment in opal/util/arch.c ;-): >>> /* sizeof fortran logical >>>* >>>* 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 >>>*/ >>> >>> >>> >>> On Tuesday 02 June 2009 09:57:46 am Jeff Squyres wrote: >>> On Jun 2, 2009, at 9:08 AM, Rainer Keller wrote: > Rainer -- is it safe for Ralph to move the arch.c stuff back up into >> OMPI, or will that conflict with your stuff? >> > > Yes, we use it. > Please leave it at the OPAL layer. We need a way to describe and > store the > remote architecture at the OPAL layer. > Question about the fortran stuff in opal/util/arch.c... 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 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 >>> >>> >>> ___ >>> 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
Ralph, The plan was to leave the arch detection down in OPAL, but instead of util to move it back in the datatype. Therefore, all references to the arch in ORTE are safe. Thanks, george. On Jun 2, 2009, at 15:31 , Ralph Castain wrote: Quick question, George - are you planning on leaving that arch computation in OPAL, but just moving it to the new opal/datatype area? If so, then I won't worry about removing the arch-related calls from ORTE right away. If you are planning on moving it back to OMPI, then I'll put my efforts at a higher priority. Thanks Ralph On Tue, Jun 2, 2009 at 10:30 AM, Ralph Castain wrote: Please feel free to do so, George, as far as I'm concerned. I will modify the ORTE code in anticipation of it by removing the arch- related calls. Should have that for you later today or tomorrow. If it doesn't move, no harm done - like I said, I really don't need it any more, but was suggesting the move only to finally clear that abstraction break we all hated when I originally did it (apologies in hindsight). :-) On Tue, Jun 2, 2009 at 9:45 AM, George Bosilca wrote: The datatype engine (where the arch code was originally from), needs a way to describe the architectures in order to know how to convert the data. Therefore I will advocate the return of the opal/util/ arch.h back in the datatype. george. On Jun 2, 2009, at 07:24 , Rainer Keller wrote: Hi Jeff, 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... We do however still have a buglet with FCFLAGS='-i8 -r16', but that's with our internal storage of [cdw]_f_to_c_index, so it's a different issue (ticket #1812). CU, Rainer PS: I especially like the comment in opal/util/arch.c ;-): /* sizeof fortran logical * * 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 */ On Tuesday 02 June 2009 09:57:46 am Jeff Squyres wrote: On Jun 2, 2009, at 9:08 AM, Rainer Keller wrote: Rainer -- is it safe for Ralph to move the arch.c stuff back up into OMPI, or will that conflict with your stuff? Yes, we use it. Please leave it at the OPAL layer. We need a way to describe and store the remote architecture at the OPAL layer. Question about the fortran stuff in opal/util/arch.c... 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 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 ___ 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
