Path: utzoo!mnetor!uunet!husc6!rutgers!clyde!watmath!watcgl!watsol!tbray
From: tbray@watsol.waterloo.edu (Tim Bray)
Newsgroups: comp.arch
Subject: Approaches to computer system performance
Message-ID: <3081@watcgl.waterloo.edu>
Date: 28 Jan 88 17:30:04 GMT
References: <839@ima.ISC.COM> <2158@geac.UUCP> <604@bnr-rsc.UUCP> <180@granite.dec.com>
Sender: daemon@watcgl.waterloo.edu
Reply-To: tbray@watsol.waterloo.edu (Tim Bray)
Organization: New Oxford English Dictionary Project, U. of Waterloo, Ontario
Lines: 30
Keywords: Algorithms, Data structures, assembler, special purpose hardware
Summary: Take a high-level approach

In discussing system performance, in article <180@granite.dec.com> 
jmd@granite.UUCP (John Danskin) suggests:
>	
>	2) Redo the parts that aren't fast enough in assembler.
>
>	3) Change your algorithms so there is more time.
>
Item #3 is right.  Item #2 is WRONG.  The more years I build up in this
business, the more I come to believe that technical sidesteps like
assembler coding, special purpose hardware, and the like do not give
anything like the payback you get from careful attention to algorithms.

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).

In support of my position, let me chant a few phrases: Database machine,
LISP machine, object-oriented architecture, user-written microcode,
Complex Instruction Set, writing operating systems in assembler.

Among other things, I have my doubts about Sun's NeWS for this very same
set of reasons.  System performance is a high-level issue and in general
requires high-level solutions.

Algorithms si!  Low-level hacking no!
Tim Bray, New OED Project, University of Waterloo