Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!rpi!batcomputer!kahn
From: kahn@batcomputer.tn.cornell.edu (Shahin Kahn)
Newsgroups: comp.arch
Subject: Re: Performance
Keywords: SPECmark Ratio, SPECthruput Ratio
Message-ID: <10213@batcomputer.tn.cornell.edu>
Date: 6 May 90 07:18:34 GMT
References: <402@dg.dg.com> <406@dg.dg.com> <38303@mips.mips.COM>
Reply-To: kahn@tcgould.tn.cornell.edu (Shahin Kahn)
Distribution: na
Organization: Cornell Theory Center, Cornell University, Ithaca NY
Lines: 59

In article <38303@mips.mips.COM> mash@mips.COM (John Mashey) writes:
<In general, with any of these higher-performance machines, one can NEVER
<assume that 2 machiens with the same clock rate will even exhibit the same
<uniprocessor performance on single-user benchmarks, simply because
<memory systems can differ greatly:

And I would add that the difference in performance for milti-user
benchmarks is probably more likely and greater.
Talking about which, what is the story with SPEC-throughput??
I had never heard of it until a few articles ago.
I hope they are not running jyst two copies of a benchmark.
They should run N=1,..,M,..,M+4 copies where M is the 
number of jobs at which paging starts.  One needs to look
at the slopes before and after paging (and hopefully you get
two straight lines with not much of a knee).
You might get surprized at what you see!

<	cache sizes, types, and hierarchy
<	memory latency
<	refill size
<	depth and nature of write-buffers
<	parity versus ECC, sometimes

Well said.  I kept these lines so they get read again!
Aren't these the parts of a system that cost the most?
What is your estimate of the cost split among various components
of a 'system'?

<Typical (but not always) rules of thumb are:
<	a) A single processor within a multiprocessor is usually slower than
<	an equivalent thing designed as a uniprocessor.

Why?  I'd have guessed it to be the opposite since a multi-processor-capable
machine with only a single processor in it may have access to a
better or more available memory system.  No?  And multiple processors may not
all want the memory system at the same time.

<	b) It is often HARDER work to make a big-machine run as fast as
<	a workstation, or even better, an embedded-control design using the
<	same chips.   Why should this be?
<		1) ECC is often slower than parity.
<		2) Sometimes you can easily build memory expandability
<		up to X at a given speed, but if you want to get to 2X<
<		you end up doing a different design that may cost you,
<		because busses get longer, etc.

Yes, cost does not grow linearly with performance (and on top of it,
price does not grow linearly with cost! (or does it?!)

Could you expand on point 1 a little.  I don't know the performance
aspects of ECC and parity.  
Actually, if you could clarify this point (b), it would be nice.
'Harder' or more expensive?
'big-machine' ?
Thanks.

<-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>

Shahin.