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