Slashdot Mirror
Is FORTRAN Still Kicking?
Algorithm wrangler queries: "I'm beginning to wonder if I should invest the time in learning FORTRAN. Although it is, arcane it seems to be the best tool when it comes to demanding optimization tasks and heavy computations. C/C++ does not cut it for me - it is simply too easy to make mistakes and I find myself using half of my time hunting bugs unrelated to the problem at hand. Additionally, although tools like Matlab exist they don't provide the power that justify the huge price tag they carry. I find any script based language (Matlab, Numeric Python, Scilab) to be inadequate as soon as it is necessary to use loops to describe a problem and using such tools for recursive systems can be a real pain. As another data-point, the Netlib repository seems to be very FORTRAN oriented, and it is a true gold mine when it comes to free routines for solving almost any computing task. What bothers me though is that FORTRAN code is really ugly and the language lacks almost any modern day language feature (I know about Fortran 90 but it is not much nicer than F77, and no one seems to use it). Can it really be true that the best tool we have for heavy duty computing is a 25 year old language, or have you found anything better - free or non-free?"
Fortran 90 has plenty of structured programming features to make maintainable code. Equally, if not more important, is that Fortran code can be much better optimized than C/C++ code for numerics. IBM did a good job on Fortran, and it's still a major player today.
Care about electronic freedom? Consider donating to the EFF!
As a recent CS grad I had to help some of my friends in the Meteorology department with their programming course(of course not taught by a CS prof). To my surprise it was FOTRAN. It seems a lot of the stuff NOAA and other government agenicies program is in FORTRAN so it is compatible with the stuff they stil use from the 70's and 80's.
"Success is not the result of spontaneous combustion. You must first set yourself on fire." -- Fred Shero
Fortran has several things going for it...
1) it's been the standard scientific computing language for so long, that every platform has a compiler, and that compiler is likely to be very mature (i.e. stable, and produces fast code).
2) since it's been a standard for so long, everyone has routines written in it which have been debugged and work, no sense rewriting them and introducing errors.
3) the language itself lacks complicated constructs, so it is very simple to optimize. This, with (1) makes fortran still outperform c, thanks to the compilers.
That said, I HATE fortran with a passion, mostly because it's ugly. 6 character variable names are impossible to deal with. Couple this with capitalization and indentation rules left over from the punch card era and you have code which is literally painful to read.
Doug
Venn ist das nurnstuck git und Slotermeyer? Ya! Beigerhund das oder die Flipperwaldt gersput!
The problems you described in C/C++ are probably mostly inherant to C. C is not type strict, so it lets you shoot yourself in the foot (or head) a lot.
What it sounds like you want is a strongly typed and type safe language. That would catch most of your problems, assuming your're just writing algorithms and not trying to interface to strange API or hardware.
PASCAL/MODULA-2/-3, or ADA can probably do what you want, and have GCC frontends available. These languages usually have runtime checks for safety, but after debugging, you can usually optomize them out for a production release.
So over all, go compiled, go type safe, go modern/OO if you can.
There is nothing so silly as other peoples traditions, and nothing so sacred as our own.
Different languages have different strengths and weaknesses. I use Fortran, C, Ada95, and Ocaml interchangeably for different tasks. Often times linking the object files into a single executable.
Fortran, designed for mathematics and engineering, obviously excels at that job. You might want to consider writing the "intensive" parts of your application in Fortran and then linking it with modules written in another language such as C or Ada.
I've found that C is perfect for handling the I/O routines for such apps, but my Ada libs are ideal for doing memory managment and when the code outgrows the practical limitations imposed by Fortran.(Note: Interfaces.C and Interfaces.Fortran).
Likewise Ocaml tends to fit around anything with a minimum of hassle.
Of course, this is just a subjective evaluation derived from my own experiences. However I would encourage you to experiment to find the combination that works best for you. As we all should know "Theres more than one way to do it."
I'm sorry if this post seems somewhat vague, but it would be rather hypocritical of me to outright prescribe a certain language or tool when I personally have a tendency to float around and use whatever tool is most convenient.
NiCad
Honestly, your objection to C++ is unclear to me...you say you spend more time fixing bugs than approaching the task at hand? Is this because you don't know the language that well? Perhaps because you're not taking advantage of the many excellent libraries available to you? Keep in mind that C++ library design requires a great deal of skill, but using a well-designed library is actually easier than coding in other languages.
C++ is my own personal choice for anything by the most demanding of high-performance computing applications. Is there an overhead to the language? Debatably, yes. Does it matter, in 99.9% of applications? No. And with only a little bit of forethought, even the "inherent" performance hits can be avoided in the places where it matters. It's just that you have to rely on a profiler to tell you where those places are...
There is a significant community of researchers and developers working on scientific and high-performance computing in C++. Check out some of these:
These are just a few good starting points. Do a google search for 'high performance c++' to find many more. Just, please, for the love of Deity, don't code in FORTRAN. ick....
Let's try not to let fact interfere with our speculation here, OK?
FORTRAN has the same kind of cherubic appeal as a very very large hirsute man wearing a tutu.
You can leave FORTRAN behind, but you can never forget it. Sometimes, I wake up at night, thinking about it -- wishing I didn't.
"I have opinions of my own, strong opinions, but I don't always agree with them." -- George H. W. Bush
...of the simple loop structures. In C, you can have a for( ; ; ) statement that does basically all sorts of weird crap in here ( ; ; ), and you can also do things like pointer aliasing (impossible in Fortran since there are no pointers at all).
Fortran loops, on the other hand, are very very simple - all you can do is increment the loop variable, and repeat. That allows for very heavy loop optimization by the compiler - comparable to what the best assembly programmers might be able to do. Furthermore, a Fortran compiler can more easily generate optimized loop code using vector instruction sets like Altivec or SSE2, whereas C compilers have a much harder time (again, because of the wide variety of loop structures possible in C, and things like pointer aliasing, etc.)
All is Number -Pythagoras.
It's obvious that the story's poster didn't really look into FORTRAN much past the aging F77.
I currently use F77 to do research in magneto-hydrodynamics simulations of neutron stars on Cornell's Velocity Cluster (which has been featured on slashdot before). Fortran, due to its lack of things like pointers, etc, is rediculously efficient, and almost completely cross platform (because surprise surprise- it's very difficult to attempt to do anything remotely platform specific). The language is much simpler than something like C with pointers, etc, that must be messed with. Sure it's ugly as hell, but once again the newer versions of Fortran take care of most of these issues.
I would suggest that anyone interested in high performance computing should check out High Performance Fortran. It's a set of extensions to the F90 language to allow the seemless integration of large-scale parallelization in your code. It also has several other performance advancements.
I highly disagree with the poster of the story, Fortran 90 is much more modern than F77, including things like objects, safe pointers, better recursion, better array sharing, generic routines (a type of function overloading). The language syntax is also much more lenient than F77 (which was designed to work with punchcards). It also has some really great array operations (things like slices, etc) that are rediculously fast. While I absolutely hate F77, if I was going to write a computationally intensive simulation, I'd probably do so in F90 or HPF.
A lot of people still use Fortran, especially computational physicists and meteorologists... Many of these people don't have time to learn new programming languages, and Fortran works very well for what they need, better in most situations than almost any other language. It's something to consider.
Cheers
Justin
The course mainly focusses on solving machine numbers, solving linear systems (direct and iterative methods), solving non-linear systems (mostly Newton-type methods), and solving eigenvalue/vector problems. The codes that students wrote last year started from scratch with early assignments. Then, I allowed them to incorporate Basic Linear Algebra Subprograms (BLAS) into their codes. Then they were allowed to use LAPACK for the rest of the semester. They were free to use the C interface, but most chose to use the FORTRAN examples, probably because of the skeleton code that I provided.
Given the tremendous amount of code that is already out there, I agree that knowing FORTRAN is an asset. And since it's not hard to learn, why the heck not, right?
On a side note, they had to use Makefiles, LaTeX their assignments, and send everything to me electronically in a gzipped tarball. They got quite a workout in console tools. For reference, I had some that were quite familiar with the system and some that had had BASIC at some level and that's it. Lots of help was needed as the semester reached the final weeks.
Matlab was used for visualization and graph creation, but I am considering using GNUPlot this year, if it is up to the task. (I think it probably is.) I may also encourage the use of Octave, where possible.
For reference, the class website (which will soon be updated for the new semester) is here: Math 224.
Curmudgeon Gamer: Not happy
"FORTRAN: "The infantile disorder", by now nearly twenty 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." (1982).
"In the good old days physicists repeated each others experiments, just to be sure. Today, they stick to FORTRAN, so that they can share each others programs. And bugs."
--Edsger Dijkstra
(Interestingly enough, Dijkstra died today.)
Having said that, when you're writing a large piece of code, much of the code probably isn't number crunching; its schlepping data back and forth between solvers, doing I/O, etc. For that, FORTRAN is fairly limited; so you use other languages.
You use the right tool for the part of the code you're writing. We are working on a large simulation code; our numerical solvers are all in FORTRAN, and we have no intention of chaning that; however, we use other things (C, Python) for higher-level tasks. And this is how it should be. People who argue about `Language X rocks!' or `Language Y sucks!' Just Dont Get It. All the languages still in use are still in use for a reason -- they have certain things they're good at. And so you pick the right tool for the job.
This shows absolutely no understanding of the language. Sit down if you're not in the field.
I used to teach "Practical Parallel Programminh" at the Univesity of Leeds and this is just crap. Fortran is typically used with OpenMP / MPI to do parallel programming. Older freaks might use PVM. They're all available for C/C++.
And it's not that I'm no longer in the field, I currently work on Grid/Globus applications.
Fortran is no more safe or fast to program in I'd argue it's a less safe myself. The performance difference between an optimal fortran program and an optimal C program I'd argue is nearly nil. Show me different, and explain why. Go on, try it.
jh
jh
This is sort of true. Fortran isn't nessecarily all that much more inherently parallelizable than other languages, but because it is the language of scientific computing quite a bit of effort has been expended on compilers that automatically parallelize for vector computers. For non vector computers, it really doesn't matter what language you use - You'll be using MPI to do it anyway, so as long as you have a set of language bindings, you're ok. (Although as far as I can tell these only exist for C and Fortran...)
The real reason that FORTRAN continues to persist in scientific computing is twofold - First, there is a huge Fortran code base. Both in terms of things like Numerical Recipies and completed code. For example, I spent my summer integrating a Weather Model with a fluid dynamics model. The Weather Model, MM5 decends from the early 1970's (Pre FORTRAN 77). It's in Fortran. It's large. It would take a hell of a lot of effort to rewrite it, and nobody is going to do it. Theres a quite a bit of this stuff around, and the effort to rewrite it would enourmous, and frankly not worth it.
Second, most people programming in scientific computing are not CompSci's. They Computaional Chemists, and Electrical Engineers and Meteorologists and who knows what else - but not programmers. They learned FORTRAN and as long as they can get their stuff done in FORTRAN, they're not gonna learn C so they can track down a segfault when their pointers wander off an array. The new PhD's probably learned C and will use it if starting from scratch(After all, even in FORTRAN 90 Dynamic allocation and pointers are really, really limited, often requiring recompiles whne your problem size changes), but 40-50 year old computational chemists are not gonna learn C. Period. So FORTRAN continues to get upgraded. At least they got rid of the @#$% Hollerith-punch card column layout...
Why?
I see these annoying questions all the time. "Don't tell me that a 30 year old whatever is the best we have!" Alright, I won't tell you. But, I'll tell everyone else, Fortran is sometimes the best language for the job, even after 30 years. It is simple, fast as hell and very robust. What's wrong with that? Oh, you can't write a gui in it or you can't have derived object classes? Tough, that's not what it was designed for.
Why is it that the age of a language or tool is associated with it being inferior? Do you feel that everything that was created prior to your birth is inadequate or inferior? It is in fact, very common for the earliest versions of many things to be far superior to newer ones. This is true, not just for for languages but also for many other things. Most often, the "improvements" and "advances" that are made cheapen, dilute, complicate and destabilize the original product. This is, at least partly to blame for the disposable society that we live in today. Better, or smaller faster cheaper, usually also means less reliable and durable.
To answer your question, yes. Fortran is still a very viable language and is still, after 30+ years, the best language for heavy number crunching. If you need to create a gui and have derived oject classes as well, just link to the fortran libs. But, I'm sure that some snot nosed whippersnapper will suggest that Perl is the only solution. Puhleez!
While the first two of the three points listed in the parent post are somewhat true, they are usually mitigated, depending on the languages you consider (e.g., you can find good compilers and well-optimized routines for C++ that will perform on par with FORTRAN, but maybe you can't for, say, Java).
However, the third point is actually a disadvantage in my mind: the overwhelming simplicity to FORTRAN leads to simple-minded implementations that are often less efficient (in time and especially in space) than a good implementation in a more modern language.
Case in point: Check out the sorting chapter of Numerical Recipes, and you'll find that their "ultimate" sorting algorithm -- and hence the algorithm that a whole generation of FORTRAN coders think is the fastest -- is heapsort. Now, heapsort is a fine algorithm, but it has some significant disadvantages over quicksort (the algorithm used in the C/C++ standard library. well, almost, anyway.) Of course, you can't implement quicksort properly in FORTRAN because the language isn't recursive! So, I guess it makes sense that they skip over it in Numerical Recipes.
These sorts of issues abound in FORTRAN programming. A lot of (older) engineers and scientists still insist that FORTRAN is the best language for high-performance mathematics, and to some extent, they're correct. As long as your mathematics are limited to those problems that can be solved with gobs of iteration, FORTRAN is your tool. But the minute you step into a realm where a more advanced data structure would be more important to performance (think hashes, heaps, trees, linked lists, etc. Places where algorithms actually matter.), FORTRAN falls flat on it's face. And don't even get started on space efficiency -- any modern language will beat FORTRAN 77 on this, hands down. Pre-allocation of arrays tends to kill an application's memory footprint...
Some of these issues are addressed in FORTRAN 90, but really, if you're going to use that language, you might as well use a language like C++, which is more common, and just as efficient, with proper care.
Let's try not to let fact interfere with our speculation here, OK?
I'm not going to wade in on a lame language war, but Fortran IS very portable. I have worked on code that was written in 1967 for a CDC mainframe. It was then ported to a:
PDP-11, then a
Vax, then a
486-class PC. The code ran much faster on the PC then the Vax.
Then I discovered that I needed a routine from the original CDC implementation, which had not been touched since. So I typed in the routine FROM CDC PUNCH CARDS. Compiled perfectly.
A caveat about Common Lisp:
...) that allow you to write code to traverse arrays in very convenient ways.
it has a lot of good things that are similar to Fortran in the numerical world.
* Integers are not a fixed width, but transparently go to multiple precision instead of wrapping around.
* All of the intrinsics deal with complex numbers transparently.
* True rational numbers: i.e. ratios of integers.
* (Better than Fortran): STANDARDIZED parameters to describe the floating point parameters of the machine (e.g. machine epsilon). Also, built-in, portable access to the floating-point encoding in bit form. Very nice bit-bashing intrinsics (I like them better than C).
* Very flexible arrays. Some nice intrinsics (row-major-aref
* Notation is pretty flexible: can add multiple numbers together using (+ a b c d e f g).
* Lisp macros are amazing. The whole power of the Lisp language is available as a "preprocessor." You can relatively easily write programs that write programs that write programs. As an example, although Lisp has built-in, kick-ass OO (CLOS), you could write your own transparent object-oriented extension to Lisp (i.e., roughly equivalent to what cfront did for C) in about 200 lines of Lisp macros, and it works as well as if it were built-in.
Some slight "disadvantages"
* Prefix notation is the default. Add-on macro packages let you also write code that is infix
(e.g. #I instead (+ (expt a 2) (expt b 2) (expt c 2)))
but it is not a built-in standard.
* The standard does not *mandate* the ability to specify extremely large arrays. Not necessarily a real problem unless you want > 1 GB arrays on a typical 32-bit implementation.
* The notation is sort of verbose. Array references go like (aref array-variable i j k l). This is just notation, so the compiler should optimize this if you ask for it.
* Variables are not typed. The way around this is declarations. Again, the notation is somewhat verbose. (the double-float (+ (the double-float x) (the double-float y)) or (declare (double-float x y) (+ x y)). Again, this is just notation, so you can "easily" write lisp macros to write either of these as something like (d+ x y)
* Most high-performance computers have high-quality Fortran compilers. Fewer have high-quality architecture-specific Lisp compilers. Likewise for highly-multiprocessor machines.
* Most importantly, the bias in the Lisp world has been to optimize things like OO method calls, function calls, recursive function calls, automatic garbage collection. Not much pressure to optimize number-cruching on large arrays. Fortran compiler writers for the last 40 years have been asked to do one thing: optimize number-crunching on large arrays.
That said, for certain numerical codes, Lisp is a nicer tool than Fortran. For some other numerical codes, a good Lisp compiler (which might not be available for your architecture) given code with sufficient declarations could match a Fortran compiler for code speed, no more than 10% performance loss, sometimes performance gain. For some codes, Fortran is going to win big in execution time.
I read an article recently about a C extension to Python that very efficiently (and correctly) handled multi-dimensional matrix math. Thus you can write code using the very nice syntax of Python and still get good performance. The author of the article said something like "No one who has tried Python with these extensions ever wants to go back to FORTRAN."
It made me wonder if, with enough C extensions, Python can take over FORTRAN's niche as a high-performance heavy number-crunching language.
I don't know enough about the issues to make any predictions; I'm just wondering.
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
PL/I, "the fatal disease", belongs more to the problem set than to the solution set.
The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence.
APL is a mistake, carried through to perfection. It is the language of the future for programming techniques of the past: it creates a new generation of coding bums.
It is practically impossible to teach good programming style to students that have had prior exposure to BASIC; as potential programmers they are mentally mutilated beyond hope of regeneration.
Well, I think I might have heard somewhere that he actually said something nice about Algol, but I can't find a quote anywhere.
Anyway, I wouldn't bother too much about what Dijkstra said 10-20 years ago about programming languages long dead. Both FORTRAN, COBOL and PL/1 has clearly proven themselves useful in numerous real-world applications. And contemporary Basic, like Visual Basic shares almost nothing but the name with the kind of BASIC Dijkstra was talking about.
Of course, being a computer scientist, I certainly agree with him, but even I am not doing what I preach. C++ is certainly a large pile of shit, and C isn't much better. Java could almost make it, if it wasn't already so braindamaged by the C/C++ infection. Perl is certainly an offense to anyones aestethics (if people have that these days). Python could almost have made it if it weren't for the completely braindamaged scoping rules, and various other twarts.
Well, guess what languages I use at my workplace? Do I violently disagree? No, because these are the languages that actually do the job, they have fine implementations you can trust, they have lots of available libraries for almost any task, and most people already know them, meaning anyone can pick up where the last person left.
I am not a numeric analyst, so I've never had the use for Fortran, but if that was what I was mostly doing, I would certainly learn it. Learning to speak the lingua franca of numerical analysis will certainly be helpful if that's what you are going to do, even if you don't intend to use it yourself (but you will, trust me - I use C myself for the same reason). And I highly doubt that Fortran 9x is not much nicer than FORTRAN or Fortran 77, numerical people doesn't seem stupid to me, and certainly not as stupid that they would have invented it otherwise.
Perl has become popular among non-programming scientists
I'm a scientist who cut his teeth on FORTRAN, and still use it for a variety of reasons, including the richness an quality of the numeric code available for use with the language, and the most excellent optimizing compilers that can be used.
Perl has none of that.
Perl is fine for weeding through a lot of data that has been generated using automated D/A systems, but that is text processing which Perl is very strong at.
But for computationally intensive tasks, Perl is just wrong.
A nice guide to some other sources of mathematical software is NIST's GAMS for Guide to Available Mathematical Software.