Path: utzoo!attcan!uunet!husc6!uwvax!oddjob!ncar!boulder!sunybcs!bingvaxu!leah!itsgw!steinmetz!davidsen
From: davidsen@steinmetz.ge.com (William E. Davidsen Jr)
Newsgroups: comp.arch
Subject: Re: benchmarks
Message-ID: <10849@steinmetz.ge.com>
Date: 16 May 88 16:20:30 GMT
References: <30872@amdahl.uts.amdahl.com> <3460014@hpsrla.HP.COM> <2175@winchester.mips.COM> <31755@amdahl.uts.amdahl.com> <8734@ames.arc.nasa.gov> <399@m3.mfci.UUCP>
Reply-To: davidsen@crdos1.UUCP (bill davidsen)
Organization: General Electric CRD, Schenectady, NY
Lines: 23


  There are (at least) two ways to do benchmarks; by running complex
programs which are similar to your desired use, or by measuring the
hardware performance in a number of areas, and trying to match the
profile to the resources needed to run your program.

  I am a believer in the independent testing of facets of the machine
capabilities, since that allows me to run multiple tests concurrently to
determine interraction. ie. if a machine has good disk access for a
single process, how does it look under load? What does the use of
floating point have to do with the disk access (hopefully nothing).

  I have seen machines which had lousy disk performance single process,
and very little deterioration under load, while machines with very fast
disks sunk like a rock when loaded. I have seen machines which had poor
thruput for CPU bound jobs when disk bound processes were running. I
wouldn't have seen this as clearly if I hadn't had an idea of what the
machine did in each area individually.

-- 
	bill davidsen		(wedu@ge-crd.arpa)
  {uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me