Path: utzoo!mnetor!uunet!husc6!ut-sally!nather
From: nather@ut-sally.UUCP (Ed Nather)
Newsgroups: comp.arch
Subject: Re: Approaches to computer system performance
Message-ID: <10422@ut-sally.UUCP>
Date: 21 Feb 88 16:25:11 GMT
References: <839@ima.ISC.COM> <1988Feb7.185328.11509@utzoo.uucp>
Organization: U. Texas CS Dept., Austin, Texas
Lines: 34

In article <1988Feb7.185328.11509@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes:
> > I find that with a typical UNIX
> > C compiler, you can often get a factor of two improvement by going to
> > assembler. 
> 
> Well, first, if by "a typical UNIX C compiler" you mean something like the
> typical VAX compilers, you are talking about a ten-year-old compiler that
> emphasized portability rather than optimization from the start.  (Yes,
> there have been improvements to it since, but not drastic ones.)  Modern
> compilers are a different story.
> 

Well, I'm using Borland's Turbo C "optimizing" compiler v1.0 to write a
time-critical program, and while it does pretty well most of the time,
it sometimes generates code much too slow for my application.  I then
must go to assembler, in desperation.  I believe it would qualify as a
"modern compiler."

As an example, I use large data arrays (long ints) and must clear them
when I start a data acquisition run.  I wrote a straight-forward "for"
loop to do it, and found it was taking much longer than I could tolerate.
After writing the "clear" routine in assembler, using the repeated store
instruction available on the 80x8x chips, I found the execution time to
be 13 times faster, by direct measurement.

While I agree writing in C is both easier and more portable, there are
times when you just can't pay such a high price.  In my view, compilers
have a long way yet to go.

-- 
Ed Nather
Astronomy Dept, U of Texas @ Austin
{allegra,ihnp4}!{noao,ut-sally}!utastro!nather
nather@astro.AS.UTEXAS.EDU