code speed moving from fortran 77 compiler to f2003 compiler
in [Fortran]
|
From: Lynn McGuire on 26 Jun 2010 12:22 > Given that you appear to have problems porting Fortran > from Watcom to another compiler, I further suspect you'll > have problems with a fortran to c++ conversion. BTW, I should mention that our code worked fine on the Vax VMS, HP UX and Sun Workstations using their native fortran 77 and c compilers. Thanks, Lynn
From: Gary L. Scott on 26 Jun 2010 12:53 On 6/26/2010 10:32 AM, Lynn McGuire wrote: >> Elsewhere you discuss a custom memory allocator where >> you need to use EQUIVALENCE in a nonstandard way. I >> suspect you have many more extensions than you can >> easily enumerate here. > > I am thinking about moving our variant data type from our structure to > several equivalanced arrays. But that was so I could try the ftn95 > compiler. I just found out that the absoft compiler supports structure. While I know that Absoft has (or had, my version is older) some extensions that Intel doesn't, I found that it lacked too many that Intel had that I used widely. I've since decreased my use of extensions dramatically. Reading this thread almost makes me want to jump in and help fix this code set. snip > Thanks, > Lynn > >
From: Lynn McGuire on 26 Jun 2010 15:08 > 1992 paper at http://www.leshatton.org/Documents/JSX_0192.pdf . Awesome article, interesting conclusion: "As will be obvious from the above, there is no natural choice of language for the scientific user. The growing trend towards hybrid systems seems essentially healthy, although it places greater demands for multi-linguality on programmers. This should not be considered a bad thing. Furthermore, the importance of the safe(r) subset should not be under-estimated. Use of this concept can reduce maintenance costs and improve reliability significantly. If C is to be used, it should be written compatibly with C++. Fortran 90 features should be used with great care and there may be a better alternative in C++." The author states that moving F77 code to F90 may be as difficult as moving F77 code to C++. Also, a great list of rules for fortran of which we only violate half of them. But then again, some of our code dates back to 1965. Thanks, Lynn
From: dpb on 26 Jun 2010 16:00 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++. Hmmm....that seems a stretch given how little actual F77 was removed from F90/95 (and that afaik, no vendors removed F77 features from compilers when adding F90+). Granted, that there is at least one that started life as F90+ only, but it's a minority afaik. OTOH, there isn't a line of F90/95 that is C++ if only lacking the trailing ; . :) > Also, a great list of rules for fortran of which we only violate half of them. But > then again, some of our code dates back to 1965. Indeed, style has changed drastically and 1965 code predates F77 by enough that many of the common features that were later standardized either in the syntax of a particular compiler or in a near relative weren't even extensions at that point. I'm not going to get into the religious debate over languages other than C++ is not on my personal list of choices as noted earlier... :) --
From: Tobias Burnus on 26 Jun 2010 16:03
Lynn McGuire wrote: >> 1992 paper at http://www.leshatton.org/Documents/JSX_0192.pdf . > Awesome article, interesting conclusion: > "As will be obvious from the above, there is no natural choice of language for > the scientific user. That's definitely the case. I think it is at the end a question of personal taste, availability of people (of the relevant field) which are familiar with the language, whether certain language features (or their lack of) make it easier or harder to implement the concrete project, the language of other software being used/developed or the difficulty to link/combine those. And the available infrastructure (e.g. existence of sufficiently usable compilers, of free compilers, of already bought compilers). > Fortran 90 features should be used with great care and there may be a > better alternative in C++." The article has been written in 1992 where Fortran 90+ compilers were essentially unavailable; thus the first statement makes sense. Nowadays, I think one can safely use Fortran 95 and even many of the Fortran 2003 features. > The author states that moving F77 code to F90 may be as difficult as moving > F77 code to C++. I do not agree with this. A standard conform Fortran 77 is also a valid Fortran 90/95/2003/2008 program (ignoring some minor deleted items, which compilers continue to support). Thus, if the program was a valid Fortran 77 - it automatically is also a F90 program - that's definitely easier than to convert to C/C++. In general, it asks for less trouble in the short and medium term to simply continue using Fortran and modernizing the program stepwise (e.g. switching to dynamic allocation, if it makes sense). There exists also some converters which make a F77 program more F90 looking. Additionally, most compilers have a fairly good legacy support, thus the chances are high that it will work unmodified (or only lightly modified) even if the code is not fully standard conform. And - as Fortran is backward compatible - most vendors ship a single compiler - independent whether the user wants to use Fortran 77/90/95/2003/2008 features. For the long term, I don't know whether converting to C/C++ is better or not for your need. Since at your place, the number of C++ developers seems to be larger, it might. The problem with converting to C/C++: If the program is badly written (with regards to modern software design) a simple conversion yields a similarly badly written C/C++ program. (Plus the problems in semantics and readability due to the conversion.) If you completely redesign the program, you essentially start from scratch which will be a huge investment. Tobias |