Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site alice.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!alice!rae
From: rae@alice.UucP (Rae McLellan)
Newsgroups: net.arch
Subject: performance metric
Message-ID: <5166@alice.uUCp>
Date: Sun, 23-Mar-86 21:41:49 EST
Article-I.D.: alice.5166
Posted: Sun Mar 23 21:41:49 1986
Date-Received: Tue, 25-Mar-86 03:27:48 EST
Organization: Bell Labs, Murray Hill
Lines: 26


   John Mashey suggests:
	Use cycles/MIPS (normalized to some common unit of work),
	i.e., try: cycles/MIPS = (clock rate in MHz) / (MIPS rating)

But the units seem to be confused.  Clock rate in MHz should be Mega-cycles.
In any event, the Mega's cancel and you're left with clocks/inst.  What
are you really trying to say?  It's not the best (or worst) #clocks/inst
that should be reported, but rather the average #clocks/inst sustained
over a significant stretch of code?  (please verify this.)

I too have been disgruntled with the meaning of MIPS.  In particular,
the multi-processor types (IBM, NEC, Encore, etc) which trumpet their
superior performance as a single MIPS number.  Instead of a single MIPS
number, I'd like to clarify exactly what is being measured with 3
separate performance metrics:

   Peak MIPS	  maximum #inst/second
   Average MIPS	  sustained rate over a "reasonable" instruction mix
		  further describing the mix as w/ floating point, w/o, etc.
   Aggregate MIPS describes the additional performance (however specious)
		  which arise with the extra processors.

Let's try to inform, not mislead. 

	Rae McLellan
	AT&T Bell Laboratories		research!rae