Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!ucsd!ucsdhub!esosun!seismo!uunet!mfci!colwell
From: colwell@mfci.UUCP (Robert Colwell)
Newsgroups: comp.arch
Subject: Re: Balanced system - a tentative definition
Message-ID: <505@m3.mfci.UUCP>
Date: 13 Aug 88 18:19:57 GMT
References: <794@cernvax.UUCP> <6082@haddock.ISC.COM>
Sender: root@mfci.UUCP
Reply-To: colwell@mfci.UUCP (Robert Colwell)
Distribution: comp.arch
Organization: Multiflow Computer Inc., Branford Ct. 06405
Lines: 37

In article <6082@haddock.ISC.COM> suitti@haddock.ima.isc.com (Steve Uitti) writes:
>In article <794@cernvax.UUCP> hjm@cernvax.UUCP () writes:
>>"A balanced system is one where an improvement in the performance
>>of  any single part would not increase the overall performance of
>>the system, and where the degrading of any single part would  de-
>>crease the overall performance."
>
>	It is a nice definition, but doesn't do much for the real world.

I disagree.  In the design of our TRACE VLIW, we had to balance
dozens of system design issues, such as number of register files,
number of register file write ports, number of register file read
ports, number of system buses, instruction sets, memory sizes,
functional unit quantities, functional unit pipelining, memory
pipelining, etc. ad-nearly-infinitum.  When somebody comes up to me
with code that they say is bottlenecked by one or another of these,
I don't shake my head sorrowfully.  I feel that as long as each of
the design parameters occasionally becomes the limiting case for some
program, then the design is probably pretty-well balanced.  If every
programmer were to complain about the same thing, I'd say that that
area probably deserved more attention in the design.

>	In real life I generally consider the CPU/RAM part as one half
>of the system, and disk I/O as the other half (and I ignore other
>kinds of I/O, unless the application being considered requires them).
>Usually the parameter that could be changed is how much RAM the system
>has, and this determines how much paging will happen.

These are just the obvious large-scale items.  At least for those one
has resources with which to make the decisions; there are books,
graphs, data, studies, and experts around.  Not that it's a piece of
cake, either, I grant you.

Bob Colwell            mfci!colwell@uunet.uucp
Multiflow Computer
175 N. Main St.
Branford, CT 06405     203-488-6090