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?"
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
All we have is this "25 year old" language for numeric tasks, and another language that's about as old for system programming. It's called C.
--Matthew
SciPy is an open source python application that sits on top of quite a few C and Fortran libraries. It is specifically targetted at the scientific computing community, and its performance is quite good, even though it's still a very young product. It supports massively parallel computation, has a number of nice plotting and graphing features, and is completely cross platform. It also includes weave, which allows you to produce native C code from python.
Best of all, it's python, which means the learning curve isn't as punishing as C++, for instance.
The website for SciPy is:
http://www.scipy.org/
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?
Also, despite what you say, well formatted Fortran code is no more ugly than most other code (and a hell of a lot nicer looking than your average Perl code :-().
I don't know why people believe that newer languages are automatically better. At the end of the day, you got storage, you got ops screwing around with the storage, and you got a mess of control flow holding the guts together. Just because I'm some hotshot wanting to get my name in the (geek-) papers with my shiny new syntax doesn't mean it's any different. And it certainly doesn't mean it's any better.
So go ahead and learn Fortran. Learn about the joys of representing linked lists as a set of next indices into an array. Learn about dimension statements and equivalence blocks. Learn how to squeeze down your numeric processing into the nub of a kernel of procedural truth. You'll end up being a better programmer.
That is all.
I've known FORTRAN since...well...for longer than many slashdot readers have been alive. Done big, numerically intensive projects in it for many years in the 1980s.
I've also done C (1990s) and C++ (2000s).
Ten years ago the criticism about speed was true - that compiled FORTRAN would beat C++ to pieces. Not anymore, unless you're committing newbie mistakes in C++.
If I were you I'd make the best of all worlds. I'd use Python for upper level logic in a clean syntax, in a quick scripting environment.
Then, if there's numerically intensive loops in the lower reaches of your code that get executed billions of times, go ahead and use FORTRAN. Especially when you're doing something like computing eigenvalues for specially shaped matrices, etc., where chances are someone has already written a FORTRAN subroutien to do it well.
Finally, use something like SIP or SWIG to connect the upper level Python to the lower level FORTRAN. Look, too, at Numerical Python and SciPy for others that have been down this road.
There's a lot to be gained from all those netlib routines that have withstood the test of time and been optimized to such an extent that even the FORTRAN programmers surrender, and drop down to call BLAS routines that are best written in assembler.
Using FORTRAN for the whole project is asking for pain once you start looking at things like parsing character input, connecting to network, linking into system libraries written in C. Been there, done that, have the scars.
"Provided by the management for your protection."
I believe that the GNU and at least a few commercial fortran compilers translate the code to C before it compiles.
While this may be true (although I think both C and FORTRAN are translated to an intermediate form), I'd say that gcc doesn't qualify as a high performance FORTRAN compiler. On the other side, if you look at the compilers provided with super-computers, the FORTRAN compiler is usually much faster than the C compiler. I heard the main reason is because of the C pointers. In fortran, when a function receives two arrays as input, the compiler can assume (it's part of the language) that they are different arrays. In C, for the same function, you are allowed to send it the same array twice (it's called aliasing), so because of that, the compiler is restricted in the optimizations it can perform. This kind of ambiguities happen in other places too. That being said, I HATE FORTRAN and for me, C++ when carefully coded can be nearly as fast (Of course, I'm also using gcc which performance is adequate but not more...).
Opus: the Swiss army knife of audio codec
I'm a physics student working for an experimental physicist. He uses FORTRAN, so I use FORTRAN (only when I can't avoid it). You are right. Pythia (google search the word, and feel lucky) is a great program for simulating High Energy particle collisions (I'm doing Tevatron simulations in the background as I type), but since it was started a couple of decades ago, it's written in FORTRAN. They're trying to convert to C/C++ (can't remember which), but it's a multi-year project for code that's already written. They've put it off for so long because the FORTRAN code works just fine (for the most part). There are some memory considerations and interface issues that make them want to switch over.
It will be nice when the finaly do.
Don't Bogart the fish sticks
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