Xref: utzoo comp.lang.fortran:4247 comp.lang.c:34434 Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!sun-barr!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!src.honeywell.com!msi.umn.edu!cs.umn.edu!kksys!wd0gol!newave!john From: john@newave.UUCP (John A. Weeks III) Newsgroups: comp.lang.fortran,comp.lang.c Subject: Re: Fortran vs. C for numerical work Keywords: dependence analysis, C, Fortran Message-ID: <533@newave.UUCP> Date: 2 Dec 90 06:03:20 GMT References: <21884@orstcs.CS.ORST.EDU> <1990Nov21.220816.15220@rice.edu> Reply-To: john@newave.mn.org (John A. Weeks III) Followup-To: comp.lang.fortran Organization: NeWave Communications Ltd, Eden Prairie, MN Lines: 32 In a somewhat long discussion... > > > It is often stated that Fortran is better than C for numerical work. > > It may not be true any more. A friend of mine brought a little fortran > > program (It is two big do loops with some instrinsic function calculation > > in the loop.) and the C translation of the fortran program. We compiled two > > program on a IBM RISC System 6000/530 with xlc and xlf. To my surprise, the > > excutable from C is faster than the excutable from Fortran by a few percent. I hope that numerical quality is not always measured by speed. If my recent experience means anything, I think that Fortran implementations generally have more well behaved numerical libraries, documented behavior, and better error handling. And since FORTRAN is noted for numerical work, someone usually tests the floating point stuff before the compiler is shipped. I have encountered C compilers that made me wonder if + and - was even tested. Of course, I remember things that don't work longer than I remember things that do work flawlessly 8-). The speed that FORTRAN is noted for can be found on the big IBM boat anchors. COBOL and FORTRAN rule on those machine for speed (discounting assembler) with C being something like 10 times slower when performing similar tasks (based on benchmarks with the IBM & SAS compilers). C style I/O is especially slow on IBM mainframes because those machines work best with record I/O and C programmers tend to think in streams of characters. -john- -- =============================================================================== John A. Weeks III (612) 942-6969 john@newave.mn.org NeWave Communications ...uunet!rosevax!tcnet!wd0gol!newave!john =============================================================================== Brought to you by Super Global Mega Corp .com