Xref: utzoo comp.lang.fortran:4153 comp.lang.c:34266 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!sci.ccny.cuny.edu!phri!cmcl2!kramden.acf.nyu.edu!brnstnd From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein) Newsgroups: comp.lang.fortran,comp.lang.c Subject: Re: Fortran vs. C for numerical work (SUMMARY) Message-ID: <9458:Nov2721:51:5590@kramden.acf.nyu.edu> Date: 27 Nov 90 21:51:55 GMT References: <1990Nov21.220816.15220@rice.edu> <2173@tuvie> Organization: IR Lines: 107 Summary: Each of the disadvantages that Brian mentions for C as compared to Fortran should disappear within a few years without any further standardization. In the same areas, Fortran has many big disadvantages, each of which will be quite difficult to fix. In article bglenden@mandrill.cv.nrao.edu (Brian Glendenning) writes: > 1. Pointer aliasing. If you allow interprocedural analysis, the compiler can detect the ``aliasing signature'' of every call to a function, and generate separate versions that run as fast as possible for each signature. If, in fact, no aliasing is present, the compiler will generate just one version. So this is only a temporary disadvantage---when C compilers get smarter, they'll be able to generate just as fast code as Fortran (at the expense of somewhat slower compilation). In my experience, pointer aliasing in C is an advantage. I don't have to, e.g., write two versions of a large-number addition routine, one where the output overlaps the input and one where it doesn't. The price I pay for this is that most current compilers only generate the slower version (so in speed-critical applications I'm now forced to write two versions, one using some unportable assertion like ``noalias''). But a smarter compiler could do the job. The extra compile time is worth the programming time saved. This disadvantage of Fortran (that it doesn't allow aliasing at all) is much more difficult to fix. Even if a compiler appears that allows aliasing, code taking advantage of it won't be portable. So nobody'll bother. Part of the flame war in comp.lang.misc is over my contention that the compiler can do a respectable job of aliasing detection *without* interprocedural analysis---by generating a small, static set of signatures and working with those. But this is a side issue. > 2. C has no conformant arrays, i.e. you can't do the equivalent of: [ ... ] > In C you either have to do your own indexing *(a + j*m +i) or have > pointers to pointers *(*(a + i) + j). I agree that this is a problem. However, the double-pointer solution usually allows faster access than the standard method of storing arrays, doesn't waste much memory, allows more flexibility, gets around the memory management problems of some small architectures, and lets you use a[i][j] for *(*(a + i) + j), all within current C. It is extremely difficult to do this efficiently in Fortran, and it will continue to be. In some applications, though, dynamically sized flat multidimensional arrays may be better than multiple-pointer arrays. At least one very popular current compiler, namely gcc, lets you declare arrays the way you want. > 3. In fortran functions like sin, cos, ** are intrinsic. Fortran and ANSI C treat intrinsics the same way. > 4. Fortran has complex variables. Given the number of inlining compilers, this is at most an issue of what syntax you prefer. Many programmers don't like infix notation for operations that are generally simulated by the compiler rather than executed directly by the machine. For them, Fortran is at a disadvantage here. This is hardly a major issue, though. > 5. There are many numerical libraries written for Fortran. Which, given f2c, is no longer an issue. > 6. C can ignore the placement of parentheses ANSI clamps down on this. > 7. "C has too many system dependent aspects (e.g. round up or down when > dividing negative integers)." Huh? Fortran has system-dependent aspects too. Fortran does not have standard I/O powerful enough to, e.g., respectably checkpoint a computation. This is a huge disadvantage. It will not be fixed except by further standardization. > 8. C does everything in double. ANSI fixes this cleanly. > (*) I realize that it is not that hard to write portable C. I think > it's fair to say that it's easier to write portable Fortran for > numeric work, though. In my experience with numerical code, it has been extremely easy to write portable C. Numerical programs use input and output too. > When and if we have fortran9? available the story may be different > (but it's getting pretty late in the day for F9x to come riding over > the horizon to save us). Fortran 8X: the teenage mutant ninja offspring of Modula-2 and Ada. A few years ago I was in a room full of Fortran programmers listening to a presentation about the language. They hated almost everything about it. Now it's Fortran 9X and still somewhere over the horizon. C is a de facto standard. ANSI C is a standard. So is Fortran 77. The new Fortran is not. C, ANSI C, and Fortran 77 are the language variants that will be widely used over the next several years, and those are the languages we should be comparing. ---Dan