Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!uwvax!oddjob!tank!uxc!uxc.cso.uiuc.edu!uxg.cso.uiuc.edu!uxe.cso.uiuc.edu!hirchert From: hirchert@uxe.cso.uiuc.edu Newsgroups: comp.lang.fortran Subject: Re: Fortran versus C for numerical anal Message-ID: <50500079@uxe.cso.uiuc.edu> Date: 28 Sep 88 14:41:00 GMT References: <893@amelia.nas.nasa.gov> Lines: 59 Nf-ID: #R:amelia.nas.nasa.gov:893:uxe.cso.uiuc.edu:50500079:000:3673 Nf-From: uxe.cso.uiuc.edu!hirchert Sep 28 09:41:00 1988 Peter da Silva (peter@ficc.uu.net) writes: >In article <4151@lanl.gov>, jlg@lanl.gov (Jim Giles) writes: >> 1) It rasies the spectre of aliasing in contexts where it doesn't exist >> if the pointer isn't user accessible. For this reason, things that >> would otherwise vectorize or unroll for pipelining must be done by >> the compiler as if the possible aliasing has actually occurred. >You use Fortran and you complain about aliasing? What about common blocks, >call-by-reference to constants, equivalence, and all the other horrible >places that Fortran can bite you on aliasing. Even *without* worrying >about optimisation. FORTRAN doesn't mandate call-by-reference to constants and other expressions, but even when this implementation technique is used, it does not cause problems for correct programs, and it is not a barrier to optimization. (I also have never before seen the term "aliasing" used to describe this situation.) Using common blocks can create multiple names for the same object, but since these different names are in different scopes that are typically compiled separately, this is not normally a performance problem (or referred to as "aliasing"). If you happen to have a compiler that does cross-procedural analysis (just beginning to become popular in the FORTRAN world), then the compiler might "see" both names at one time, in which case the effect is essentially the same as equivalence. Equivalence does create multiple names for an object, but since this effect is static, it can be analyzed by the compiler so that no more performance degradation takes place that would have occurred if a single name had been used at each reference. (Although this is aliasing in the English language sense, this is not what is usually meant by "aliasing" when discussing compilation problems.) In the context of performance and compilation discussions I have encountered, "aliasing" means dynamic aliasing, i.e. run-time behavior that causes two or more names to identify the same object. In order to insure correct behavior, a compiler may have to forgo optimizing transformations because of the _possibility_ that two names might identify the same object. To the extent that this possibility is not realized, this is an unnecessary loss in performance and considered a problem. One of the reasons FORTRAN so frequently outperforms C and other "modern" languages on computationally intensive benchmarks is that FORTRAN is largely free of "aliasing" in this sense and thus suffers fewer unnecessary performance losses. >> 2) It clutters up it's scope with the name of something I don't need >> explicit access to. This increases the possibility of another >> variable, whose name is misspelled, going undetected. >You use Fortran and you complain about misspellings going undetected? This >language has more of a problem with typos than any other just because of >implicit typing of variables. I think that this 'feature' of Fortran by itself, >counts far more against it than *anything* you can call up against C. Other things being equal, variable "clutter" increases the chances of undetected typos. Implicit typing increases this possibility far more, but most FORTRAN programmers who care about this that I know of either use IMPLICIT NONE (on machines where it is available) or simulate the effects of IMPLICIT NONE with either IMPLICIT LOGICAL(A-Z) or IMPLICIT COMPLEX(A-Z) (or better still, by alternating between these two on successive compilations). >Peter da Silva `-_-' Ferranti International Controls Corporation. Kurt W. Hirchert hirchert@ncsa.uiuc.edu National Center for Supercomputing Applications