Path: utzoo!utgpu!news-server.csri.toronto.edu!neat.cs.toronto.edu!jonah
Newsgroups: comp.arch
From: jonah@cs.toronto.edu (Jeff Lee)
Subject: Re: Bloat costs
Message-ID: <90Jun4.103308edt.14939@neat.cs.toronto.edu>
Organization: Department of Computer Science, University of Toronto
References: <2793@crash.cts.com> <265D2FE5.2513@tct.uucp> <640@sibyl.eleceng.ua.OZ> <2662CE6C.3E68@tct.uucp> <26798@eerie.acsu.Buffalo.EDU> <KHB.90May31000254@chiba.Eng.Sun.COM> <WSD.90Jun1130958@miles.cs.brown.edu> <25444.2667fff8@ccavax.camb.com>
Date: 4 Jun 90 14:33:34 GMT
Lines: 42

khb@chiba.Eng.Sun.COM (Keith Bierman - SPD Advanced Languages) writes:
>If we assume that Amdahl was even slightly right .... each "MIP"
>requires 1Mb main memory and 1Mb/sec of "disk" channel capacity.

Amdahl was speaking of shared mainframes, not single-user workstations.
He was also comparing systems of the same generation.  The analysis
might not be transferrable across different types and generations of
systems.

wsd@cs.brown.edu (Wm. Scott `Spot' Draves) writes:
>One of the wonderful things about 20Mip 32Mb workstations is that I
>don't have to worry about eff. when writing most code.  I can
>concentrate on other issues such as clarity of code, speed of
>execution, speed of development, fancy features, ...

>by "eff." i mean "frugal of code and data".

Being frugal with code and data often leads to clarity of code, speed of
execution, and speed of development.  You can then concentrate on
optimizing the 10% of the code that consumes 80% of the time.  The one
thing it doesn't get you is fancy features.  Give everyone a 20Mip 32Mb
workstation and they tend to forget about simplicity, modularity,
compatibility, and just stick in a Lisp extension language or 3D buttons
instead.  Designing for the general case instead of the special case
takes a bit bit longer but you save in the long run on reusability.
The trouble is often that most people look at every problem as being a
"special case".

merriman@ccavax.camb.com (George Merriman) writes:
>In fact, a lot of our maintenance headaches are
>caused by scrimping on resources ("Why use a longword here instead of a word?
>We'll never see a value of more than a few thousand." Ha!).

This is the wrong sort of "space efficiency", but alas, the most prevalent.
On the other hand, if the task is inherently sequential, why load *all*
the data into memory, process it, and then write out the result?  This is
one of the *worst* ways to use virtual memory, but is becoming much more
common.  People often use the size and speed of modern systems as an excuse
to not worring about picking the right *algorithm*.  As a result, the
solutions often don't scale well.

Jeff Lee -- jonah@cs.toronto.edu or utai!jonah