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: <504@m3.mfci.UUCP>
Date: 13 Aug 88 18:09:15 GMT
References: <794@cernvax.UUCP>
Sender: root@mfci.UUCP
Reply-To: colwell@mfci.UUCP (Robert Colwell)
Distribution: comp.arch
Organization: Multiflow Computer Inc., Branford Ct. 06405
Lines: 32

In article <794@cernvax.UUCP> hjm@cernvax.UUCP () writes:
>
>
>Someone a while ago asked what a "balanced system" is.  I propose
>the following definition for debate/flaming:
>
>"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."
>
>So that's my definition.  Comments, anyone?

I like your definition, Hubert.  The only thing that might be worth
stating explicitly is that the above must hold true for the workload
of interest.  For any given architecture, it is easy to conjure up
a program that runs extremely badly.  But that doesn't in itself 
mean that the architecture is deficient or imbalanced.   I know
Hubert knows this, but it's worth being very clear about it, because
I think this one issue was the primary cause of an awful lot of
early RISC/CISC fights ("my machine kicks your machine's butt on the
following set of toy benchmarks!"  "Oh, yeah, well my machine spits
on your benchmarks and blows you away on this other set!")

It's also usually possible to produce a program that runs extremely
well on some given machine; if you're going to go this route, though,
it behooves you to make that program something useful.

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