Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!sirius.ucs.adelaide.edu.au!augean!sibyl!ian
From: ian@sibyl.eleceng.ua.OZ (Ian Dall)
Newsgroups: comp.arch
Subject: Re: Speed costs (Re: MWC's Coherent - A Lemon...)
Message-ID: <640@sibyl.eleceng.ua.OZ>
Date: 27 May 90 00:53:01 GMT
References: <2793@crash.cts.com> <265D2FE5.2513@tct.uucp>
Reply-To: ian@sibyl.OZ (Ian Dall)
Organization: Engineering, Uni of Adelaide, Australia
Lines: 41

In article <265D2FE5.2513@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:
>The old saw that programs will expand to fill the memory available to
>them is true.  It points out that the primary reason why mundane
>programs use large memory spaces is the tendency of programmers to use
>brute force to attack problems until the computer they're using runs
>out of force.  It used to be that the brute force line was crossed
>quite early; not so today.  Too bad.

Not entirely. Sure it would be nice if all code was compact, but
achieving it isn't free. I too did my first serious programming on
PDP-11's (running RT-11 which left one with less the 64k (~45k ?) to
work in). I spent a *lot* of time shoe horning programs into limited
space. Younger programmers might not have the same skills in that
area, but they *don't need them*. We all have to get used to the fact
that memory is now about $80/MB and swap space is about $10/MB. By the
time the project you are working on is finished, these prices might
have halved. There is just no point in being too stingy with either!
Indeed, these days, an employer could be justified in berating a
programmer for wasting time reducing the size of a program instead of
increasing it's speed or functionality or getting it to market
earlier!

The same argument applies to a lesser degree to speed. Generally, so
long as it is small "enough" and fast "enough" (*), there are better
things to do with your time than making it smaller or faster.  The
reality of the industry is that improvements in software lag behind
improvements in hardware, and it makes sense to trade size and
performance for speed of development.

I don't mean to imply that there is often big gains to be made by
redesigning things from time to time. In operatin systems, Mach seems
to me a step in the right direction, but I think the improvements are
largely a cleaner better partitioned OS with any reduction in code
size being a fringe benefit.

(*) Don't bother telling me that you can always use a faster numerical
    analysis routine, so can I. There are some programs which will not,
    in the forseeable future, ever be fast "enough".
-- 
Ian Dall     life (n). A sexually transmitted disease which afflicts
                       some people more severely than others.