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

Yes

[mfos.org]

FORTRAN is used in high performance scientific computing. The language allows for high parrelelization.

Use Fortran 90

[Lally Singh]

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.

FORTRAN is easy

[Philippe]

You can become a passable FORTRAN programmer in a couple of hours if you already know another language, such as C or Pascal. There are a couple of gotchas (predeclared variables & COMMON statements IMHO).

If you are going to touch any heavy simulation code (such as statistics, physics & biology) learn FORTRAN. It works very well for those problems. Yes, it is old, but that doesn't mean it's bad. It's not modern, but it works surprisingly well.

I find myself teaching FORTRAN to budding scientists, and they are able to write complex stuff very quickly because they don't trip all over the language (e.g. '==' vs '=' in C).

Just link your FORTRAN libs

[mocm]

to your C code. You just have to know how FORTRAN arrays are held in memory and how long the FORTRAN types are. Then you need to know what standard FORTRAN libs you need to link, so that your numerical libs will work. I did that for lots of my numerical work and it worked fine. You have to test it of course and it takes a while to work out the kinks.

Re:Don't complain about C!

[owlmeat]

C is not older than Fortran. Fortran dates back to 1954, when K & R were probably toddlers.

Re:Try Common Lisp

[ultima]

Common Lisp is a very high level language with a tremendous amount of expressiveness, and it is suited towards academia in that in general, functionality is not sacrificed for performance.

Check out http://www.lisp.org, http://cmucl.cons.org/cmucl for a really good implementation (and there are even Debian packages of it).

CL is not known for its parallelization abilities, but if you need a language that lets you describe mathematics, CL is useful.

Lisp is actually based around something called the Lambda Calculus, which is a way of expressing concepts by transforming data into other data using data which is expressed as a "function". Because of this, Lisp has a lot of abilities that other languages lack, such as extremely simple and powerful function composition, even at run-time. CL also has a massive core library with OO facilities, basic mathematic primitives, good FFT suppot in most implementations, windowing system support, and good commercial vendors like Franz. Check it out; it's almost as old as Fortran, but has evolved in a much more elegant manner.

Re:NOAA

[GuidoDEV]

Speaking of meteorological programming, ALL the major atmospheric models are written in FORTRAN. The ETA, AVN, NGM, MM5, WRF, and scores of lesser-known models...all of them written in FORTRAN (most of them FORTRAN-90 now, but some of the older ones are FORTRAN-77). The MM5 & WRF may be found here [ucar.edu] and here [ucar.edu]. The source code to several others is readily available as well if you're so inclined, for instance the ETA [noaa.gov] and the ARPS [ou.edu]. Anyone wanting to run them may do so fairly easily on a PC running Linux (any new PC will be able to run a fairly hi-res model real-time); I do so myself.

On languages and Fortran.

[McDoobie]

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

Re:Use Fortran 90

[rsilva]

Yes, I completely agree. I have already posted a message about this in Slashdot foruns where I described some of the Fortran 95 characteristics:

http://slashdot.org/comments.pl?sid=3041&cid=145 39 90

Something that changed from that time is that now we have a free compiler for non-commercial use (linux, i386):

http://www.intel.com/software/products/compilers /f 60l/noncom.htm

Re:of course it's still kicking

[ttfkam]

C's libraries may not be (and may never be due to compiler pointer aliasing issues), but C++'s are. One in particular is Blitz++ [oonumerics.org].

Not to take away from Fortran. Language in general means far less to performance than an experienced programmer and good algorithms.

Don't use Fortran 90.

[Tim]

Don't use Fortran 90. It's as messy a language as C++, with the significant disadvantage that it has a much smaller user base.

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:

• POOMA [lanl.gov] - a high-performance mathematics C++ framework
• Blitz++ [oonumerics.org] - a C++ mathematics library which uses template metaprogramming to achieve FORTRAN-caliber performance.
• MTL [iu.edu] - another example of template metaprogramming.
• oonumerics.org [oonumerics.org] - a good site for information on high-performance object-oriented code.

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

High Performance Fortran

[QuantumFTL]

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 [rice.edu]. 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

FORTRAN is the common denominator.

[james_sorenson]

I work as a controls engineer at the NASA Ames Research Center. Most of the nonlinear aircraft simulations are still written in FORTRAN. FORTRAN provides very robust mathematical libraries while making it very easy to parse text files. In other words, FORTRAN is ver good at taking a text document of flight data, and crunching it into a useful simulation. The main thing is that so many compilers and languages talk to FORTRAN. I do a lot of work in Matlab and C, and both can link to my FORTRAN code. I can pull up an old simulator from the early 90s, slap on an s-function or C-wrapper, and use the code in my new code. Of course, the question is: is new FORTRAN code being generated for reasons OTHER than to be compatible with the old code, or because it is the only language the crusty engineer knows? Well, it's a toss-up. Matlab seems to be making a lot of headway, especially since it's code is very C-like and can link to old code. But, the gnu g77 compiler means I can distribute my FORTRAN work to anybody with a Unix box. Not everyone has put out the cash for Matlab. My recommendation is to learn enough FORTRAN to understand the math and logic loop functions. This will be enough to be able to read old code, and to be able to write math subroutines to be linked to more modern code. I still have to write in FORTRAN, but it's uncommon that I ever write a stand-alone FORTRAN program with an interface or anything. It is mostly text-file and math subroutines for Matlab or C.

matlab

[SETY]

I don't use fortran and here is why.......
There is Matlab www.matlab.com or the GPL version www.octave.org
Matlab doesn't give arcane error messages. Matlab has piles of built in functions for every basic math thing you could want. Matlab has many toolboxe's etc etc. Almost every university has a Matlab license and companies can afford a license.

Now the reason I am so pro-Matlab is it makes me much more productive for the simulations and experiments I run. Matlab is slower than raw compiled code (c,fortran,etc), but the productivity gains more than make up for it. If you are writing on fortran simulation that is going to run for a year on a super-computer don't use matlab. If you are writing many smaller simulations and ones that can use Matlabs tool-boxes than give it a shot.

When Matlab is slow you can always write a bit of c or fortran code and put it in with the Matlab. I've done this for a few long simulations. Also have Matlab and Labview (www.ni.com) integrated is fantastic.

Re:Yes

[Chundra]

"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.)

Ratfor at least makes it look better

[Mr Slushy]

Fortran is truly ugly, if you need to write fortran, at least do it an ratfor (Rational Fortran) described by Kernigan and Plauger in Structured Programming [amazon.com].

Ratfor adds "normal" structured programming constructs to fortran to make it readable by somebody less than 40 years old.

You write code that looks like:
for(i=1;i=100;i=i+1) {
fortran code here
}

Ratfor generates:
23002 if(.not.(i.le.100))goto 23004
fortran code here
goto 23002
23004 continue

I dont know about Linux, but ratfor is included in the FreeBSD ports.

Re:Yes

[prefect42]

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

Re:Use Fortran 90

[L0C0loco]

Here at NASA we still use fortran (F90) for our processing of satellite remote sensing data. For brute strength and optimized speed it is hard to beat. F90 makes the code easier to work with. I like to use the AbSoft F90 compiler on my linux cluster. There are only a few differences from the DEC (HP - Compaq - whatever) fortran for thier Unix and Digital Fortran for Windoze. Using some good F90 rules adherance tools to keep you from including propriatary extensions smooths the process of assuring portable code.

If you need to develop number crunching code that has a limited lifetime (disposable code) you might consider RSI's Interactive Data Language. This IDL is wonderful for developing code fast and is very powerful with its built-in graphics. It is also vector/matrix oriented and few loops are really necessary once you get used to the language. Bad part about IDL is the cost unless you can qualify for the student version ($75 last time I checked). Best part is that is comes with an extensive library of high level functions.
Check it out at http://www.rsinc.com/ .

Enjoy! Z

Why lisp of course!

[Anonymous Coward]

I'll get flamed for this but a nice choice, particularly if you want recursive computing, is Lisp. Lisp was not really designed for heavy computational use but it did find its niche in AI which is heavily mathematical in its algorithms. There is a lot of numerical library code floating around out there though you will find none at netlib. clmath is a nice math library that can be found here and there out there. Lisp is slow you say? BS. It is fast for development, fast for testing/debugging, and yes...it is fast to execute. Lisp can be both interpreted and compiled. Interpreted means fast testing. Compiled means fast execution. One implementation of lisp (cmucl) is actually faster than C or fortran in many instances. Personally, I use clisp but that is because it compiles on OS X out of the box for the most part. Well, that's my advice. It's nearly as old as fortran but still a great great language.

problems with loops?

[spongebobsquarepants]

I hate to sound trollish, but Python seems to handle loops quite well, and I find them intuitively easier to implement than in C/C++. The next time the author uses Numeric Python maybe he should give for or while a try. Plus there are other modules such as sci.py and scientific python that offer other tools, and Python integrates well with R, gnuplot, GRASS, and other computational tools. And I find C++ to be pretty zippy speed-wise.

Re:It's still kicking...

[coats]

Wrong about the GNU compiler.

As a matter of fact, Craig Burley (original author of "g77") had quite a fight with RMS over optimizations that "gcc" did not provide but that are necessary for performance in a language where multi-dimensional arrays are first-class citizens.

There are still a couple of "compilers" that translate into C (Gnu "fort" which is basically both obsolete and dead from a development point of view, and NAG "f90" that is free and is OK if you are only doing development work that doesn't involve real number crunching.

Neither is used for serious computational work; having to live within the C aliasing rules doesn't permit the optimizations necessary for high performance computing problems.

Re:of course it's still kicking

[jaoswald]

There are some fundamental weaknesses in the C language that make it less-than-optimal for writing numerical codes.

1) C arrays are nothing more than pointers in drag. "Aliasing" of multiple pointers pointing into the same region of memory can cause optimizations to introduce bugs. Because all array accesses are done as if by pointer arithmetic, it is hard to deal with multi-dimensional arrays where more than one dimension can vary (think rectangular MxN matrices). There is a bias in the language toward manual pointer movement (*p++, etc.) to efficiently stride through arrays.

2) C always "wants" to compute with doubles. (E.g. the usual trig libraries all return doubles, and the default function call rules cast float arguments to doubles.) Serious number crunching code may want to use single precision floats to conserve memory and, more importantly these days, cache and memory bandwidth.

3) No built-in exponentiation operator. (Important so that the compiler can optimize small integer powers as combinations of multiplications.) No built-in, transparent complex number support. E.g. trig functions with complex arguments.

Re:NOAA

[Jandar0]

Well, I can't speak for other agencies, but here at NASA Glenn Fortran is very much alive. A huge amount of the thermodynamic cycle/turbomachinery analysis that gets done around here is done using legacy Fortran code. Though they are no longer developing new codes in Fortran (at least in my office), it still lives. Rather than rewriting Fortran code, the effort (mine anyways) currently goes into writing generic GUIs for Windows to interface with those programs.

Re:Dijkstra

[Chundra]

Yeah I don't think it's a troll as it seems to be coming from reliable sources. Apparently his family sent an email to the faculty at cs.utexas.edu which has been forwarded around. I would imagine it would show up in the news within a day. Here's a link to the email [develooper.com], on the perl5-porters list.

Re:It's still kicking...

[astroboy]

I don't think there is anything in the above post which is correct.

The poster says:

I believe that the GNU and at least a few commercial fortran compilers translate the code to C before it compiles.

This isn't true, and I don't think has ever been true. Below is a quote from a g77 page [std.com]:

The g77 compiler is a combination of a front end that translates Fortran source programs and a back end that uses the results of the translation to make an object or executable file that performs the actions specified by the source programs when run. The back end is the same back end used by GNU C, C++, and Objective-C, which have their own front ends to translate their respective languages. Other front ends for Pascal and ADA are available or in progress.

(Note: g77 does not translate Fortran to C code at any point. It is a native portable compiler, just like gcc. They share the same back end.)

No commercial compiler I'm aware of does anything similar, either. Obviously, one should be wary of taking language advice from someone who is this ill-informed about compilers.

As for unrelated bugs, this can be an issue. If all one wants to do is a fourier transform, or a singular-value decomposition, or something similar, on some data, it's clearly ridiculous to have to learn the C++ STL, or similar libraries in other languages, to just mess with some matricies. FORTRAN, for all its problems, Will Just Work as long as you're doing something simple.

On the other hand, if you're just doing some small stuff and you don't want to deal with more complicated languages, the best bet is probably to use Matlab/IDL/Maple/Mathematica and not worry about computer programming at all. Even if you're planning on doing big calculations at this point, prototyping your algorithm and methods in these interpreted special-purpose tools can be a very good way to get your code up and running.

Re:Try Common Lisp

[alispguru]

The problem with using CL for heavy computing tasks is that Lisp is a linklist-based language.

Just curious, does all your knowledge about programming languages date from 1975, or just your prejudices about Lisp? Lisp has had arrays since about then, those arrays have the same O(1) access time as anyone else's arrays, and the performance of code using them is tuneable to FORTRAN speed or better. Whoever taught your "survey of programming languages" course did you a real disservice - maybe you should get them brought up on educational malpractice charges.

That said, FORTRAN can probabaly outrun Lisp on supercomputers, because of the effort put into parallel and vector optimizations on those platforms. I love Lisp, it's my preferred hacking environment, but I wouldn't propose it as the language of choice for big numerical applications unless there was a chance that hairy data structures might improve performance.

Try O'Caml

[Tom7]

Try O'Caml (caml.inria.fr [inria.fr]); it's a modern language that's compiled very efficiently (independent benchmarks [bagley.org]) and is suitable for heavy crunching. O'Caml has lots of features that you won't find in many languages, like algebraic data types, higher order functions, etc., but is intended for real general purpose programming. Most importantly, it's type-safe (statically) so you probably won't spend as much time tracking down bugs unrelated to the problem at hand. (That has certainly been my experience with SML, a language from the same family.)

hear hear for portability

[jjtime4sko]

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.

Extra ints on unformatted writes

[TFloore]

Your issue with extra ints on unformatted writes of Fortran file io... I've worked on Fortran development on 2 platforms:
1) DEC/Compaq Alphas running OpenVMS with DEC compilers
2) Windows NT4/2K with MS Powerstation v4 and Compaq Visual Fortran v6 compilers.

The DEC compilers on OpenVMS did *not* do those extra ints on unformatted file io. My C code to read the output file worked with no extra steps, and could read data structures with few problems. The MS/Compaq compilers *did* write extra ints on the Windows platform. Drove me buggy when I was trying to port some software from VMS to Windows. (Don't ask why, I was ordered to do it.)

Incidentally, the MS Powerstation v4 compiler wrote a 16-bit int before and after, and the Compaq Visual Fortran v6 compiler wrote a 32-bit int before and after. That change also drove me nutty. This had some extra issues... an array declared as
integer(4) MYVAR(1000)
was *larger* than the 16-bit int could specify... so the compiler broke it up into 128-byte chunks. Yes, a 4000-byte array was written as a series of 31 128-byte chunks (each with its own leading and trailing 16-bit ints), followed by a 32-byte chunk with its own leading and trailing 16-bit ints. Making C code to read this mess hurt my brain. At least switching to the Compaq v6 compiler took that issue away.

I didn't look up the Fortran language spec to see which one was actually complying with the spec. Having seen all three methods, I decided none were correct.

Incidentally, when doing unformatted writes of structures where one language is writing, and another language is reading the file... Make sure both compilers are using the same memory/data alignment rules. My Fortran compiler was doing align=byte, and my C compiler was doing align=word, and my structures with some logical*1 and integer*2 variables were messing up my read routines.

Ahh... the dangers and joys of multi-language development projects.

Design and Structure

[Morris Schneiderman]

Fortran does not force you to write spaghetti code, any more than c forces you to generate buffer overflows or perl forces you to write unreadable code.

Design and structure your application.

If you are used to objects and methods, just use subroutine modules and entry points to the same effect.

Fortran was where I learned to use multiple entry points into one sequential file for recursive processing.

Re:Matlab and Octave

[Nyh]

I agree. Especially for research Matlab is a very powerful tool (in particular with the special purpose toolboxes, Simulink is great!). You will have to think in matrix and vetors to get the speed. I am regularly called by colleagues to fix speed problems with Mathlab applications. Usually it is a for loop that could be vectorised (mostly by the use of boolean array's).

Why is Matlab so fast? Well, it's nothing more as an easy frontend for the Fortran libraries. That's where the speed is: FORTRAN.

Cu, Hans

Re:Dijkstra

[VP]

UT-Austin has an obituary [utexas.edu].

Pick'n'mix?

[Anonymous Coward]

I do use Fortran (F95). It runs beautifully both on my Linux desktop and on a remote Alpha cluster on True64. It also runs fine in the Soliaris and SGI workstations. The beauty of F95 is not that it is quite portable, but it is _easy_ You can use loads of time saving constructs which are a pain to deal with in C (I also do C for some other things mind you). If you use Windows, you get some pretty good debuggers (the ones for Linux are quite ugly, and since gcc does not yet support F95, gdb does not particularly care for it).

The thing is that if you tye F9x, you'll find writing the code easy. Learning the language is a no-brainer. You can then interface the numerical stuff with things such as SciPy [scipy.org] to display it and so on.

Re:Yes

[the eric conspiracy]

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.

Re:Will Python take over FORTRAN's niche?

[fxj]

Eventually it will. Look at www.scipy.org. They have a module called weave. With that module you can mix C-code into Python-code. The C-code is compiled when you run the program the first time and then you have a fast module.
There are also some modules which allow the linking of FORTRAN subroutines into Python code.

Re:Don't use Fortran 90.

[FullyIonized]

I can't believe the amount of crap being posted here, and this is fairly typical.

a) lack of dynamic memory allocation --- plain shit, nothing you can do about
You obviously don't know a thing about f90. Dynamic memory allocation is the first thing everyone converting an f77 code uses. Yes f77 is dated. Go pick up the f90 book by Cooper-Redwine and read the first chapter. Really, f90 is fairly clean.

b) everything is passed by reference - no recursion whatsoever
Inconvenient, but it makes for much easier optimization. For recursion, there are tricks in f90 now that allow you to overcome most of the obstacles.

The compilers are unbeliveably crash and bad. And I've tried both Sun and SGI f95 compilers... Sucessfully segfaulted them both within a few days of using them... Funnily enough NAG f95 compiler for linux seems to be quite stable.
I agree that Sun's f90 compilers are crap (although there f77 compilers are excellent), but SGI's is quite good. I use every advanced feature of F90 possible (derived types, pointers, allocatable arrays, operator overloading, etc.), and SGI's works quite well.

c) Surprisingly hard to interoperate with f77 or C, becaused modules get funnly pre/suffixes all over the place...
I've never had problems with f77 but I agree with about C. A bigger problem with f90 is that the array structure is compiler dependent. This was done to allow the compiler writers more flexibility in optimizing their code, especially for parallelization issues, but given the way high performance computing is moving (in the U.S. anyway), it is a pain.

If you want to use f90 on Linux, I highly recommend the Lahey-Fujitsu compiler [lahey.com]. This produces nice fast code with good error checking. They seem to focus more on Windows than Linux which I dislike, but it is still a solid product.
Also quite good is Portrand Group [pgroup.com]

Here is some recommended links from them that all of the "Fortran sucks" crowd should read: prentice [lahey.com]

In the U.S., the HPC community is clearly moving towards using C/C++ especially for the libraries (such as POOMA, Blitz,... that the parent poster mentioned). I've seen codes that have been POOMAized and they've run much slower than the original f90 versions. The POOMA guys talk about the fact that they will get their libraries further optimized, but it still remains to be seen. I saw a talk by the BLITZ people on how they are TRYING to get C++ as fast as C, which makes me think they should just use f90. My big complaint with these library writers is that they typically work with relatively simple problems -e.g., Poisson's equation- and then think that it will work for everything. I have yet to see a fluid code that uses these libraries and really fly.

As scientific problems become harder, the associated numerical algorithms become harder, and the codes more sophisticated and flexible. So agree that f77 is inadequate for any modern, real code, but that is hardly news. While the U.S. HPC community seems to be focussing on trying to get C/C++ up to snuff, it seems that Europe and Japan are pushing f90 or high performance fortran. I personally think we (the U.S.) are heading down the wrong path.

The basic reason why I use F90 is:
I'm a physicist, not a computer scientist. Yes, I agree that you can have fast code with C, but it is much harder.

25 year old language-wrong

[markmoss]

"25 year old language." No it's a 45 year old language, more or less. It was created in the 1950's, and had major revisions in 1964, 1977, and 1990. I'm personally familiar only with before & after '77 - this was a very big revision. The only "structured" control statement in FORTRAN 64 was the DO loop, a crude precursor to for loops; the end of the loop, IIRC, was marked by a line number, and it would execute the loop once even if the parameter values indicated it should execute 0 times. All IF statements, if evaluated true, did a GOTO, and the target was a line number, not even a label. And I found the FORMAT statement (roughly equivalent to printf) to always be a big pain, but there was no other way to print anything at all. But it was possible to write big programs in it, and the other choices of the era - COBOL, assembly, and various toy languages written by ivory tower types as demos - were often even less atractive. IBM even wrote accounting programs in it (using a hammer to drive screws because someone else invented the screwdriver, I mean COBOL), until they developed PL/1, which looked sort of like FORTRAN with certain critical ideas out of COBOL added whether or not they fit in...

FORTAN 77 had control structures like IF-THEN-ELSE, WHILE, etc., so you didn't have to write GOTO line number. It smoothed various other issues out, but to make it backwards compatible it kept much of the peculiar look of F-64: all caps, lines actually starting in column seven to leave room for up to five digit line numbers and a continuation mark in column six, I think even the reservation of columns 72-80 for sequence numbers so you could have a card sorter straighten out a dropped deck (not that anyone I knew ever used this feature - it made it kind of difficult to swap the cards around for debugging.)

Anyway, FORTRAN was primarily designed for number crunching, and AFAIK it still compiles the fastest straight number crunching code. Part of this is due to the many "advanced" features that hadn't been invented in 195x when it was first written. For instance, functions and subroutines have their own name spaces (like most languages since, except the first releases of BASIC), but the storage is static by default. So it doesn't spend time creating and destroying local variables on the stack, but OTOH you tend to use more RAM and recursive code was out of the question at least until F-77. There are (or were) no data structures (aka records). There are no pointers - you must use arrays anywhere a C programmer would use pointers. This vast loss of flexibility has the payoff that for the general run of numeric array operations, the compiler can tell what you are trying to accomplish and optimize it better than C compilers can, and even use parallel processors where available.

Still, IMHO, programming in FORTRAN sucks once you learn real progrsamming. But it is easier for mathematicians/engineers/physical scientists to use FORTRAN's arrays than C's pointers and structures, and the compiled code really zips.

Re:Yes

[The Grey Mouser]

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.

This may be changing soon. Check out the Perl Data Language [perl.org], which is designed to allow rapid calculations on large matrices using Perl syntax (and, of course, allowing use of Perl's text manipulation facilities directly). I don't imagine it's as fast as Fortran, most especially if you're using HPF or the like, but it's fast enough for a large array of applications. I'm an astronomer and use it fairly regularly for image analysis, statistical and visualisation tasks. Not yet as mature as IDL, but that seems to be where it's headed.

Cheers,

Michael

Numerical Recipes considered harmful

[jaoswald]

Sure, the authors NR took on a big task (I wouldn't call it mammoth, because they only skim over things like PDEs), but they weren't up to it.

The authors are scientists, not specialists in numerical computing. The appearance of "complete" does not equal accurate or correct. Writing robust and accurate numerical codes is difficult work, and there are journals dedicated to the topic.

Even their code for special functions is pretty lousy, often just taken from Abramowitz & Stegun, which is a source from the 1950s!!!

I'll freely admit that Netlib is not uniformly good; often, you have to find the most up-to-date solution to your particular problem from among the 3 or 4 solutions you find there. Also "old" does not mean "incorrect," or "untested," although it often does mean "probably inferior to some later work."

Real production-quality matrix codes, for instance, are not easy-to-read like NR. They are total mazes of special cases and tests and branches, but all of those things were put in for very good reasons, and the stuff that survives in high-quality libraries has been throughly tested and peer-reviewed. Don't expect to read a few pages of chatty prose and a couple pages of Fortran and feel totally informed. Expect it to be a black box that you can use with confidence, but inside is basically incomprehensible without careful study.

NR is a danger because it is not as good as readers think, and because it causes readers to not look any further for better solutions to their problems.

Re:Numerical Recipes considered harmful

[jaoswald]

A nice guide to some other sources of mathematical software is NIST's GAMS [nist.gov] for Guide to Available Mathematical Software.

Re:Good Fortran 77/95 Compilers?

[Anonymous Coward]

I found ifc produced faster code, typically 2x my g77 code, all on fortran 77 code. Not all optimizations work reliably for me, and some core dump. Try turning some off. Most of the speed boost for me is prefetch optimization, in my case. I also have Lahey's fortran express, which at US$250 is the cheapest commercial fortran available for linux. I bought the one before they added prefetch. g77 is the slowest out of all the above. It is also slower than f2c+gcc in my case. But coding for f2c is a pita because it's stricter than g77.

There is basically no free lunch with regard to f95, well except ifc. There is a project called g95 but it's nowhere near done.

Re:FORTRAN lives

[dvdeug]

I never ever claimed using floating point was the best idea, merely that it wasn't an inherently bad idea.

But it is an inherently bad idea. You're better off using strings, for crying out loud. You don't need the sin, sqrt, 1E-100 stuff that floating point offers you. You do need exactness to the cent, no matter how large the numbers are - something floating point doesn't offer you.

Depending on the processor and library, there can be distinct advantages to using floating point, like overflow and underflow exceptions, support for infinities and not-a-number values, and so on.

Which are worthless. You don't want infinity or not-a-number - you want it to raise an exception where you screwed up, which integer types in better languages do. You don't want an underflow exception - you want it silently round to zero. And you can get overflow exceptions on integers just as easy as on floats.

Re:Will Python take over FORTRAN's niche?

[sandgroper]

Lots of things to like about Python, but NumPy [numpy.org] is one of the better ones, IMHO. There is a largish and growing community of numerical jocks coalescing around around Python in scientific computation. NumPy makes Python into an "array language" (like Matlab, S-Plus/R, APL, etc. etc.) where the crunching is heavily optimized C code. Links to LAPACK et al., and Fortran wrappers exist in f2py and PyFort, for that old still-running-after-all-these-years code.

(Just another enthusiast, dabbling in the religious-war du jour. Flamage to /dev/null ;-)

CERNLIB

[bmfs]

Fortran is still alive and well in the high energy physics (HEP) community... though it is fading away slowly (not as slowly as some people would like though). Up until very recently, FORTRAN was *THE* language for data analysis but is slowly being replaced by C++ in newer experiments such as BaBar [stanford.edu] at SLAC and is replacing FORTRAN for data analysis at a few older experiments such as H1 [www-h1.desy.de] at DESY. The reason why FORTRAN is fading away so slowly is mainly because of CERNLIB [www.cern.ch] which is a FORTRAN library that contains many useful functions (random numbers, matrix manipulation, data fitting etc...) As most particle physicists "grew up" using CERNLIB, it will be a while yet before FORTRAN well and truly disappears (in the HEP community anyway). Also of note, CERNLIB has now been released under the GPL, so anyone can use it. Nice.

Re:Will Python take over FORTRAN's niche?

[clive_p]

For some things, yes. It has the advantage of good exception-handling mechanisms, which won't be in Fortran until F2002 (and then not as good as Python's). And for high-performance applications, where you want to run on parallel hardware, it's not clear that Python can compete with a fully-compiled language.

But I'm astonished at the range of mis-information on earlier replies in this thread. Most seem to think that Fortran means Fortran77, though just a few mention Fortran90. Most users of the language that I know have switched to Fortran95. It has just about everything C++ has, and more in a few ways: for example in Fortran you can define your own operators, and overload them. In C++ you can only overload an existing operator symbol, which leaves you with a rather small choice. Suppose you want to implement a "like" operator for string matching along the lines of that in SQL: you can define .like. to do it in Fortran, what obscure symbol are you going to choose in C++? Fortran95 isn't fully compatible with object-oriented programming, but for scientific applications that's often irrelevant.