Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!alberta!calgary!radford
From: radford@calgary.UUCP (Radford Neal)
Newsgroups: comp.arch
Subject: Re: Approaches to computer system performance
Keywords: Algorithms, Data structures, assembler, special purpose hardware
Message-ID: <1325@vaxb.calgary.UUCP>
Date: 31 Jan 88 02:43:33 GMT
References: <839@ima.ISC.COM> <2158@geac.UUCP> <604@bnr-rsc.UUCP> <3081@watcgl.waterloo.edu>
Organization: U. of Calgary, Calgary, Ab.
Lines: 23

In article <3081@watcgl.waterloo.edu>, tbray@watsol.waterloo.edu (Tim Bray) writes:

> Given a routine which you have determined, with careful profiling, to be 
> sucking up a lot of your resources, how much more can you really get
> out of it than the compiler-generated code?  Unless you are lucky and have
> a deep understanding of your machine's architecture *and* the implementation 
> of that architecture, and the routine does something for which the compiler 
> generates pathologically poor code, probably no more than a few percentage 
> points.  (Given a reasonably modern compiler).

Well, the last phrase may make your statement true, but if so, I don't
use many "reasonably modern compilers". I find that with a typical UNIX
C compiler, you can often get a factor of two improvement by going to
assembler. I assume here that your C program is written carefully, but
that you haven't been looking at the generated code to see which constructs
are handled better by your compiler, then making changes that have no 
machine-independent motivation.

This isn't to say that algorithmic improvements won't get you even more, but
if you're desperate, you've already done that...

   Radford Neal
   The University of Calgary