lamaster@ames.arpa (Hugh LaMaster) (03/30/88)
In article <46500011@uxe.cso.uiuc.edu> kelly@uxe.cso.uiuc.edu writes: >I see a lot of people claiming that fortran is a wonderful number-crunching >language. In my experience, even if this assertion has basis in fact, it is >irrelevant to your average engineering (including myself) or scientist >programmer. A well designed compiler will make a difference of about a >factor of two in how fast a code runs. This difference between a so called >good/bad programming language would not be more than 20%. Well, I don't know anybody who claims Fortran is "wonderful" - just better than the alternatives. Why? 1) Vectorizing compilers that can, in some cases, deliver performance on a vector machine (Cray, Cyber-205/ETA, etc.) of 50% of peak performance on a well designed code. That might be 100-200 MFLOPS, compared with 10 MFLOPS for a scalar version on the same machine. The payoff is much greater than the factor of two cited above. 2) Fortran is modular. Fortran subroutines are modules, and this puts Fortran ahead of any language (e.g. Pascal) which only has "procedures". Yes, both would be better. Unfortunately, I haven't seen any vectorizing Modula-2 compilers for the Cray or CDC machines. Convex does sport a vectorizing C compiler, however. 3) Fortran is not a bad programming language, even for systems programming. Fortran has been used as the basis for a number of system implementations. Now C bigots will note that C has modules and internal procedures, and, yes, it does have advantages as a system implementation languages. But, for a Fortran replacement it is hopeless. The syntax is confusing and more error prone than Fortran, but even worse, because C doesn't have dynamic array dimensioning you can't use it for separately compiled libraries like Linpack. > The fact is your average engineering (including myself) or scientist >programmer hasn't a clue how to write good fast code. And it is almost >certain that any reasonably large code we write, can be made run at least >2 times faster by changing how it is coded. It is also true that for >99 percent of the code that we write, it doesn't matter how fast it runs, Again, the payoff on a vector machine can be much more than a factor of two. True, it doesn't matter how fast most code runs. But it does matter how fast certain very important (to you, the user) codes run. And now that vector machines are reaching the market of below $100 K machines, you will have an opportunity to see which codes will run much faster. You may be pleasantly surprised. > My chief beef against fortran is that it is non portable. >ANSI fortran is portable; but it is such a limited language, it has >to be extended to make it useable for any large scale program. >If you don't believe me, look at any large finite element code. All >of them rely on extensions to fortran 77, extensions which in most >cases are not portable. Fortran is intrinsically neither more nor less portable than C. Thousands of Fortran programmers have run Linpack programs on their machines with no modifications. And thousands of C programmers continue to write code which depends on the existence of data types of certain sizes ( e.g. 16 bit ints), on machine dependencies such as byte order, and indeed on how the compiler will allocate the fields in a structure (just like the infamous Fortran equivalence!)...
bzs@bu-cs.BU.EDU (Barry Shein) (03/30/88)
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. This has caused me to write a lot of Fortran in my day and I don't remember being severely traumatized by the experience. There's one bad reason to program in Fortran: It's the only language you know (or want to know.) This has caused me to re-write a lot of other people's brain-damaged Fortran in my time, and I do remember being severely traumatized by the experience. 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
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
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
clewis@spectrix.UUCP (Chris Lewis) (04/08/88)
In article <6630@ames.arpa> lamaster@ames.arc.nasa.gov.UUCP (Hugh LaMaster) writes: Much as I hate FORTRAN, I will admit it has its uses. Particularly in number crunching. Mind you I believe that the main reason that FORTRAN is used so much for number crunching and is better than most others for number crunching is simply because it's used so much for number crunching. A circular argument ;-). But consider, since there is relatively little demand for SERIOUS number crunching in any other language, no other language-developer (eg: C or whatever) bothers to tune their language for it, nor is much in the way of mathematical libraries for anything else. Similar statement: IBM PC's or clones are better for running LOTUS than a Sun ["FORTRAN" is better for "NUMBER CRUNCHING" than "C"] Of course! Lotus doesn't run on a Sun.... [The only customers of ours doing number crunching use APL!] I wouldn't normally have said anything here, but I'm a little curious about some of your statements, and I would like you to clarify them. >2) Fortran is modular. Fortran subroutines are modules, and this puts >Fortran ahead of any language (e.g. Pascal) which only has "procedures". >Yes, both would be better. Unfortunately, I haven't seen any vectorizing >Modula-2 compilers for the Cray or CDC machines. Convex does sport a >vectorizing C compiler, however. What exactly do you mean by "modular"? Separate compilation and linking? Most "serious" languages have that - C, PL/1, Assembler, COBOL and (gasp) ADA to name a few (no flames about Ada being "serious" please :-). Most useable Pascal compilers (for big "systemy" things) do too (eg: IBM Pascal/VS), though this is of course not part of Wirth Pascal. It's been a while since I did any work with FORTRAN, but I think I can do just about everything FORTRAN can do with COMMONs and EQUIVALENTs in C. Simply because a language definition doesn't refer to "modules" doesn't mean that it doesn't have them. >3) Fortran is not a bad programming language, even for systems programming. As long as you wrap RATFOR around your FORTRAN :-) Seriously, speaking as an ex PL/1 and FORTRAN jock, it's been my experience that non-structured programs are hard to maintain. So hard in fact to often be impossible to maintain. Yes, I know that C can be written as spaghetti-like as FORTRAN can, but the language-training you get (from schools, books, courses whatever) *usually* leads a person into programming in more-or-less the same mind-set as everbody else. FORTRAN is usually spaghetti. C is usually not. [But there is a University around here that teaches FORTRAN IV programming style in PL/1 and C...] (Actually, RATFOR *is* pretty good for systemy stuff.) >Fortran has been used as the basis for a number of system implementations. >Now C bigots will note that C has modules and internal procedures, and, yes, I did. >it does have advantages as a system implementation languages. But, for a >Fortran replacement it is hopeless. The syntax is confusing and more error >prone than Fortran, This is of course open to debate. You can kill yourself with the ol' while(something); do something or a = sin(1); or if (a = b) something problems in C, but there's probably just as many in FORTRAN: DO I = 1 10 call f(2) subroutine f(a) a = 4 end problem (and a horde of others) in FORTRAN too (going back into the history of FORTRAN for my examples). At least, *most* of the versions of C will behave the same way to silly syntactical mistakes. FORTRAN does not. Yes, C programmers do sometimes depend on byte order and NULL-dereference behaviour. Most of the problems with USENET-distributed software is not due problems like this. They're mostly due to operating system differences (Xenix vs. BSD vs. SV vs. DOS), not language problems. Sure, Linpack will port real nice in FORTRAN - but try writing the netnews software (or any other multi-program, system-dependent thing like a mail system like I did) in FORTRAN. Then move it from an IBM MVS Fortran-H to a DEC VMS F77 environment. Or even just Fortran-G to H. Then you'll find out about FORTRAN incompatibility! Though, you're right. I wouldn't do major number crunching in C. Probably not FORTRAN either. (perl is the ticket! ;-) >but even worse, because C doesn't have dynamic array >dimensioning you can't use it for separately compiled libraries like >Linpack. Doesn't have dynamic array dimensioning? I will admit that using dynamic bounds multi-dimensional arrays is sometimes a bit hard, but dynamic length vectors is certainly no problem (the C libraries are chock full of routines that will handle variable-length vectors - eg the str* routines). And there's lots of libraries that will handle arrays of arbitrary objects (eg: qsort). And C can dynamically allocate storage - can FORTRAN? Can FORTRAN handle arbitrary numbers of dimensions? I don't think so. C can. Can FORTRAN handle complex data structures? Eg: dyamically allocated trees, linked lists etc.? "unions" (variant records)? Nope. Most versions of FORTRAN I've used can't even handle character data types for heck's sake (I stopped using FORTRAN just as F77 came out...). Mind you, the lack of dynamic length arrays as parameters is the single most important reason why I hate Pascal (I know some dialects support them, but not all) and some PL/1 subsets (eg: DRI PL/1G for CP/M...). Actually, if you think about it, I think C is more portable than FORTRAN when you compare the number of variants of FORTRAN (Fortran II, IV, 66, WATFOR, WATFIV, 77, SWATFIV and specialized versions from specific vendors (ala FORT-G, H, FORT-VS, F4+, F77 etc. etc. etc.) and C (which boils down to: pre-K&R V6, K&R-conformant (V7 and most others), and post-K&R - very little actually changed at all. Except for Intel processors. Sigh...) FORTRAN has changed a *lot* more over the years than C has. And those *really* old FORTRAN compilers are *still* around haunting us. -- Chris Lewis, Spectrix Microsystems Inc, UUCP: {uunet!mnetor, utcsri!utzoo, lsuc, yunexus}!spectrix!clewis Phone: (416)-474-1955
walter@garth.UUCP (Walter Bays) (04/09/88)
In article <538@spectrix.UUCP> clewis@spectrix.UUCP (Chris Lewis) writes: >In article <6630@ames.arpa> lamaster@ames.arc.nasa.gov.UUCP (Hugh LaMaster) writes: > IBM PC's or clones are better for running LOTUS than a Sun >Of course! Lotus doesn't run on a Sun.... Qcalc probably runs on lots of UN*X boxes, uses the same data files, and has the same look-and-feel (direct flames to the "Apple vs. The World" topic on comp.sys.mac, please :-) But if you'd like it to run much slower on the same workstation, we, Sun, Apple, and others have 80386 (or 286) co-processors you can run Lotus on. Seriously, though, if you have ordinary sized worksheets, or don't mind getting a cup of coffee while it recalculates, generic AT's are certainly cheaper. -- ------------------------------------------------------------------------------ Any similarities between my opinions and those of the person who signs my paychecks is purely coincidental. E-Mail route: ...!pyramid!garth!walter USPS: Intergraph APD, 2400 Geng Road, Palo Alto, California 94303 Phone: (415) 852-2384 ------------------------------------------------------------------------------