40
$\begingroup$

Fortran has a special place in numerical programming. You can certainly make good and fast software in other languages, but Fortran keeps performing very well despite its age. Moreover, it's easier to make fast programs in Fortran. I've made fast programs in C++, but you have to be more careful about things like pointer aliasing. So, there has to be a reason for this, and a very technical one. Is it because the compiler can optimize more? I would really like to know technical details, so if I use another language I can take these things into consideration.

For example, I know -or so I think- that one thing is that the standard specifies that pointers are contiguous in memory always which means faster memory access. I believe you can do this in C++ by giving a flag to the compiler. In this way it helps to know what Fortran does good, so that if using another language we can imitate this.

|cite|improve this question
$\endgroup$
  • 7
    $\begingroup$ I would say this might be a better question for stackoverflow, even though I thing it's a good question. A quick search (stackoverflow.com/search?q=fortran+fast) leads me to this question that might help you: stackoverflow.com/questions/146159/is-fortran-faster-than-c $\endgroup$ – Yann Dec 3 '11 at 17:13
  • 3
    $\begingroup$ You need to specify which type of fortran you're using. There is a substantial difference between 77 and 90+. I'm assuming at least 90 if we're talking about pointers... $\endgroup$ – qubyte Dec 3 '11 at 17:26
  • $\begingroup$ I always read about Fortran being faster than C. Well maybe, but is it faster like 2% or rather faster like 50%? $\endgroup$ – shuhalo Dec 7 '11 at 19:23
  • 4
    $\begingroup$ It's an urban myth. Unless the compiler can make use of special instructions, you can hand-optimize almost any program, regardless of compiler, to generate about the same machine language. $\endgroup$ – Mike Dunlavey Jun 29 '12 at 16:13
50
$\begingroup$

Language designers face many choices. Ken Kennedy emphasized two: (1) better abstractions and (2) higher- or lower-level (less or more machine-like) code. While functional languages like Haskell and Scheme focus on the former, traditional scientific-computing languages like Fortran and C/C++ focused on the latter. Saying that one language is faster than another is usually quite misleading: each language has a problem domain for which it excels. Fortran fares better in the domain of array-based numerical codes than other languages for two basic reasons: its array model and its explicitness.

Array Model

Fortran programmers largely do array manipulations. For that, Fortran facilitates several compiler optimizations that are not available in other languages. The best example is vectorization: knowing the data layout enables the compiler to invoke assembly-level intrinsics over the array.

Language Explicitness

While it seems that a simpler language should compile "better" than a more complex one, that really isn't the case. When one writes in an assembly language, there isn't much a compiler can do: all it sees are very-fine-grained instructions. Fortran requires explicitness (thus, more work by the programmer) only in cases that yield real rewards for array-based computing. Fortran uses simple data types, basic control flow, and limited namespaces; by contrast, it does not tell the computer how to load registers (which might be necessary for real-time). Where Fortran is explicit, it enables things like complete type inference, which helps novices to get started. It also avoids one thing that often makes C slow: opaque pointers.

Fortran Can Be Slow

Fortran is not fast for every task: that's why not many people use it for building GUIs or even for highly unstructured scientific computing. Once you leave the world of arrays for graphs, decision trees, and other realms, this speed advantage quickly goes away. See the computer language benchmarks for some examples and numbers.

|cite|improve this answer
$\endgroup$
  • 6
    $\begingroup$ The GUI/IO problems can be easily solved by wrapping Fortran crunching in a "more general purpose" language. I frequently use R for this purpose. $\endgroup$ – mbq Dec 4 '11 at 8:56
  • 2
    $\begingroup$ shootout.alioth.debian.org is no longer available! And the new version has much less information :( $\endgroup$ – astrojuanlu Dec 14 '15 at 10:09
23
$\begingroup$

The design of Fortran allows the compiler to perform stronger optimizations in some cases, optimizations that are not generally available to C.

One famous example is the handling of aliasing. In Fortran, you can access a specific memory area only though the specific symbol associated with that memory area. This knowledge allows the compiler to employ smart tricks when it's time to cache: it knows if a value has potentially changed or not. Until F90, this was verified easily. When Fortran 90 introduced pointers, the assumption was no longer true: you could access the same memory area through two (or more) symbols. This is the reason why you have to specify target to arrays you want to address via pointers.

Another interesting fact is that many constructs allow the compiler to perform parallelization without user intervention. Such luxury is possible due to the relative "platform agnosticism" of Fortran as a language.

There are many other subtle tricks like this. In addition, remember that nobody uses Fortran today, except for numerical calculations, meaning that the core feature and selling point of Fortran compilers is the resulting code speed. As a result, vendors focused on this.

Nevertheless, you can produce performant code also with other languages. It may, however, require special care or human intervention. The general point, however, is that performance is not a problem until there's a problem, and man time is way more expensive than computer time. So coding practices should focus on saving human time, rather than computer time.

|cite|improve this answer
$\endgroup$
  • 2
    $\begingroup$ When your computers get into the > $100 million range, people time (grad students) stop looking quite so expensive in comparison. $\endgroup$ – Phil Miller Dec 6 '11 at 22:21
  • 5
    $\begingroup$ @Novelocrat: The amount of code that runs on \$100 millions computer has been written by uncountable man hours which go well beyond the \$100 million mark, even at grad student price. Remember the costs of a person is twice its income. The rest goes into taxes and correlated. Also, a computer does not experience burn off. A person does, and will change job. $\endgroup$ – Stefano Borini Dec 7 '11 at 8:58
  • 1
    $\begingroup$ @StefanoBorini I have a long history of PCs that experienced burn off... $\endgroup$ – N74 Dec 21 '15 at 17:16
11
$\begingroup$

I don't think Fortran is that close to the metal (see other answer) but it tends to optimize very easily. Loops are simple, and the language readily supports vectorization extensions (okay when I used it in my first job we were targeting a wide range of vector big iron).

There is also the large factor of inertia. A lot of numeric code is in Fortran, so builders of high end servers and supercomputers make sure they write good optimizing Fortran compilers. The compilers are good (even on machines with a relative lack of high quality compilers) so the users continue to use the Fortran and even write new code in it. So the builders make sure their next generation have good compilers, etc...

|cite|improve this answer
$\endgroup$
7
$\begingroup$

Be careful of urban myths here. If two compilers generate the same assembly code, then the resulting programs will have the same performance.

For any given piece of logic, there is a program in assembly language that minimizes its execution time. That program doesn't care which compiler generated it.

That said, compiled languages exist to make life easier for the programmer. Part of the cost of this is they may tempt the user into using features that don't result in minimal execution time. The prime example of this is new in C++. (How slow could it be - it's only three characters?) It practically begs you to dynamically allocate memory, and pay no attention to the runtime cost. If that's what you want to do, that's terrific, but Fortran could be faster just because it didn't suck you into doing that.

But way beyond that, I've never seen a program that, as first written, didn't have major room for performance improvement of the kind that the compiler could never clean up for you. As one example, spending a large fraction of time calling exp and/or log repeatedly with the same argument. As another example, calling DGEMM to multiply matrices and finding out that a large fraction of time goes into calling LSAME just to decipher its input character arguments.

This is at the same time as people are saying Fortran is faster because of pointer aliasing or loop unrolling. That's like saying a bus made by Porsche would certainly be faster than a bus made by Chevrolet. There needs to be a little common sense.

|cite|improve this answer
$\endgroup$
  • 4
    $\begingroup$ I dont think its just an urban myth. Fortran's support for whole array operations, PURE/ELEMENTAL functions etc. can help compilers easily optimize/vectorize or even parallelize. For e.g., see thinkingparallel.com/2007/08/14/…. What the compilers actually do is a different story (depends on vendor). $\endgroup$ – stali Jul 12 '12 at 17:20
  • $\begingroup$ @stali: It depends on more than the vendor. It depends on the program being compiled. I've seen people generalize from "there exists a program that Fortran can make run fast" to "Fortran is faster on any program". If you point this out, people can start to hem and haw and split hairs, and what it really comes down to in the end, is basically nothing more than what people want to think. $\endgroup$ – Mike Dunlavey Jul 12 '12 at 18:05

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.