Are FORTRAN 77 programs faster than Fortran 90 ones?

Question

Today I was reading code from some very popular numerical libraries written in FORTRAN 77 such as QUADPACK (last updated in 1987), and I was wondering if there is any reason not to rewrite those libraries in Fortran 90 apart from the big amount of work it would pose, given the great improvements Fortran 90 brought to the language, including free-form source, better control structures so GO TO could be forgotten, vectorization, interfaces and so on.

Is it because FORTRAN 77 compilers produce more optimized code, maybe it is better for parallel execution? Notice that I'm not even talking about Fortran 2003 for example, which is only 8 years old: I'm talking about Fortran 90, so I assume it has enough widespread and the compilers are ready. I don't have contact with the industry, anyway.

Edit: janneb is right: LAPACK is actually written in Fortran 90.

Iolenta

I think it's the "big amount of work it would pose" for something that is already a proven contender. Many "higher level" language-constructs are nice, but short of a paradigm shift, they seldom benefit performance. That is, "code with new syntax" doesn't imply "better compiler optimizations", and even F77 (as much as it pains me to admit it) is a "high level" language. – Unruly

Efficient Fortran codes should stick to F77 features at their core for high performance, most of newer features would usually result in less efficient executables. F90 and newer would be mainly useful for maintainability and extensibility of the code. – Mccully

@Mccully - I'm guessing you have some strong evidence to support such statements? – Rather

@pst, I understand that actually these libraries do work, but I didn't mean those syntax changes should be made to gain performance: I wasked if those changes weren't made because they led to worse performance. – Iolenta

Well, yes, there is evidence for this strategy. I do not claim, that all newer features have a negative impact on performance, or that you should not use them at all. Just in the very kernel, the F77 style is generally a good guide to produce efficient code. (Staying away from pointer and target attributes, do not use fine-grained derived datatypes, there was even a time when array syntax statements where slower than explicit do-loops, though compilers seem to have much improved). I am actually using F2003 features heavily, my point is just in the very kernel, there is propably little benefit. – Mccully

Answer 1

Well, like "pst" mentioned, the "big amount of work it would pose" is a pretty major reason.

Some further minor points:

• LAPACK IS Fortran 90, these days, in the sense that the latest version no longer compiles with a F77 compiler. That being said, it's far from a rewrite, only a few things that were changed.

• Most of the F90 features you mention make it easier and faster to write robust programs, it doesn't necessary make the resulting programs any faster.

• It wasn't that long ago that free F90 compilers were not available (plenty of people used g77!), so for a widely used library like LAPACK not using F90 features was likely a conscious decision.

• A F77 compiler does not, generally, produce faster code than a F90 compiler. If not for any other reason, then because it's likely obsolete and cannot optimize for the latest CPU's. A modern Fortran compiler might create faster code from F77 than from an equivalent F90 program which makes extensive use of things like pointers etc., but that is highly dependent on the program in question (e.g. using pointers and fancier data structures may allow usage of better algorithms, allowing the F90 program to produce results faster even though it might execute at a lower average utilization of the CPU arithmetic units).

• Vectorization, if by this you mean the F90+ array syntax, is mostly a programmer convenience issue rather than allowing faster code. A competent compiler will vectorize the equivalent DO loop just as well.

Callboy

A F90 compiler might generate faster code than the F77 compiler, because it doesn't have to guess as much as to where array operations are, or how the array elements alias; the programmer tells it directly in a lot more cases. – Raft

Hum, I didn't know there had been a lack of free F90 compilers for so long. Good point and good answer, thanks! – Iolenta

@IraBaxter: Yes, in principle. In practice, optimizing the scalarization of array expressions has its own set of non-trivial problems, chief-most being that the compiler wants to avoid using a temporary array (which is the semantic model of how array expressions work in F90). Once that is done, the vectorizer pass can be let loose on the scalarized loops. – Callboy

Answer 2

There is no reason to put in a ton of work to (maybe) improve something that works well. It should be noted that even though Fortran 90 introduced many new features, it did not change the language. Remember that Fortran 90 Standard is backwards compatible with FORTRAN 77. A modern compiler will be able to optimize a FORTRAN 77 code just as well. There are features introduced in Fortan 90 (e.g. pointers) that would hinder the efficiency and that should be avoided if one cares about execution time, e.g. in HPC.

So it would not really make a difference. For a modern compiler, well written FORTAN 77 is just as optimizable - it is like a cake without icing. Here, in case of Fortran 90 and later, icing looks better than it tastes - it is a convenience for the programmer, but does not necessarily improve the program efficiency.

Conduit

IIRC, actually Fortran Standards are not backwards compatible. Fortran 90 deprecated some features from FORTRAN 77, and Fortran 95 deleted some deprecated features in the previous standard, for example. – Iolenta

@Juanlu001 You are right. I went ahead of myself. Fortran 90 standard is backwards compatible with Fortran 77 (and also has most added features to the language). – Conduit

IRO-bot, @Juanlu001 - Went ahead, but not by much ... for a feature to be deleted from a fortran standard, it has to pass through several phases, and only a few until now were deleted so far (very non-portable, and rarely used ones). However, even with that in mind, most vendors still support them, regardless of standard. So, yes, even though the standard has expelled them, one can say that fortran compilers are VERY backward compatible. In F90 there were no deleted features, and F95 introduced a few, although I've yet to see a compiler which doesn't support them. – Rather

So practically this is really a non issue. F2k added nothing to the obsolete list, if memory serves. – Rather

Answer 3

There is one major reason why Fortran 77 programs might be faster :

Allocated arrays (Fortran 90) are much slower than declared-at-compile-time arrays. Both are not put at the same place in memory. That's the stack vs heap memory management in Fortran.

See here for instance

This being said, Fortran 90+ have fast 'all in block' array operations. I'm a big fan of gcc-fortran (gfortran) and without any compilation option, for an array a of size N

a = a + 1

is 4 times faster than

do i = 1 , N
  a(i) = a(i) + 1
end do

This bench is for me, on my machine, on gfortran without optimization option, and without any claming that this is professional benchmarking.

The allocation "problem" (which is not a problem but a feature) is not architecture, compiler or anything related but to the Fortran Standard.

Childbirth

Well, sure, dynamically allocated memory make programs harder to optimize than statically allocated because they are less predictable by the compiler. Whether they are put on stack or heap is not defined by the Fortran standard, and is most likely system, compiler, and a d20 roll dependent. But this is not a real argument, because, where allocatable arrays are not necessary, we certainly don't want to use them. – Conduit

But where allocatable arrays are necessary, we'll have to use them, won't we? :) Great answer Maximilien, thank you for pointing this out! Not a CS student, so this things are not trivial for me. And also the vectorization thing is so useful. – Iolenta

But where allocatable arrays are necessary, you must use Fortran 90 anyway. So it is not a relevant argument for comparing F77 vs. F90 efficiency. Apples and oranges. – Conduit

@IRO-bot The original question was about the interest there might be in rewritting F77 libraries in F90+. I guess we do not discuss here about style only (free vs fixed form). If you just delete the useless spaces and transform 'C' in '!', then ... pointless 77to90. If your goal is to really use F90+ and its features, then you may consider my answer. By the way, you may not transform apples to oranges. The comparison is more between apples and bigger apples. – Childbirth

@MaximilienLevesque I see what you are saying. I assume the scope of the question is specific about rewriting F77 to F90 without changing the application and semantics. So, features like array operations and new flow control structures are relevant for comparison, but dynamic allocation not really, in my opinion. Note that I agree with your answer (+1), but it's still apples and oranges for me :). – Conduit

#pragma openmp,mpi,mpich, etc do i = 1 , N a(i) = a(i) + 1 end do without having to memory manage, f77 will still stomp on more f90 code for brute number crunching, which is what f77 is built for. f77 is not matlab or python. it's chew up this massive matrix, give me some eigenvectors, SVD, or decompose this and i want the results now. – Overslaugh

Answer 4

Whether F77 program will be slower or faster then the equivalent F90 program, rewritten with newer syntax is discussable, but let's disregard that for now.

What should however be taken into account, is that nobody really cares about speed only. People only care about speed of execution in the cases where it is relevant, and where it is bussiness profitable (I'm sure there is a better term for this, but nothing comes to mind right now ... cost effective maybe).

Since those two (rather popular libraries) are still in F77, it is obvious that it is the general opinion that the costs of rewriting them outweights the benefits gained, benefits in term of speed of execution, and benefits in terms of cost effectiveness of that whole process.

Rather

Yep, speed is the key factor here, because these libraries are used for number crunching mainly. – Iolenta

@Juanlu001 - How people love that term :) It still doesn't matter sometimes; for example, if a program runs 24 hours a week, then it doesn't run for two weeks ... nobody's gonna care if it runs 25 hours a week ... – Rather

@Idigas It is so much more tight with time in operational weather forecasting for example, where every little speed-up here and there matters. – Conduit

Mmmmm, number crunching sounds like engineering breakfast – Iolenta