rwwetmore@watmath.waterloo.edu (Ross Wetmore) (04/01/88)
In article <21064@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes: > >Ok, this is getting silly. > >There's one good reason to program in Fortran: The software subsystems >you need to attach to are written in or designed to interface to Fortran. [ ... ] Not silly ... by a long shot !!! There are a lot of Fortran packages out there whose size and complexity makes the Unix kernel look like a trivial programming exercise. While oftimes system dependent portions are coded in assembly or C, the bulk of the computational algorithms are in Fortran. Until other languages support for fast FP arithmetic and function libraries reaches the level of Fortran support, this is not likely to change, and new packages are still going to be written to use existing libraries, and code from existing programs in much the same way as C programmers steal and hack local versions of libc routines when creating a new user application. Until such hardware and software libraries are thoroughly tested and verified with several years of proven track record, no massive move to convert existing packages is liable to arise. Until some group starts to convert existing packages to non-Fortran environments, which means until there is some viable reason to do so that funding agencies and scientists whose only interaction with the programming environment is through the user interface can use to justify the expense and effort, none of this is liable to occur. >In the end it's all about getting the job done and done correctly and >efficiently. But that rarely enters into these discussions. > > -Barry Shein, Boston University Fortran currently does its job, does it reasonably well, and often more efficiently than the competition. An adamant assertion that all OS' should never be written in anything but prolog and any that aren't are neanderthal and should be scrapped, is about as sensible a comment as trying to tell computational scientists to scrap Fortran. C may have the strings capability to print the final result, but Fortran has the FP capability to compute it. One should use the appropriate tool for the appropriate application, even if this means learning a second language. Now if we can only broaden the horizons of the diehard Fortran nuts and the fanatic new-wave of Unix gurus to half the extent of Barry's, maybe some really exciting things could be achieved. Ross W. Wetmore | rwwetmore@water.NetNorth University of Waterloo | rwwetmore@math.waterloo.edu Waterloo, Ontario N2L 3G1 | {clyde, ihnp4, ubc-vision, utcsri} (519) 885-1211 ext 3491 | !watmath!rwwetmore
radford@calgary.UUCP (Radford Neal) (04/01/88)
In article <552@tuck.nott-cs.UUCP>, anw@nott-cs.UUCP writes: > While I'm on the subject, a correspondent tells me of vague memories > that Pascal and Algol also benchmarked faster than Fortran on the CDC > 7600, again with very little effect on the general population of users. > Rings a bell with me too -- anyone able to confirm or deny? Back in 74 to 78, I used a CDC 6400, which is instruction set compatible with a 7600. The FORTRAN compiler was certainly far better than the Pascal and Algol 60 compilers for numeric computations. The difference was likely even larger for th 7600, with its multiple functional units, exploited by the FORTRAN compiler more than Pascal or Algol. However... I can well beleive that most FORTRAN programs ran slower than they would have if written in Pascal. Most FORTRAN programs are not dominated by numeric computations. The FORTRAN IO system was abysmally slow, due to the need to interpret formats at run time, plus general brain damage. I find it rather amusing how scientists and engineers insist of using FORTRAN for "numeric" applications which are 90% IO, data conversion, and control, applications for which it is wholely inappropriate, *especially* if you are not a professional programmer. Radford Neal
weemba@garnet.berkeley.edu (Obnoxious Math Grad Student) (04/01/88)
In article <17946@watmath.waterloo.edu>, rwwetmore@watmath (Ross Wetmore) writes, in response to Barry Shein: > Fortran currently does its job, does it reasonably well, and often more >efficiently than the competition. > C may have the strings capability to print the final result, but Fortran >has the FP capability to compute it. One should use the appropriate tool >for the appropriate application, even if this means learning a second >language. Hear hear! (I'm surprised at you Barry--you've said many wise things when vi vs Emacs wars come up before.) I once wrote an application that used the C curses windowing package to get its results dynamically/interactively, allowing me to make simple mo- vies using script, but whose innards were actually calls to run a remote Cray job for some fantastic number crunching. So of course the outer loop was in C, and the innards were in FORTRAN. Having become an Emacs weenie in the meantime, I may very well write my next such application's outer loop in Emacs Lisp! But I don't want to learn FORTRAN 8X. I really don't. ucbvax!garnet!weemba Matthew P Wiener/Brahms Gang/Berkeley CA 94720
mcdonald@uxe.cso.uiuc.edu (04/02/88)
>However... I can well beleive that most FORTRAN programs ran slower >than they would have if written in Pascal. Most FORTRAN programs are >not dominated by numeric computations. The FORTRAN IO system was >abysmally slow, due to the need to interpret formats at run time, plus >general brain damage. I find it rather amusing how scientists and >engineers insist of using FORTRAN for "numeric" applications which are >90% IO, data conversion, and control, applications for which it is >wholely inappropriate, *especially* if you are not a professional >programmer. > Radford Neal I find this comment most curious. Disregarding Pascal for the moment, I've surveyed the Fortran programs around here (the University of Illinois Chemistry Department) twice in 15 years, and find that only a small amount of time is spent doing IO. Most, by far, is spent in either actual computation, or in a wait loop looking for user input. Only one group uses a substantial amount of IO (while diagonalizing 100000x100000 sparse matrices) and believe me, they make SURE that it is as efficient as possible! At the time of my first survey, 1975, I was the largest computer user; my main program output about 10 kbyte of data every 30 minutes of computing (on the Illiac IV). Today I do a lot of O, very little I, with most of the O going to graphics devices which are totally language-independent- everything in their drivers is in assembler. Actually the Fortran IO system is more efficient than most, as it allows direct block IO explicitly, if you use it right. In real scientific programs, no one uses formatted IO for intermediate results. I do agree that the default behaviour of the Fortran formatted IO system is unsatisfactory for interactive use --- that is its biggest problem and the reason that, for instance, C is becoming more popular. As to Pascal--- since I have never seen anyone write a scientific program in it, I can't comment directly, but looking at the standard Pascal definition, I can't see that it would be any better than Fortran: it lacks a LOT that Fortran has, so much, in fact, that it is really a toy. The only real alternative to Fortran is C, which has its own problems for scientific use: no Complex type, and problems with convenience handling multidimensional arrays; it's also harder to write a really good optimizer for C, due to aliasing (see the discussions in comp.lang.c). Doug McDonald