Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!sdd.hp.com!wuarchive!psuvax1!rutgers!otello!gear!cadlab!staff From: staff@cadlab.sublink.ORG (Alex Martelli) Newsgroups: comp.lang.fortran Subject: Re: C/FORTRAN holywar Message-ID: <548@cadlab.sublink.ORG> Date: 8 Dec 90 21:08:11 GMT References: <1202902230@opto> Organization: CAD.LAB, Bologna, Italia Lines: 100 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).