Xref: utzoo comp.lang.c:27183 comp.lang.misc:4635
Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!mailrus!purdue!mentor.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.lang.c,comp.lang.misc
Subject: Re: A note for those not consumed by efficiency worries
Summary: The choice of algorithm is important and machine-dependent
Message-ID: <2024@l.cc.purdue.edu>
Date: 24 Mar 90 13:56:17 GMT
References: <1990Mar21.061420.9862@athena.mit.edu> <1084@targon.UUCP>
Followup-To: comp.lang.c,comp.lang.misc
Organization: Purdue University Statistics Department
Lines: 37

In article <1084@targon.UUCP>, ruud@targon.UUCP (Ruud Harmsen) writes:
> In article <1990Mar22.072712.10902@diku.dk> jensting@skinfaxe.diku.dk (Jens Tingleff) writes:
> >
> >	MAKE THE THING WORK, THEN MAKE IT FAST.
> >
> True.  But only with one very important footnote:
> 
> While making the thing just work, do consider performance, and know where and
> how you might want to optimise later.
> If in the design of a programme or system you totally disregard all
> performance issues, you might have to rebuild large parts from scratch,
> and/or make the whole thing totally incomprehensible when optimisizing.
> 
> I've seen things like that happen, and I can tell you it's a tragic sight
> to watch.  A much better approach is to have the spots for optimization
> marked and planned, so it is easy to fulfill, will be really effective
> and does not violate the original design.

There are far too many algorithms which work, but cannot be speeded up
appreciably, while other algorithms are very much faster.  The choice of
the algorithm depends on what can be done in the hardware.

A good example is the frexp() function in 4.2BSD.  This was (ugh) coded in C
for the implementations I have seen in a straightforward manner.  By using
additional resources, it could have been speeded up in the (unfortunately
too common) bad cases, but only by using additional resources and running
slower in the better cases.  It worked, but could not be made fast.

However, a semi-portable machine-dependent algorithm, deliberately ignoring
typing, could be written which is in the ballpark of machine language 
algorithms.  Starting with these, one could make it fast.  But unless
the operations of pack and unpack are in the language, this cannot be
done otherwise.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)