code speed moving from fortran 77 compiler to f2003 compiler
in [Fortran]
|
From: dpb on 26 Jun 2010 18:46 Lynn McGuire wrote: >> 1992 paper at http://www.leshatton.org/Documents/JSX_0192.pdf . > .... > The author states that moving F77 code to F90 may be as difficult as moving > F77 code to C++. .... In addition to the note Richard M has made regarding the full quote, and other comments I just add one... The difficulties you've experienced moving from Watcom/OpenWatcom F77 to the IVF F95+ compiler aren't the language issues of F95 vis a vis F77 at all. IVF is one currently supported compiler that does (and will surely continue to) support the VMS FORTRAN STRUCTURE your code uses so even that extension isn't the issue. The issue is, as mentioned above, the reliance upon the peculiar feature of some compilers/OS'es to initialize all memory to zero or the Watcom /SAVE switch which has more widespread application than does, apparently, the same option(s) under IVF. I fail to see how moving to C/C++/whatever will resolve this issue so it seems to me that moving to another language is a red-herring in the mix. Eventually the deficient code is going to have to be fixed and it would seem more cost-effective to concentrate on that rather than move to another language and still have the problem to deal with. As another poster noted, it's quite simple to take advantage of features of F95 in a progressive step and would seem (at least to me) that much of the code in Fortran likely gets little modification as being numeric routines of long-standing. If so, it would seem it would follow that once the locations needing initialization are found and fixed it would again be essentially static but that as areas are identified for work they could at that time be placed in modules and those features that are useful incorporated as makes sense at the time. $0.02, etc., etc., etc., ... just an ol' wheat farmer so what do I know??? :) -dpb --
From: Lynn McGuire on 26 Jun 2010 19:45 > The issue is, as mentioned above, the reliance upon the peculiar feature of some compilers/OS'es to initialize all memory to zero > or the Watcom /SAVE switch which has more widespread application than does, apparently, the same option(s) under IVF. Hmmm. It wasnt so peculiar back in the 1970s when we were supporting ten different environments simultaenously. Univac 1108, CDC cyber 6600 and 7600, PrimeOS, IBM 370 (that was the worst !), etc... > I fail to see how moving to C/C++/whatever will resolve this issue so it seems to me that moving to another language is a > red-herring in the mix. Yes, it is. Our move to C++ is too soon to be planned at this time other than generalities. This group did a great job in helping me to figure out what our next step needs to be after the Hollerith conversion project is finished (that project is in year two !). Just like our "implicit none" project took a couple of years to implement. But I do see C++ as necessary for us to remain competitive in the future. Just as a matter of mention, the Apple iPhone/iPad only allow one to build apps with Objective C (preferred), C, C++, and Java. No Fortran compilers are supported that I know of. Not that we have a port planned there but I am certainly thinking about it as the mobile market seems to be exploding right now. We dont currently have a MacOS version but several customers are running our software there via Parallels, etc. > Eventually the deficient code is going to have to be fixed and it would seem more cost-effective to concentrate on that rather > than move to another language and still have the problem to deal with. Yes, the /save issue will need to be fixed before any compiler change. I was thinking that another Fortran compiler might do a better job about telling me which is initialized and which is not (an option that you mentioned to me that I had not considered). But, OW F77 should be workable in this respect also for now even though it only does static analysis. > just an ol' wheat farmer so what do I know??? :) -dpb <g> I've known quite few smart wheat farmers here in Texas over the years. I just got into crisis mode myself as I have been working on making our MS Excel interface interactive for our users. We've been using DDE code for dumping data into Excel for the past 18 years. I just found out that the DDE interface in Excel is not re-entrant so I get the "pleasure" of converting our interface code into OLE automation. And with a target ship date of July 15 - not gonna happen ! Thanks, Lynn
From: glen herrmannsfeldt on 26 Jun 2010 21:38 dpb <none(a)non.net> wrote: (snip) > The issue is, as mentioned above, the reliance upon the peculiar feature > of some compilers/OS'es to initialize all memory to zero or the Watcom > /SAVE switch which has more widespread application than does, > apparently, the same option(s) under IVF. > I fail to see how moving to C/C++/whatever will resolve this issue so it > seems to me that moving to another language is a red-herring in the mix. Most likely it won't, but do note that C (and C++) require static variables not otherwise initialized to be initialized to zero. That isn't the main reason to do the translation, but it is part of the standard. -- glen
From: e p chandler on 26 Jun 2010 22:24
"Lynn McGuire" <lmc(a)winsim.com> wrote in message news:5MGdnQ08UYC_DLvRnZ2dnUVZ_sqdnZ2d(a)posted.internetamerica... >> The issue is, as mentioned above, the reliance upon the peculiar feature >> of some compilers/OS'es to initialize all memory to zero or the Watcom >> /SAVE switch which has more widespread application than does, apparently, >> the same option(s) under IVF. > > Hmmm. It wasnt so peculiar back in the 1970s when we were supporting > ten different environments simultaenously. Univac 1108, CDC cyber 6600 > and 7600, PrimeOS, IBM 370 (that was the worst !), etc... > >> I fail to see how moving to C/C++/whatever will resolve this issue so it >> seems to me that moving to another language is a red-herring in the mix. > > Yes, it is. Our move to C++ is too soon to be planned at this time other > than generalities. This group did a great job in helping me to figure out > what our next step needs to be after the Hollerith conversion project is > finished (that project is in year two !). Just like our "implicit none" > project > took a couple of years to implement. > > But I do see C++ as necessary for us to remain competitive in the future. > Just as a matter of mention, the Apple iPhone/iPad only allow one to build > apps with Objective C (preferred), C, C++, and Java. No Fortran > compilers are supported that I know of. Not that we have a port planned > there but I am certainly thinking about it as the mobile market seems to > be > exploding right now. We dont currently have a MacOS version but several > customers are running our software there via Parallels, etc. > >> Eventually the deficient code is going to have to be fixed and it would >> seem more cost-effective to concentrate on that rather than move to >> another language and still have the problem to deal with. > > Yes, the /save issue will need to be fixed before any compiler change. > I was thinking that another Fortran compiler might do a better job about > telling me which is initialized and which is not (an option that you > mentioned > to me that I had not considered). But, OW F77 should be workable in > this respect also for now even though it only does static analysis. > >> just an ol' wheat farmer so what do I know??? :) -dpb > > <g> I've known quite few smart wheat farmers here in Texas over the years. > I just got into crisis mode myself as I have been working on making our > MS Excel interface interactive for our users. We've been using DDE code > for dumping data into Excel for the past 18 years. I just found out that > the > DDE interface in Excel is not re-entrant so I get the "pleasure" of > converting > our interface code into OLE automation. And with a target ship date of > July 15 - not gonna happen ! > > Thanks, > Lynn Sort of OT, but if you do use office automation, dumping data into Excel is much easier. Using VBA, sucking data into Excel is super easy. Pushing data in from another Office component or even classic VB or a dot Net language is not too bad - once you can deal with the object model. It's an improvement over DDE just as VBA is a vast improvement over Excel Macros in version 4.0 (XLM). Likewise, thinking about actually using the features of Fortran 90 looks overwhelming, but you may find that Fortran 95/2003 or whatever does actually simplify things considerably in the re-engineering process. I'm probably thinking of someone else's code, but just replacing home grown routines for dynamic memory allocation with standard features of the language could cut down the actual work considerably. I predict that Fortran 9x will be less prone to memory leaks and will give you better run-time diagnostics than C++. As for your /SAVE and zero initialization issues, I do think that existing compilers like g95 and gfortran and Silverfrost do give you enough diagnostics to find the actual variables involved. Elliot |
