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

12 of 685 comments (clear)

  1. Use Fortran 90 by Lally+Singh · · Score: 5, Informative

    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!
    1. Re:Use Fortran 90 by L0C0loco · · Score: 5, Informative

      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

      --
      -- Instant Karma's gonna get you! [320848 = 2*2*2*2*11*1823]
  2. Re:NOAA by GuidoDEV · · Score: 5, Informative

    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 and here. The source code to several others is readily available as well if you're so inclined, for instance the ETA and the ARPS. 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.

  3. On languages and Fortran. by McDoobie · · Score: 5, Informative

    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

  4. Don't use Fortran 90. by Tim · · Score: 5, Informative
    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 - a high-performance mathematics C++ framework
    • Blitz++ - a C++ mathematics library which uses template metaprogramming to achieve FORTRAN-caliber performance.
    • MTL - another example of template metaprogramming.
    • 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....

    --
    Let's try not to let fact interfere with our speculation here, OK?
    1. Re:Don't use Fortran 90. by FullyIonized · · Score: 4, Informative
      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. 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

      Here is some recommended links from them that all of the "Fortran sucks" crowd should read: prentice

      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.

      --
      Sigs are bad for you.
  5. High Performance Fortran by QuantumFTL · · Score: 5, Informative

    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

  6. Re:Yes by Chundra · · Score: 5, Informative

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

  7. Re:Yes by prefect42 · · Score: 5, Informative

    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

  8. hear hear for portability by jjtime4sko · · Score: 4, Informative

    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.

  9. Re:Yes by the+eric+conspiracy · · Score: 4, Informative

    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.

  10. Re:Numerical Recipes considered harmful by jaoswald · · Score: 4, Informative

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