Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!mash
From: mash@mips.com (John Mashey)
Newsgroups: comp.arch
Subject: Re: More Snake bytes.
Message-ID: <1871@spim.mips.COM>
Date: 4 Apr 91 04:02:57 GMT
References: <2004@kuling.UUCP> <8840021@hpfcso.FC.HP.COM> <569@diab.se>
Sender: news@mips.COM
Organization: MIPS Computer Systems, Inc.
Lines: 47
Nntp-Posting-Host: winchester.mips.com

In article <569@diab.se> pf@diab.UUCP (Per Fogelstr|m) writes:
>In article <8840021@hpfcso.FC.HP.COM> maf@hpfcso.FC.HP.COM (Mark Forsyth) writes:
>>>From: mash@mips.com (John Mashey)
>>
>>>the line of well-implemented single-issue, 1-level cache RISCs,
>>>i.e., SPECint = .75-.80X MHz.

>>The integer "performance" is 2.7 times the 25 MHz R3000 (DEC 5000/200). 
>>Speed is an extremely important high performance design technique. If 
>>you normalize it out you end up with a truely meaningless indicator of
>>performance and one that users shouldn't and don't care about.

>I think Mashey's statement is correct. It's not meaningless to compare
>normalized SPECint because it gives You a good indicator on how well
>the architecure is implemented. The proof is the SPECint figure for
>Sparc which is very low compared to others. You might guess why.

As maf points out, the (anythings)/Mhz is fairly irrelevant to
end users.  Of course, this is a newsgroup on computer architecture,
and my note was a successor to some earlier postings (I don't recall
from whom) about SPECint/MHz.
Such numbers (actual benchmark)/Mhz are of interest to architects,
of course, since:
	a) SPECint/Mhz is probably as close as you can get to a measurable
	integer CPI, where you can get real numbers for lots of machines.
	[Because it is truly difficult to get real
	Cycle-Per-Instruction numbers, unless you are the computer
	architect with all of the real, likely-to-be-proprietary tools.]
	Many arguments, real or bogus, revolve around CPIs,
	hence it is useful to actually have some realistic metrics
	to compare on.  Of course, it is also userful to look at
	SPECmarks/Mhz, SPECfp/Mhz,  LINPACK MFLOPS/Mhz, etc, i.e., as
	long as the benchmark is something you think is meaningful.
	b) An open issue (based on machines on the market)
	is whether or not you can get the
	SPECint/MHz much better than .75 to .85.  It is CLEAR that
	you can get SPECmark and SPECfp better.  Somewhere in Hennessy
	and Patterson it talks about available low-level parallelism,
	and differences thereof regarding types of code.
But again, end users should usually care less ... even I, in "end user
mode", have been known to purchase computers with processors in them
whose SPECint/Mhz would probably be .1 or so :-)
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	 mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash 
DDD:  	408-524-7015, 524-8253 or (main number) 408-720-1700
USPS: 	MIPS Computer Systems MS 1/05, 930 E. Arques, Sunnyvale, CA 94086