Xref: utzoo comp.lang.fortran:4139 comp.lang.c:34225 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!usc!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!mcsun!tuvie!vmars!hp From: hp@vmars.tuwien.ac.at (Peter Holzer) Newsgroups: comp.lang.fortran,comp.lang.c Subject: Re: Fortran vs. C for numerical work Keywords: dependence analysis, C, Fortran, register variables Message-ID: <2173@tuvie> Date: 26 Nov 90 16:33:05 GMT References: <21884@orstcs.CS.ORST.EDU> <1990Nov21.220816.15220@rice.edu> Sender: news@tuvie Followup-To: comp.lang.fortran Lines: 47 paco@rice.edu (Paul Havlak) writes: >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. Even simple pointer can confuse a compiler on brain-dead architectures. I had a little program that did something with two arrays item * a, * b; int i; /* init a, b */ for (i = 0; i < N; i ++) { a [i] = f (a [i], b [i]); } After I optimized it to: item * a, * b, * pa, * pb; /* init a, b */ for (pa = a + N, pb = b + N; pa >= a; /* I know that is not portable, but it works * with this compiler if sizeof (item) <= 8 */ pa --, pb --) { * pa = f (* pa, * pb); } it ran 80% slower, because on this architecture (80286) far pointers don't fit into registers whereas the integer i does, and indexing is relatively fast. To make things more complicated: On the same computer program 2 is faster than program 1 if both are compiled with near pointers. Morale: Write your code readable. Usually the compiler knows more about the architecture of the target computer than the programmer (especially if the program has to be compiled on lots of different computers) and can therefore optimize better. -- | _ | Peter J. Holzer | Think of it | | |_|_) | Technical University Vienna | as evolution | | | | | Dept. for Real-Time Systems | in action! | | __/ | hp@vmars.tuwien.ac.at | Tony Rand |