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
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?
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