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