Slashdot Mirror
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?
20 C++ faster than Fortran
There's already a team of very capable -- and young, not ancient/retired/whatever -- programmers implementing the Fortran 9x language, which defines some really interesting constructs. The current plan is for an initial release as part of 3.5.
Fortran 2000 has a spec, but I don't know of any implementations for it.
As far as "why is it still being used at all" comments, two words for you: no aliasing. The same reason why numerical computation in Fortran continues to chew C's head off.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
Haggle over the technical merit of g77 all you want, but free software is not the same as "free-ware".
Digital Citizen
The gropu that works on the Fortran standard is J3.
The current standard is Fortran 95 which, as another poster pointed out, is currently being developed into g77. However, work is progressing nicely on Fortran 2003. From the web site above:
"Fortran 2003 is an upwardly-compatible extension of the current Fortran standard, Fortran 95, adding, among other things, support for exception handling, object-oriented programming, and improved interoperability with the C language."
I went poking around on Google and could not find an answer in 30 seconds, so you are forgiven. ;-)
I think this page on aliasing should answer most of your good question.
Add to that page the fact that if a compiler can't be sure about something, the answer is typically to copy the thing it can't be sure about into a safe location, and either copy it back somewhere after the "unsafe" thing or explicitly check it for changes.
For instance, if you're calling a function and the compiler can't know what it's going to do to the caller's registers, the compiler must painstakingly copy the registers out to main memory (well, it'll probably land in L1 cache but still it could be very expensive compared to the function itself), call the function, and copy the registers back in, whereas if the compiler can know it's a little function that only uses registers X and Y, it can only save those. If you're calling lots of little functions, this can add up.
A real example of this? If you're making a static call in C to a function, the compiler can go look at the function and do this analysis. If you're calling through a pointer, a common operation (at least, I can't stand using C without it...), it can't, because that pointer could be pointing at anything, up to and including a dynamically constructed function (if you're brave). To maintain its promises to the programmer that a function call never changes the variables in the caller (which may be located in registers), it has to protect all the registers.
Aliasing is a nasty problem because it's completely opaque to the compiler; the compiler can't see through that indirect function call to the function beyond, not even in theory. As the page mentions, other techniques are being developed that don't involve that sort of opacity by working around aliasing, and the JIT compilers take a different, more dynamic tack that in theory lets them do this analysis dynamically. (The Transmeta processors can also do some of this stuff, which is one of the ways they can speed up code when they run it a lot; they can do this more expensive analysis and dynamically optimize the code.)
Yeah... I thought the CS community at large mostly knew about this. Okay:
Fortran specifies that Thou Shalt Not Alias, so in the example on the page that you linked to, the function-calling programmer, the function-implementing programmer, and the compiler can all assume that everything refers to non-overlapping memory, and can optimize the hell out of read/write memory accesses.
When Dennis Ritchie designed C, it was a deliberate decision to not prohibit aliasing. (C's ancestor languages may have allowed aliasing as well, and DMR just decided to continue that; I don't actually know. But the question was brought up and considered; it's not an accident.)
When C was first being standardized by ANSI, a really sloppy proposal was made to add a 'noalias' keyword. It was so bad that DMR sent a public letter to the ANSI committee stating, "noalias must go; this is non-negotiable." So C89 has no way of restricting aliasing.
C++98 and C99 do, sort of. C99 added the __restrict keyword to the language. C++98 left the core language alone and defined a library type, std::valarray, that is free of aliasing by definition, opening up a number of optimization possibilities.
Valarray didn't quite work out; its design is semi-broken. Far more hopeful is using expression templates to expose more of the numerical computations to the compiler, so that more optimizations can be done on visible numbers. Check out Blitz++ at oonumerics.org for an example.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
Fortran is the language used in the communication terminals the Navy uses to send and receive data through the Milstar satellite communication network.
These devices are used in ground stations, ships, and boomers. That's a pretty major application.
Show me on the doll where his noodly appendage touched you.
Not C++ but C: f2c
Stick Men
The Intel Fortran compiler supports F90, dynamical allocation, works better than Absoft or Portland Fortran, and is free for Linux...and for all of you complaining about Fortran, do you have a job ? I know someone who ended with a very nice job just because he had mentioned "Fortran" on his resume, and had spent maybe 1 week of work on " Numerical Recipes in Fortran" and the Intel/g77 compiler.
Google passes Turing test : see my journal
Two words: multidimensional arrays.
In C, multidimensional arrays are more difficult to use than one-dimensional arrays. In Fortran, there are real multidimensional arrays that are easy to use in a general way. Yes, you can use structs and stuff in C to get around the problems, but the point is that it is *easy* in Fortran. If you really need dynamic allocation (and your compilers don't suck) you can just call malloc from F77.
The author of Blitz++ has proven, through these benchmarks, that his code, when compiled with an actual C++ compiler (gasp, horror, so inefficient!), is more efficient than Fortran at tasks in which Fortran excels. I sure don't think he needs to show any machine code to convince me. In this particular case, the C++ machine code would be much longer and more complex, in fact, since it uses a complex algorithm to traverse the arrays. Therefore, looking at the machine code would be totally missing the point.
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
Why not use gfortran ?
Well, I think it's still a bit early for production use. In its current state, it may be fine to play around with and help the developers, but I don't think it is good enough yet for real world programming.
Marcel
I fully agree that Fortran is NOT for every day programming of word processors, opertating systems, games, device drivers, and GUIs, and that there is a resistance to learning it in schools these days. However I believe the Modern Fortran Language is a better choice for most scientific and numerical programming by non-computer scientists;
/= 0.0)
,as C does, but also if the routine will change that variable. This lets the compiler know that it can multi-thread and not have to worry about locking an array against changes. In the example, the disk-write subroutine would declare the argument (A) to be immutable. Again the multi-threading is hidden from the user, no need for laborious "synchronize" mutex statements. It also allows for the concept of conditionally-mutable data.
Consider the following....
perhaps the biggest complaint in the cutting edge of computing is that no one knows how to effectively program for multi-processors for ad-hoc, scientific programming. Duals are already ubiquitous at the low end consumer market, and of course IBM, sun and sgi have long made units with dozens of cores. Its only going to increase. Likewise Intels now all have hyperthreading to increase the efficiency of their instruction pipeline.
An unsolved problem is how to write custom code for end use in multi-processors that does not depend on knowing the architecture or require special libraries or the very complicated bussiness of writing thread-safe code (locking variables etc...). Shared Memory management is a major bottleneck: How to distribute arrays to multi-processors and keep caches up-to-date after writes is a huge problem.
For parallel processing fortran 95 boasts many language level features that give ANY code implicit parallelism and implicit multi-threading and implicit distribution of memory WITHOUT the programmer cognizantly invoking multiple threads or having to use special libraries or overloaded commands.
An example of this is the FORALL and WHERE statements that replace the usual "for" and "if" in C.
FORALL (I = 1:5)
WHERE (A(I,:)
A(I,:) = log(A(i,:))
ENDWHERE
call some_slow_disk_write(A(I,:))
END FORALL
the FORALL runs the loop with the variable "i" over the range 1 to 5 but in any order not just 1,2,3,4,5 and also of course can be done in parallel if the compiler or OS, not the programmer, sees the opportunity on the run-time platform. The statement is a clue from the programmer to the compiler not to worry about loop-order dependencies. Moreover the compiler now knows it can fork off the slow-disk-write operation so it does not halt the loop on each interation.
The WHERE is like an "if" but tells the compiler to map the if operation over the array in parallel. What this means is that you can place conditional test inside of loops and the compiler knows how to factor the conditional out of the loop in a parallel and non-dependent manner.
Moreover, since the WHERE and FORALL tell the compiler that the there are no memory dependent interactions it must worry about. thus it can simply distibute just minimal and orthogonal pieces of the A array to different processors, without having to do maintain concurrency between the array segments used by different processcors, thus elminating shared memory bottlenecks.
Another parallelism feature is that the F95 header declaration not only declare the "type" of variable
Other rather nice virutes of FORTRAN is that it uses references rather than pointers (like java), so less ways to spend your time debugging.
The sad reason the world does not know about these wonderful features, or repeats the myths about the fortran language missing features is due to GNU releasing a non DEC-compatible language. I think the world would be better off if g77 did not exist. By doing so they undercut the affordable fortran compiler market and forced everyone to write for the lowest common denominator to have their code
Some drink at the fountain of knowledge. Others just gargle.
Numerical recipies said it best. Scientist solve next years problems on last years computer. Computer "scientists" solve last years computer problem on next years computer. You appear to have no clue that all your statements about will slow the code and the memory management ot a crawl.
1) clean, neat code that is easy to read by non-programmers.
>*snort* I'll believe that when I see it.
double snort. Did you know its not possible to make a typo type syntax error in fortran 77 that will compile? hard to believe I know but its true. ( You cant misplace a plus sign or comma or leave off a [] and have it compile.
when I try to debug faulty c-code and see something like
i = --j
I have to try to figure out if they could have meant to write
i = -j or i = j-- or i = --j
yuck.
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.
SLOOOOW. And unparallelizable. and it kills multi-processing dead. and loss of control over memory management. loss of memory mapped sub arrays, strides etc.... Sure you can do strides in c++ but now they are function calls not direct-to-memory. In fortran you can often pull contionals outside of loops using the WHERE syntax. Its much better to have a good syntax in the language than make up for it with a bunch of function calls and object instantiation. e.g. both languages can write
A = B*C where A,B and C are matricies but C has to do it with objects and overloads. fortran does not. which do you think is going to be faster.
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.
So fortran steals a good thing from C and you complain? In fact fortran 95 implemented headers much better than the asanine way C does it. If fortran you can declare the headers for the called functions right in the code that will call the function so fewere prototype mismatches occur. and fortran also lets you specify the not just the type defs but also whether the subroutine will change the arguments or not (without having to pass by value or declate things final). Thus the compiler can know for example if a cache will need to be written back or how to share memeory between two processors. or if it can multi-thread past a subroutine call.
4) Easy use of BLAS and LAPACK routines for real computational work.
>Two words: C wrapper.
whoopee. I can say it in reverse: take the STL and put a fortran wrapper on it. now fortran has the STL.
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.
well fortran90 can either derive its prototype or you can specify them your call. its nice to have it both ways and not pay any price.
>Fortran isn't perfect (yet). It still lacks the ability to make a function part of a data
structure (ie, classes).
not really true. You can program in an object oriented fashion if you wish. but its more like perl-objects where the data is explicitly passed rahter than C where its hidden from the user.
in C++ you would say
myobject->hash_get(key)
in fortran you would say:
hash_get(myObjectStructure, key)
is there any important difference?
It current i/o abilities still suck. It's ability to handle characters and
character strings is terrible.
Well fortran90 does have nice string handling. and of course it lacks the C string terminator problems that account for so many buffer overflow issues. But I w
Some drink at the fountain of knowledge. Others just gargle.