code speed moving from fortran 77 compiler to f2003 compiler
in [Fortran]
|
From: Ron Shepard on 26 Jun 2010 16:17 In article <dqydnRQzSPW-tLvRnZ2dnUVZ_qCdnZ2d(a)posted.internetamerica>, "Lynn McGuire" <lmc(a)winsim.com> wrote: > > 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. Yes, but if your code were standard f77, it would be trivial to "port" your code to f90 and f95 compilers. In most cases, the effort for that "port" would have simply been to recompile the existing code with the modern compiler. If you further group your subroutines into modules, then you start to benefit from some of the modern features of the language with essentially no programming effort. You should consider investing the effort to get rid of these nonstandard, and as you are finding nonportable, extensions. It is much easier to do when you still have compilers that do support those extensions. If you wait until there are no compilers that work with your code, when you can no longer examine intermediate results during the conversion process, it will be much more difficult. And as a practical matter, it is always easier to port standard f77 code to newer versions of fortran than to some other language entirely; that has been one of the design considerations of the modern fortran standards. As I said previously, the main benefit of having compilers support the nonstandard features of other compilers is to assist you in eliminating those features. You have been using those extensions to delay that task, not to facilitate it. Developing code in modern fortran is much better than with the older versions (including f77). With your current path, you are not benefiting from the newer language features. $.02 -Ron Shepard
From: Ron Shepard on 26 Jun 2010 16:46 In article <KLqdnZTBFcS-zbvRnZ2dnUVZ_gWdnZ2d(a)posted.internetamerica>, "Lynn McGuire" <lmc(a)winsim.com> wrote: > > 1992 paper at http://www.leshatton.org/Documents/JSX_0192.pdf . > > Awesome article, From almost 20 years ago. Since then there has been much progress in fortran. Also, the enthusiasm for c++ in the late 80's and early 90's has waned. That was also at the end of the decade of the 80's when the standards committee drug its feet and delayed the approval of any new features in fortran, even the trivial ones which had been accepted as near universal extensions (such as the mil-std bit operators, do-enddo, implicit none, and so on). In 1992, few people had practical experience with the new f90 features, and some of the important features (such as allocatable arrays) still had several shortcomings (could not be dummy arguments, could not be used in derived types, etc.). > 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. Newer versions of fortran support interoperability with C in a direct way. > 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++. In hindsight, this last part of the sentence should be essentially reversed. Some effort programming within C++ needs to be directed toward compatibility with C. The general feeling in the late 80's was that C++ would replace C entirely. That did not happen, and it is clear now that it is not going to happen. > Fortran 90 features should be used with great care and there may be a > better alternative in C++." Do you think this might have changed in the past 20 years? Now, the situation might even be reversed, where some tasks are easier, clearer, and more efficient, in fortran than in C++. > > The author states that moving F77 code to F90 may be as difficult as moving > F77 code to C++. But we know that is simply not true. Standard f77 is trivial to "port" to newer versions of fortran. > 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. Yes, we've all been there. Even now, if you look at a lot of netlib code, for example, you see programming style dating back to the 60's. Usually it is trivial to update. That is one of the features of modern fortran. $.02 -Ron Shepard
From: Richard Maine on 26 Jun 2010 17:10 Lynn McGuire <lmc(a)winsim.com> 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++. I was curious what in the world would justify such a claim, so I read the paper. I was ecpecting to find that it was talking about "f77" code with loads of extensions or some such thing. Instead, No, the paper doesn't actually say that. The closest thing I could find sounds perhaps slightly simillar, but has a major extra bit that you omitted. That extra bit is the entire reason for the claim, not just a detail. In particular, the author says "The step from Fortran 77 to Fortran 90 is arguably therefore as large as the step from Fortran 77 to C if the new features are to be used." Note the "if the new features are to be used" bit. The step from f77 to f90 is zero if you just want to take existing standard f77 code, which is also already standard f90 code. Reading in a bit more detail, it appears that this extra bit is based on the author's belief that "the new features largely involve throwing away most of the Fortran 77 features". Further reading reveals that the author basically appears to have no idea what f90 is. I see no evidence in the paper that he actually studied the language with any care. All of his descriptions seem very broad brush, much like the above quote, without even a hint of what specifics he might be alluding to. He obviously would never have used an f90 compiler (insomuch as he alludes to the f90 standard not haveing yet been completed when he wrote the paper). -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: glen herrmannsfeldt on 26 Jun 2010 17:14 Tobias Burnus <burnus(a)net-b.de> wrote: (snip, someone wrote) >> 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++. It depends on what you mean by Fortran 90. Yes it is valid Fortran 90 code but, for example, if it uses the Fortran 66 style allocation using large array in COMMON and EQUIVALENCE then one might say that conversion to Fortran 90 includes conversion to real ALLOCATABLE arrays. For computation bound programs that don't do much I/O, the conversion to C or C++ might not be so bad. I/O is fairly straightforward, but tedious to convert. > 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. -- glen
From: Richard Maine on 26 Jun 2010 17:48
glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: > Tobias Burnus <burnus(a)net-b.de> wrote: > (snip, someone wrote) > > >> 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 > It depends on what you mean by Fortran 90. Not if you mean anything sensible. It is standard f90, which is what one should mean by f90. Other changes, such as the ones you mentioned do not constitute "moving f77 code to f90". Yes, one can misuse terminology all you want. You can refer to such changes as "mowing the lawn" (which I ought to go do instead of posting here) if you want to use that as your terminology, but that doesn't make it correct. It just miscommunicates. You are talking about making style changes among the choices available within f90. That might or might not be a reasonable thing to do in any particular context, but if you use terminology that describes that as "moving f77 code to f90" you are likely to confuse yourself. Worse, even if you know what you are talking about, other people will *NOT*. I absolutely guarantee it. Heck, they probably won't even know what you mean if you add the appropriate qualifiers. Qualifiers like that tend to get dropped along the way, even when they are central to the point. That's what happened in Lynn's quote of the paper in question, for example. The paper basically said that they thought the new features of f90 required throwing out most of f77 and therefore in order to make use of those new features of f90, you had to redo most of the f77 code. The bit about needing to throw out most of f77 is a very questionable judgement (and appears to be based on the author's poor understanding of f90 as far as I can tell). But even if it were true, it is a critical qualifier to the author's claim. Without it, the meaning of the claim is completely different. Nonetheless, it got dropped in quotation, with consequent change of meaning. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain |