Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!ucsd!ucbvax!decwrl!decvax!tektronix!uunet!mcvax!cernvax!hjm
From: hjm@cernvax.UUCP (hjm)
Newsgroups: comp.arch
Subject: Balanced system - a tentative definition
Message-ID: <794@cernvax.UUCP>
Date: 11 Aug 88 09:30:53 GMT
Reply-To: hjm@cernvax.UUCP ()
Distribution: comp.arch
Organization: CERN European Laboratory for Particle Physics, CH-1211 Geneva, Switzerland
Lines: 49



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?

The explanation of this definition is that every part of the sys-
tem  is  going as fast as it can, and that no one part is holding
up the process.  Consequently, if any one  part  slows  down,  it
would drag the rest of the system down with it.

In this definition, I include both the hardware and the  software
in  the  term  "system",  as  a system can only be balanced for a
given problem, or class of problems.  For example,  Amdahl's  Law
about  1 MIPS & 1 MB & 1 Mbyte/sec was for I/O intensive business
applications written in COBOL.  This is  obviously  not  directly
applicable to image processing written in assembler or C, for ex-
ample.

Including the software as part of the system is  a  more  general
view  than that expressed by the original debaters (who were dis-
cussing memory speeds and CPU speeds  with  reference  to  screen
blitting),  but  is  necessary as this is most often the limiting
factor on system performance; the most dramatic speedups are usu-
ally  achieved by tweaking the software.  But, there comes a time
when, for instance, the number of calculations required cannot be
changed (you always have to do the same number of FLOPS in an FFT
calc) and the CPU is then the limit.  If it is choked by a memory
that requires wait-states then that is the next point of improve-
ment.  Increasing the memory speed might then lead to a  balanced
system  where  the  CPU is processing as fast as possible and sa-
turating the memory whilst executing a well-written program.   At
this  point,  increasing either the CPU speed or the memory speed
would have no effect, and the software can't be  tweaked  anymore
anyway  -  a  balanced  system.   But, detuning any one component
(CPU, memory or software) would cause a speed hit.  Hence the de-
finition.

(I  haven't  mentioned  I/O-related  parameters,  such  as   disk
transfer  rates  or  disk  access times, but the extension to any
given system parameter is not difficult.)

        Hubert Matthews