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