36

I'm trying to decide between Fortran and C++ for an application in scientific computing. It's not clear to me if Fortran still has advantages over other languages when it comes to performance. For example, I believe since Fortran enforces strict aliasing, better optimizations could be made by the compiler when compared to C before C99. I'm unsure of how C++ fits in here.

Any guidance?

Fortranner
  • 2,525
  • 2
  • 22
  • 25
royco
  • 5,409
  • 13
  • 60
  • 84
  • 22
    "FORTRAN--the "infantile disorder"--, by now nearly 20 years old, is hopelessly inadequate for whatever computer application you have in mind today: it is now too clumsy, too risky, and too expensive to use." -- Edsger Dijkstra, 1975. – James McNellis Jan 27 '11 at 21:13
  • I have to go with what James said, really. If it does have any advantages, they're irrelevant today. – Moo-Juice Jan 27 '11 at 21:15
  • 25
    @James McNellis - Dijkstra was a bit of a cremudgeon. If you can find me a quote from Dijkstra where he *complements* a language, I'll accept that as an argument. – T.E.D. Jan 27 '11 at 21:18
  • 4
    @T.E.D: "LISP has been jokingly described as "the most intelligent way to misuse a computer". I think that description a great compliment because it transmits the full flavor of liberation: it has assisted a number of our most gifted fellow humans in thinking previously impossible thoughts." -- Apparently he liked Lisp... – James Jan 27 '11 at 21:24
  • 35
    "Arrogance in computer science is measured in nano-Dijkstras" -- Alan Kay, 1997. – Fred Foo Jan 27 '11 at 21:28
  • @T.E.D.: [Just a bit.](http://programmers.stackexchange.com/questions/39/whats-your-favourite-quote-about-programming/11830#comment-19852) – Fred Nurk Jan 27 '11 at 21:30
  • 9
    @T.E.D: `(Whatever (his (attitude (might (have (been, (he (does (have (a (fair (point (against (LISP (syntax)))))))))))))))`. – sbi Jan 27 '11 at 21:36
  • 1
    @James - This one's more applicable : "When I read the first manual, the Lisp 1.5 manual, published in 1961, I could not believe my eyes. It was an extremely poor language. Now it has become the defacto standard of the AI community, which now suffers from Lisp, the way the rest of the world suffered from Fortran" – T.E.D. Jan 27 '11 at 21:37
  • @T.E.D.: I can't help but wonder which of those two quotes came first... :) – James Jan 27 '11 at 21:44
  • @James - A big clue is that one was given in the past tense and the other not. The exact answer is that the one you gave was from 1972, and the one I gave from 1985. – T.E.D. Jan 27 '11 at 21:57
  • 2
    @T.E.D.: Okay, so Dijkstra in 1985 was criticizing Lisp over the Lisp 1.5 manual of 1961? How timely. – David Thornley Jan 27 '11 at 23:08
  • 1
    @T.E.D: I think of programming languages a bit like Churchill thought when he said "Democracy is the worst regime of all, except all others" (or something like this). – Matthieu M. Jan 28 '11 at 07:11

10 Answers10

52

I took a look at some of the stuff in the latest Fortran standards, and frankly I'm impressed. A lot of what I hated about the language 20 years ago is gone now. No more line numbers and special columns (may they burn in hell).

Fortran has been heavily used in engineering circles for 50 years now. That gives you two advantages if you work in those circles. First off, these folks care a lot about optimization. That means Fortran compilers tend to have the best optimizers around. The language itself is a lot more optimizable than Cish languages too, thanks to its lack of aliasing.

The second advantage is that Fortran's library support for number crunching simply cannot be beat. The best code is nearly always going to be the well-debugged code you don't have to write.

If your application doesn't fall under scientific, engineering, or number crunching in general, then neither of the above will be a big deal for you, so you may be better off looking elsewhere.

T.E.D.
  • 44,016
  • 10
  • 73
  • 134
  • 2
    The lack of aliasing argument isn't so much true in C anymore thanks to `restrict`. But +1. – Billy ONeal Jan 27 '11 at 23:10
  • 5
    It's no big deal to use Fortran libraries from C++. And C++ libraries may even outperform Fortran, since C++ supports inlining much better (in particular with template based expression libraries). So, upshot is to use a language that helps with higher level issues; not sure that either C++ or Fortran qualifies... – Cheers and hth. - Alf Jan 28 '11 at 11:12
  • The issues mentioned in the comments help with, but do not totally alleviate the problem. Restrict is a definite improvement, but it would be better yet to not use pointers at all (from that standpoint, const reference parameters are actually a bigger deal). But at least its attacking the right problem. Better C++ template inlining just helps alleviate one (of many) problems that Fortran never had in the first place. – T.E.D. Feb 11 '11 at 14:45
  • 6
    FWIW a lot of commercial aircraft systems code (eg. the FMC, Nav systems etc.) still relies on Fortran for its navigation calculations. Not sure whether that's just a legacy, or whether it's because the numeric handling is accurate, or even because engineers were brought up on FORTRAN but these systems are generally very conservative, and have years of reliability behind them. The compilers are also well understood, which is another factor that supports running these safety-critical systems. Doesn't mean you'd leap into Fortran today, but when you fly, Fortran is helping you stay safe! – Pete855217 Jul 26 '12 at 08:00
28

The other major issue is the learning curve which is very huge for C++ and exceptionally small for Fortran (90 and later). Fortran is like MATLAB with operations like ...

  • B'DB is matmul( matmul(transpose(B), D), B )
  • L2 norm of a vector is norm2(x)
  • SVD of a matrix using LAPACK is call gesvd(A,S,u,vt)

Fortran also has pointers, dynamic memory, user defined data types etc.

It is well supported by major vendors (Intel/Sun/IBM/Cray/PGI/NAG etc.), open source (gfortan/g95) communities and developers of numerical library/APIs such as PETSc, MPI etc.

Heck the new standard (Fortran 2008) even has co-arrays for doing parallel programming without the need for MPI/OpenMP and some Fortran compilers already support it (g95 and Cray).

Basically it has all the good qualities required for numerical computing, is easier than MATLAB, is standardized, free, scalable (with MPI/OpenMP and co-arrays), produces blazing fast/parallel code.

For numerics nothing beats Fortran but unfortunately for anything else everything beats Fortan. So if you are a scientist with a safe job and only do numerical/HPC computing then stick with Fortran otherwise learn and use C++ as it is widely used for non numerical software.

AboAmmar
  • 5,439
  • 2
  • 13
  • 24
user4562
  • 281
  • 2
  • 2
15

Fortran allows whole array operations and also operations on array sections. There are C++ classes for arrays, but I don't think you can refer to a slice such as x(:,2:,1:N3:2) as easily as in Fortran. This lets one express some algorithms pretty concisely.

The convenience of Fortran's array operations extends to arrays of derived types. Suppose you have a an array of dates:

type date
integer :: month,day,year
end type date

type(date) :: x(1000)

Then x refers to the array of dates, x%month refers to the array of months, and pack(x,x%month==1) refers to all dates in January. How many other programming languages offer this convenience?

Some of the earlier comments about Fortran -- "old and disgusting" -- are biased and should be discounted accordingly. Let me argue the opposite. In my opinion the free format of Fortran 90 looks better than the syntax of C and C++, with the curly braces and semicolons. Leaving them out or incorrectly putting them in can cause errors in C and C++ that have no counterpart in Fortran.

Fortranner
  • 2,525
  • 2
  • 22
  • 25
12

Fortran has been highly optimized for mathematical (especially matrix) like operations.

C++ has been highly optimized for object usage.

Which is more important to you.

As noted below C++ has an optimized matrix library.
But Fortran's whole purpose is optimization of mathematical processes (especially matrix operations). The fact that these optimizations are built into the foundation of the language (rather than a library) and have about a two decade head start on research over C++ I doubt (but don't know for a fact) that in this area Fortran is going to win hands down.

Martin York
  • 257,169
  • 86
  • 333
  • 562
  • 1
    There have in recent years been developments on the C++ side of matrix manipulation, esp. the new cache-aware algorithms in the Matrix Template Library. I don't know how they compare with Fortran, since I've never bothered to tame that dinosaur. – Fred Foo Jan 27 '11 at 21:24
  • 3
    Most of Fortran's advantage is going to come from the compiler implementation itself. C++'s handicap here isn't really something intrinsic; it's that most of its users don't care that much about tight loop (matrix) optimization in their compiler, so the compiler writers don't have nearly the incentive to work on it that Fortran compiler writers have. – T.E.D. Jan 27 '11 at 22:11
  • 1
    @T.E.D.: Also, the aliasing rules are different, so it's possible for the compiler to optimize much more aggressively. Consider matrix multiplication: in C++, there are certain operations that are done in a defined order, regardless of whether matrices overlap or not. This means that it isn't possible to automatically parallelize it, since if matrices overlap that could give different results. Fortran compilers can go ahead and parallelize in cases like this, and if there's problems from overlaps it's your fault. – David Thornley Jan 28 '11 at 15:28
8

Advantages of fortran95 and above over c++(2003):

  1. As previously(by user4562) mentioned short learning curve(my first language was C and i still can't master it , similar is true for C++)
  2. (My personal opinion) Easy for code transition from Octave(for that matter Matlab)similar syntax,same modularity[I use Octave to prototype a program and rewrite in fortran95 for speed],though u can directly use octave code in C++.
  3. dynamic memory allocation is quite straight forward.(f77 didn't have this at all!)
  4. libraries support (u can do this in c++ as well , but its natural to use fortran)
  5. Co-array support for parallel computing (pity only cray supports them as of feb 2011 gfortran work has started as of gfortran4.6 but still a long way to go)

in short if your program or application is purely scientific computation use fortran 95 and above if calculating a few numbers is just part of the story use C++ (or whatever u feel is better)

Evan Teran
  • 87,561
  • 32
  • 179
  • 238
fedvasu
  • 1,232
  • 3
  • 18
  • 38
7

I am new to programming.I have been programming in the field of finite elements for about a year. After some research on the net I decided to use fortran 2003.I learned to program in the modular style in about ten days by studying the Chapman book. It's one year on and i have written about four thousands of code lines in modular format(maintainable,reusable and neat codes) and haven't used any character variable at all. I don't think that by studying C++,matlab,python,java ... for ten days you would be able to write numerical codes as efficient as in fortran. fortran 2003 also has all the necessary OOP capabilities which I am learning now. So in terms of language strength in the numerical aspect fortan doesn't lack anything(modular style,OOP style,powerful array capabilities,powerful libraries, free and commercial up to dated compilers,very easy to learn, very efficient ...). Languages like python/numpy has most of these capabilities but lack efficiency. Languages like C++ also has most of the capabilities of fortran(although for array computation which is the main core of numerical computation you have to import some libraries!!), but maybe a program written by someone like me in fortran would be more efficient than one written by some c++ programmer with 10+ years of experience.
Finally I do my heavy numerical computations in fortran(modular or OOP format), and use python\numpy for small size computations(like creating plots,small size array computations ... ).

Babak Abdolahi
  • 6,559
  • 3
  • 15
  • 4
6

My experience with Fortran is that it's easy to learn, clean (being highly modularized), and thus well suited to a non-programmer whose main concern is doing highly optimized numerical computations. Although equal optimization can be performed in c++, (even perhaps to a greater extent), it takes a lot of instrinsic understanding to achieve those level of optimizations. When it comes to matrix calculations, out-of-the box a Fortran compiler will normally out-perform a c++ compiler. I'd also add that Fortran has keywords that are specifically designed to help the programmer to squeeze more performance out of a numerical routine. C++ has this too, but not to the extent Fortran does.

Another advantage is that Fortran is not operating system or architecture specific. In other words the Fortran code you write on one operating system or architecture should easily port to another where there is a Fortran compiler.

Another advantage is that modern Fortran is normally backwards compatible with older code bases of Fortran. And the code base that has been built over the years in Fortran is huge and extremely sophisticated (being mostly done by scientists and mathematicians).

Also, personally, I really enjoyed the built-in file handling functions that allow one to read a data file and perform operations on it almost instantly. Many other built-in functions in Fortran are designed to allow this convenience. C++ offers mainly building blocks to do this and this requires a bit of sweating it out just to read a data file b/c you need to know something about delimiters (where Fortran allows you to specify the delimiter).

Beyond this I can't think of advantages. Most anything else would be string manipulations, or algorithmic based operations to which c++ as a language, and in general it's compilers, are better suited and most often will perform better. A good knowledgeable programmer will likely prefer c++ as she/he would understand how to optimize a numerical routine in a way that could likely perform better than a Fortran compiled routine. Additionally good reliable Fortran compilers are not as easy to come by as good reliable C++ compilers.

4

IMHO, the only advantage that really matters is that programming FORTRAN allows you easier reuse of a lot of existing FORTRAN code and libraries. And if you have 50 FORTRAN programmers at hand for a project and a limited time frame, are you going first to teach them all C++, or will you accept to let them use their favorite language?

Doc Brown
  • 19,739
  • 7
  • 52
  • 88
  • 1
    You are almost certianly right. Call it "installed base". This is the same advantage "Wintel" boxes have over other systems, and the same advantage C/C++ has over other system's programming languages. There's just too much support material and mindshare already in existance for anything to displace them in their niche, no matter how good it may be. – T.E.D. Jan 27 '11 at 22:18
  • +1 That is an important factor when doing considering the domain space. The ability to re-use rather than re-invent will lead to more optimized code and a shorter development cycle. – Martin York Jan 27 '11 at 22:59
3

Given the existence of scientific computing packages like LAPACK++, which are highly optimized already, modern Fortran doesn't even have a performance advantage. C++ may have its faults, but performance is not one of them.

Daniel Gallagher
  • 6,915
  • 25
  • 31
  • 5
    Neither LAPACK++ or its successor TNT have all the stuff in them that the Fortran LAPACK contains. Still, it is getting there. – T.E.D. Jan 27 '11 at 21:45
  • In any case, the latest lapack release, 3.3, has an official C interface. – janneb Jan 28 '11 at 07:58
0

With the emergence of template-meta programming (especially expression templates), C++ reached FORTRAN's league in numerical computations, so speed should not be an issue anymore. However, there's still some things to be said about other issues:

Pro FORTRAN: The older folks might know it better than C++.
Contra FORTRAN: It's a disgusting, old, and mostly abandoned language, that's already outdated the moment your start your project. Whoever learns programming now, is very unlikely to learn FORTRAN, so you might run into problems finding programmers for the project later.

Pro C++: It's relatively modern, with compilers still improving in considerable strides. It allows you to write quite expressive code.
Contra C++: Some of those template error messages will make you weep.

sbi
  • 219,715
  • 46
  • 258
  • 445
  • 7
    +1 for template error messages making me cry. – James Jan 27 '11 at 21:43
  • 3
    Are you talking Fortran 2008, or one of the older versions from before C++ even existed? Also, I don't think C++'s speed disadvantage was ever entirely an issue of templates being slow. Its really more an issue of what C++ compiler writers care to spend time improving in their compilers. – T.E.D. Jan 27 '11 at 21:48
  • @T.E.D.: I didn't even know that they are still advancing FORTRAN. Anyway, C++ wasn't slow due to templates, but TMP allows you to write very expressive code that's transformed, at compile-time, into code that allows the optimizer to do more of its magic. Writing matrix manipulation as `m1 * m2 * m3` without having a temporary matrix object - that's what TMP is for. – sbi Jan 27 '11 at 21:58
  • @sbi - Yeah, I didn't either, until I was forced to interact with it for a project last year. Before then, I thought like everyone else here. It's still not gonna be my favorite language, but it isn't a total loss like it used to be . – T.E.D. Jan 27 '11 at 22:03
  • 3
    I don't beleive that assertion "emergence of template-meta programming, C++ reached FORTRAN's league in mathematics". The main problem I have with that is not the compile time stuff that C++ does but the optimizations that Fortran has built into the languages specifically for mathematics (especially matrix manipulation). The Fortran compiler has four decades of research into this field while C may have optimizations none of them are designed for the same scenarios that Fortran is optimizing for, – Martin York Jan 27 '11 at 22:43
  • I like this summary from [SO is fortran faster than c](http://stackoverflow.com/questions/146159/is-fortran-faster-than-c/172832#172832): Which basically says it depends. – Martin York Jan 27 '11 at 22:57
  • +1 to just counter the anonymous downvotes. – Cheers and hth. - Alf Jan 28 '11 at 11:13
  • @Martin: I think the main way to improve performance nowadays is mostly through massive parallelization, not through squeezing the last 10% out of optimization. If you can run your computations on your graphic card, you beat all optimizations any compiler tailored for a more traditional CPU can come up with. Now this isn't my field of expertise, so please correct me if I'm wrong, but I haven't heard that CUDA comes with FORTRAN bindings, nor OpenCL. But even if they do - the main advantage then still lies in employing this parallelization, no matter which language you do that from. – sbi Jan 28 '11 at 13:10
  • Anyway, performance is just one point in choosing a language for a project, and I've listed a few others. [Expressiveness](http://en.wikipedia.org/wiki/Expression_templates) is just as important, and `m3 = m1 * m2` is really hard to beat. OTOH, this expressiveness breaks down the moment you do something wrong and the compiler barks at you in a 23.8k error message. The question is whether you want to put up with this or that, weigh one of these more or the other. Nobody but the OP can do this. – sbi Jan 28 '11 at 13:14
  • 1
    @sbi: When I think of scientific computing and fortran desktops are not what come to mind (so CUDA to me is not relevant). But parallelism is. And every hard mettle multi-core system that comes with a fortran compiler (that I have seen) is designed for parallelism. With its strict aliasing rules fortran is more naturally a data parallel language (than C++) and easier to parallize by the compiler. I agree that C++ is very good at expressing intent with relation to object (its what it is designed to do). Fortran is better at expressing mathematical intent (and usually without the need for the – Martin York Jan 28 '11 at 14:20
  • ... programmer to get to involved with the parallelism (compilers job). – Martin York Jan 28 '11 at 14:20
  • 1
    The thing about template metaprogramming is that it can accomplish nothing that you couldn't accomplish by writing the same code by hand, since it's code generation. Since Fortran can do some important calculations faster than C or C++ (because of the aliasing rules), it retains the performance advantage. C++ does rule in expressiveness, since TMP can provide great notational convenience that can be added to easily, while Fortran's expressiveness is more limited. – David Thornley Jan 28 '11 at 14:53
  • @Martin: That might well be true (although I have heard of scientists who would insist on writing their programs _for PCs_ using FORTRAN, because "that's just the best"). As I said, this is definitely not my area of expertise, so I'll just appreciate your point and bow out. – sbi Jan 28 '11 at 16:04
  • 1
    @sbi: I am no expert either. And nowadays with supercomputers being replaced with a cluster of networked X-Box/PSP the most effective language can be swinging the other way (with CUDA). Its 20 years since I wrote any fortran (my choice now would be C++ but that is because of my ability to use C++ better than fortran). – Martin York Jan 28 '11 at 18:11
  • @David: One thing TMP can is computing things at compile-time and massively inlining the resulting code. That can make quite a difference in an inner loop (although I agree with you in principle). – sbi Jan 28 '11 at 18:17
  • 1
    -1, certainly agree with speed not being an issue, but the pro/contra arguments are very poor. How do you define "disgusting"? What does "old" have to do with it, is that now an aspect of language? I would also argue that finding programmers for your project is easy, as one advantage is that Fortran is relatively simple. Seems to be more of an emotional answer, but I guess that's what these non-constructive questions lead to. – steabert Jun 08 '14 at 11:27