Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!mips!dimacs.rutgers.edu!aramis.rutgers.edu!paul.rutgers.edu!njin!uupsi!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.lang.c
Subject: Re: Just rambling about optimization...
Message-ID: <10550:May918:36:1291@kramden.acf.nyu.edu>
Date: 9 May 91 18:36:12 GMT
References: <3072:May700:46:3691@kramden.acf.nyu.edu> <42843@netnews.upenn.edu> <721@taumet.com>
Organization: IR
Lines: 27

In article <721@taumet.com> steve@taumet.com (Stephen Clamage) writes:
> dsimon@eniac.seas.upenn.edu (Derron Simon) writes:
    [ wants a source-code optimizer ]
> I'm not surprised.  It is of very little use.

That's what I mean by counterproductive. But rather than trying to
convince you that any competent human can easily outdo the best
available automated optimizers, let me show you an unarguable advantage
of source-code optimization.

A typical math library takes hours, often even days to compile on each
machine. Installing several libraries can start taking a huge chunk from
the CPU time available for users. Why is compiling so slow? Because the
optimizer spends so much time searching for optimizations that could
have been expressed at the source level.

Guess what? If someone includes a source-optimized version along with
the original code, you won't have to waste nearly as much time doing the
same optimizations again for your machine.

This points to a productive area of research: how to make languages
sufficiently expressive that all interesting optimizations *can* be
expressed portably at the source-code level. Now doesn't this seem more
useful than answering every optimization question with ``It is of very
little use''?

---Dan