Is GNU g77 Killing Fortran?

goombah99 asks: "I've come to believe that the existence of GNU g77 (and f2c) is holding back Fortran development. You might think that a free-ware compiler would be good for promoting the language. But it's not because the GNU flavor does not implement the de-facto standard DEC extensions to the language that give it dynamic memory allocation, pointers, and data structures. Without these Fortran 77 is indeed barbaric, but with them it is quite pleasant to work with. The problem is everyone writing new code is now afraid to use these commands in because of the desire to have their applications compilable by the teeming masses who may not want to pay $500 to $1000 dollars for a professional Fortran compiler (all of which do implement the DEC extension). F95 is being held back by the same considerations. Do you agree? Does anyone have some library extensions or pre-compilers that provide these capabilities to g77?" Are the DEC extensions so widespread and common that language survival is dependent on their inclusion, as the submitter suggests, in "every professional compiler". Assuming there aren't comparable features already available in g77, are there plans on eventually implementing similar?

Comments

Re:10 GOTO 20

[Spy Hunter]

Wow. That article is awesome. This code made my jaw drop:

const int N = 64;
Array<double,3> A(N,N,N), B(N,N,N);
Range I(1,N-2), J(1,N-2), K(1,N-2);

A(I,J,K) = (B(I,J,K) + B(I+1,J,K) + B(I-1,J,K) + B(I,J-1,K) + B(I,J+1,K) + B(I,J,K-1) + B(I,J,K+1)) / 7.0;

You can do that with C++?!? And it's super-efficient!?! The article explains that this code actually expands automatically into this loop that traverses the arrays in a convoluted manner designed specifically to improve cache-hit performance. All this complexity is hidden inside the library. Now I see what all these people have been raving about with template metaprogramming and expression templates.

Seems to me that template metaprogramming is a rather awkward way to go about these things though. Couldn't you design a language that had features specifically designed to enable this type of in-line compile-time code expansion?

Sad but (mostly) true.

[Professor D]

In my former life as a grad student in the sciences the lack of a free f90 compiler definately prevented adoption of GNU/Linux as an alternate/cheap platform. We had code that simply could not be compiled because g77 lacked features that are older than some people reading this post!

The vendor compilers however had all the f90 options, which 'forced' us to pay for the expensive developer packages instead.

At the time, the two extensions we needed (IIRC) were STRUCT and POINTER, which were on g77's to-do list. Now, the better part of a decade later, they _still_ are AFAIK.

I wonder why none of the many high-budget science projects that use open-source extensively have never properly funded g77 development?

Fortran 95.

[Bill, Shooter of Bul]

Frotran 95 includes the For each programming construct that allows the compiler to perform each action in the loop on a different proccessor. And thats just darn cool.

Re:10 GOTO 20

[Spy Hunter]

Why do you need to see the machine code? Doesn't the performance of the compiled code speak for itself? He benchmarks the code against hand-optimized Fortran code for the same task, and it beats Fortran. Did you even read the link?

This is Depressing

[turgid]

When I was doing Physics at Uni they forced me to use FORTRAN 77 for "portability" despite the fact that I already knew C.

However, 10 years ago, FORTRAN compilers were very much more advanced in terms of optimisation for numerical work than C (e.g. the Cray compiler could do automatic vectorisation.)

I would have thought that if you had a big, expensive supercomputer, you can afford the compiler. Not buying the compiler is silly, because you'll probably end up with an order of magnitude less performance out of it with a compiler whose primary goal is portability and has been designed to work well on totally different hardware architectures.

Having said that, though, if you've got a low end box, you probably want a cheap or free compiler. Why spend $1000+ on a compiler when the box probably cost less? The low end box can probably sustain 100+MFLOPS (easily) and peak well into the GFLOPS. That's a cheap Athlon we're talking about. So you probably don't want to buy a fancy FORTRAN compiler. Why not just stick to C or even C++ nowadays? Legacy code :-(

So you have a problem. The big supercomputer you bough 5 years ago probably has a "slow" C/C++ compiler. The nice cheap box you have on your desk has arubbishy FORTRAN compiler and a reasonable C/C++ compiler.

So, you can convert all your legacy code to C and C++, you can buy a commercial FORTRAN compiler or why don't you universities cough up some time and money to give to the GNU FORTRAN people to help them improve their compiler? Or is that too radical and lefty?

what is killing fortran

[Mark Muller]

What is really killing fortran is the perception that fortran == f77. Tell someone you program
in fortran, and they immediately think of old,ugly f77.

I write code (both reasearch and commercial vibration analysis) in fortran90/95 every day - I
use modules, I use pointers, and I get great performance. A few things I also get:

1) clean, neat code that is easy to read by non-programmers.

2) Array bounds checking by the compiler - try that with C++. Array bounds checking saves me
huge amounts of time in development.

3) Compiler checking of function calls, via encapsulation of functions in modules.

4) Easy use of BLAS and LAPACK routines for real computational work.

5) The actual function definition used for the function prototype - I don't have to maintain a
separate prototype for my functions to get the advantages of prototyping!

Fortran isn't perfect (yet). It still lacks the ability to make a function part of a data
structure (ie, classes). It current i/o abilities still suck. It's ability to handle characters and
character strings is terrible. But it does have advantages other than producing fast code, and it
isn't your father's fortran77.

Re:what is killing fortran

[MagikSlinger]

1) clean, neat code that is easy to read by non-programmers.

*snort* I'll believe that when I see it.

2) Array bounds checking by the compiler - try that with C++. Array bounds checking saves me huge amounts of time in development.

I use the STL and not think about bounds ever again.

3) Compiler checking of function calls, via encapsulation of functions in modules.

Unless you're badly describing another feature, that was one of the first features of C++ and ANSI C.

4) Easy use of BLAS and LAPACK routines for real computational work.

Two words: C wrapper.

5) The actual function definition used for the function prototype - I don't have to maintain a separate prototype for my functions to get the advantages of prototyping!

Some argue that having a separate prototype prevents the implementor from arbitrarily changing the interface without warning their other team member.

Fortran isn't perfect (yet). It still lacks the ability to make a function part of a data
structure (ie, classes). It current i/o abilities still suck. It's ability to handle characters and
character strings is terrible. But it does have advantages other than producing fast code, and it
isn't your father's fortran77.

You just said the two most important capabilities of any programming environment in most problem domains (I/O and character handling) suck, so what advantages does FORTRAN have have? Native complex number support? The rest of FORTRAN's "advantages" have long since been added to every other programming language on the planet.

And as for native complex number support, I might point out with C++, you can create identical functionality with a class and operator overloading.

Re:10 GOTO 20

[Anonymous Coward]

The conclusion reached in that article is spurious. All it proves is that a faster algorithm, implemented in C++, is faster than a slower one, implemented in fortran. The fact that the fast hilbert traversal algorithm is built into his library (note, it was not a result of any of the code shown on the page -- it is hidden in the range objects and the overloading of the () operator, and the code that does it is in the library), and is not a standard feature in fortran, does not change the point that he was comparing TWO DIFFERENT ALGORITHMS.

In fact this is exactly why people still use fortran. Because in 9 times out of 10, the situation is the exact opposite: there is a heavily optimized implementation already available in a widely available fortran library, or you can write your own crappy C/C++/Java/Perl/whatever code.