Xref: utzoo comp.lang.fortran:4105 comp.lang.c:34120 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!rice!letaba.rice.edu!paco From: paco@rice.edu (Paul Havlak) Newsgroups: comp.lang.fortran,comp.lang.c Subject: Re: Fortran vs. C for numerical work Keywords: dependence analysis, C, Fortran Message-ID: <1990Nov21.220816.15220@rice.edu> Date: 21 Nov 90 22:08:16 GMT References: <21884@orstcs.CS.ORST.EDU> Sender: news@rice.edu (News) Reply-To: paco@rice.edu (Paul Havlak) Organization: Rice University Lines: 31 In article <21884@orstcs.CS.ORST.EDU>, ghe@comphy.physics.orst.edu (Guangliang He) writes: |> In article bglenden@mandrill.cv.nrao.edu (Brian Glendenning) writes: |> > |> >It is often stated that Fortran is better than C for numerical work. |> >[Some deleted text here] |> |> 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. Presumably the Fortran-to-C translation preserved the array structure and indexing found in the original Fortran program. A good compiler can optimize Fortran, no matter what language it's written in. But watch out if you use C in its full generality. All but the simplest pointers will confuse a compiler and reduce its ability to optimize. Heap-allocated dynamic data structures will reduce data locality and increase page faults. To paraphrase Jack Schwartz: "We don't know what the numerical programming language of the year 2000 will be called, but it will look like Fortran." (Well, at least the loops will.) ----------- Paul Havlak These are the opinions of a single grad student, working on compiler analysis of scientific programs.