danny@itm.uucp (Danny Cox) (12/07/90)
I'm posting this for Glen Clark. Please use the return path at the end of this article to reply to.... DSC. I am puzzled by the ongoing C .vs. FORTRAN holywar. The recent blizzard of exchanges left my news mailbox fuller than any other time in recent memory. I am willing to cede the fields of most business programming to C, but I fail to follow the arguments of those who contend C offers anything to the numerical analysis/ scientific communities that they can't get elsewhere. We have continued using FORTRAN in our office (to this point) because of a *decided* advantage is floating point speed. I don't mean 10 or 15%. I mean that algorithms coded in FORTRAN ran 3X, 4X and even sometime 10X faster than equivalent C code run on the same machine. This was primarily due to the heavy floating-point nature of our work, but what can you expect when many C compilers thought it would be a needless luxury to bother to include a library that included calls to the 68881? (Admittedly, these tests are a few years old). I don't take this as an indication that FORTRAN is intrinsically better (whatever that means) than C, but simply that FORTRAN compiler designers have been more concerned about floating point performance than the C_faithful who were so taken with the cleverness of what they had created, that they tilted their chairs back, stared at the wall, and mused "Wow man. Recursion. What a concept!", and left their floating-point libraries static (and useless) from 1983 to 1989. I have no religious attachement to any language. Our CPU hardware is a major part of the expense of running our business. If someone would show me where we could double our throughput by programming in COBOL, I would have someone begin recoding our man-years, of written_in_house programs in the morning. I believe Press et al said it better than I could hope to in NUMERICAL RECIPIES, so I will simply borrow a line or two: "In traditional C, float variables are automatically converted to double precision. ... The justification is, "well there's nothing wrong with a little bit of extra precision". ... One does not need much experience in scientific computing to recognize that the implicit conversion rules are, in fact, sheer madness! ... They make it impossible to write efficient numerical programs. One of the cultural barriers that separates computer scientists from "regular" scientists and engineers is a differing point of view on whether a 30% or 50% loss of speed is worth caring about. ... The practical scientist is trying to solve tomorrows problems with yesterdays computer; the computer scientist, we think, often has it the other way around." Apparently someone listened to Press, because this condition has changed within the last year. For the first time since we began comparative benchmarking of hardware/software combinations 10 years ago, C's floating-point performance is at parity on *some* platforms. For our in-house benchmark, we found that both the SPARC 1+ and the RS6000 have C floating point speed that is equivalent (within 1 or 2%) to the FORTRAN. But notice I said 'parity', not advantage. Now my question: What does C do for me in the world of numerical analysis/scientific programming that FORTRAN won't? If the advantage isn't speed of EXECUTION, then it must be speed of code DEVELOPMENT (i.e. flexibility of the language) or memory conservation. (Execution time, development time, and efficient hardware resource utilization. What else is there?) If I was writing a relational database manager, or rewriting American Airline's SABRE reservation system, I'd pick C in a New York minute as the only rational tool. But if I don't need to code a B-tree search, what can C give me I don't already have? The only comment I have seen that even began to address any tangible utility advantage (as opposed to religious conviction) was Pierre Asselin's recent comment on building "unstructured meshes". [I also agree with John Phelan's premise that the future of scientific computing is massive parallelism, therefore the focus of the FORTRAN-9X standard should be more on meeting that meritorious challenge, and less on adding more C-like features.] I don't pose the above question to be a wise guy. If someone has a valid answer, I'd really love to know. (Maybe I'm telling the world how little I know) But please, if you have an answer, put it in a form relating to what you can DO with it, not how NEAT it is: (i.e. having the form: "C has a rich library of intrinsic functions which are pipelined to make more efficient use of the floating point hardware. The polar-to-rectangular conversion function RECT(R,THETA,X,Y) provides for the simultaneous performance of the X=R*COS(THETA) and Y=R*SIN(THETA) tasks, thereby resolving the polar-form vector into its cartesian components in half the time. Therefore, many vector-intensive programs will execute in significantly less time." not: "C allows the creation of flat arrays of the data type foobar, allowing them to be cross-connected to the warp-drive engines, and isn't that cosmic?" ) I learned FORTRAN-66 on a CDC 6600, made an IBM 370 learn to hate me, and spent almost as much time using a DEC-10 in single-user mode as I spent in the Army. (Even took a side-trip to model the RF environment in downtown Chicago in ALGOL on a Burroughs 5500.) But excepting a few "close_to_the_hardware" C functions that would have been helpful when writing our own plotter drivers, I have yet to find something that I needed to do that couldn't be done straightaway in FORTRAN. Even Microsoft F-80 (FORTRAN for the 8080) under CP/M (heaven help us) allowed one (with clever use of the .AND. operator) to go grab the status byte off the UART, mask off what you want, and make your own flow control. So what's the BIG deal with C? Glen Clark Glen Clark & Associates Consulting Engineers Alpharetta, GA gatech!dscatl!opto!glen (404) 740-0178
staff@cadlab.sublink.ORG (Alex Martelli) (12/09/90)
Just a wee bit of input - I abhor holy wars as much as you do, and since I daily program in both Fortran and C, have no stake in it either way. I hope, however, that it may be useful to you and others if I present some technical considerations and observations that I have performed during my work here in CAD.LAB. I wish to emphasize that, although this matter IS part of my daily job, the thoughts I want to share with you are MY OWN, PERSONAL ideas, and must NOT be taken in any way as "opinions" or "positions" of CAD.LAB S.p.A.. My observations are all based on WORKSTATION-class machines, OS/2, VMS, and, mostly, Unix boxes. Our programs have rather precisely delimited sets of routines which perform heavy numerical computation (on the usual 20% of the code, 80% of the crunching, kind of scale); I *USED* to think that it would be CRAZY to even THINK about recoding these in anything but Fortran, until I started doing some benchmarks a few months ago with f2c. At the time I posted some numbers to this very group, astonished as I was - going through f2c made performance BETTER on some platforms, notably Sun ones! I had some correspondence after that, but nothing came of it - I did not hear anything more from those I had sent my code to, etc. I'll have to redo the benchmarks on the Sparcompiler some day. A more usual result was reasonable degradation, between 5 and 15 per cent. These were double-precision computations anyway, but then this IS most of what we have to do; if we had heavy single-precision requirements, on some boxes forcing double precision would be a heavy hit, on Sun we could use the nonstandard -fsingle switch on cc, and on others such as IBM RS6000 one would hardly notice the single vs double precision difference; a bit difficult to get reasonably general conclusions from such a varied picture. For anything BUT straight numerics, C shows incredible performance wins on our hardware. I/O, for example, is FAR simpler in C, and better adapted to what the underlying OS/2 or Unix system provides - the Fortran compiler seems to have HEAVY overhead - to cut it short, a checkpoint to disk is quite likely to take TWICE as long from Fortran as from C!!! I do NOT think this is in any way inevitable; I believe a Fortran runtime library WILL always have more overhead, but on the *few percents* level, definitely NOT 100% as I have observed; thus I must conclude that the Fortran compilers/libraries we use on these small machines are simply BADLY IMPLEMENTED, at least for I/O. Manipulation of characters is more of the same; SOME overhead is implicit in the Fortran standard (implicit fill-with-blanks, implicit runtime checks for boundaries, etc), but in practice C measures FAR better than this little things would imply - or should I say, Fortran (the compilers available to us) measures far worse. Taking all of this into account, our strategy is to move our LOW-level code more and more to C - comes out more portable (no more wondering what type is needed in an INQUIRE(), what unit of measures, bytes or longwords, must be specified in the RECL of an OPEN(), etc), more maintainable (thanks to better structure, layout, mandatory variable declaration, etc, which we could not get PORTABLY in fortran across more than a dozen platforms), and with measurably better performance. It's also easier to find people coming out of universities with good command of C than of Fortran, nowadays; a minor point, but this has to be taken into account too. This is for the kind of people we want for low-level, close-to-the-system work: graphics, algorithms, I/O, abstract datatypes, all sorts of "computer science" stuff which, of necessity, goes into a well-rounded software system. At *higher* levels Fortran stays - no real reason to redo hundreds of thousands of lines of code, unless gradually - also the people who work on the more application-oriented portions tend to be mechanical and civil engineers, and THOSE are still easier to find with some knowledge of Fortran than of C - again a minor point, but not fully to be ignored! I have ignored so far the ability, with C, to express naturally and effectively more complex structures, through pointers. I know most Fortran users will scoff at this, but take care: unless you are only working with DENSE arrays, you are already losing the "simplicity" of straight Fortran, and should benchmarks some of your application's kernels in C. Sparse matrices are better represented through arrays of pointers than array of indices into other arrays; an array of structures will have better locality (for caches and paging) than the traditional "separate, but 'parallel' arrays" one would use in Fortran; and whenever you have to "swap data around", you might be better off swapping pointers to them instead (again, swapping indices adds a level of indirectness, which makes performance worse). These apply to both high- and low- level components of applications, so why am I not "pushing" C over Fortran even more in our company? First, I'm NOT talking about orders of magnitudes improvement, and we already have a LOT of Fortran code out there; recoding for 10 or 20 percent improvement, when in any workstation family more than that is routinely offered every YEAR by manufacturer, is a rather marginal investment; C is not some "silver bullet" that will make your data structure and algorithms better by itself, you have to back it up with study and work to get THIS class of improvements! So I'd rather have our engineers think about the other engineers that will be using our codes, rather than, at least in part, becoming computer scientists. Besides, I believe even more of this sort of improvements, and others, will be available shortly from a swith to Object-Oriented software engineering techniques and languages; so I'd rather invest in THAT in a short while. -- Alex Martelli - CAD.LAB s.p.a., v. Stalingrado 45, Bologna, Italia Email: (work:) staff@cadlab.sublink.org, (home:) alex@am.sublink.org Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434; Fax: ++39 (51) 366964 (work only), Fidonet: 332/401.3 (home only).
khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) (12/18/90)
>on our hardware. I/O, for example, is FAR simpler in C, and better
This is purely an artifact of the IO library, not the Fortran model.
--
----------------------------------------------------------------
Keith H. Bierman kbierman@Eng.Sun.COM | khb@chiba.Eng.Sun.COM
SMI 2550 Garcia 12-33 | (415 336 2648)
Mountain View, CA 94043