Path: utzoo!attcan!uunet!samsung!sdd.hp.com!ucsd!ucbvax!PHY.DUKE.EDU!rgb
From: rgb@PHY.DUKE.EDU ("Robert G. Brown")
Newsgroups: comp.sys.sgi
Subject: Re: Processor efficiency, mccalpin response.
Message-ID: <9006151729.AA01170@physics.phy.duke.edu>
Date: 15 Jun 90 17:29:53 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 19

That is exactly the sort of thing that I expected;  I just don't have
the data on the R3000.  I sort of hope that the SG tech people give
us some hard information.  I also want to know what kind of cache
it is;  it could be separate data and instruction caches or they could
be combined into one.  I need to know how big it is (although I could
do something like you have done and find out).  The larger reduction
in throughput (percentagewise) is probably due to the R3000 being a
faster processor in the first place; given that the memory bandwidth
is roughly the same in the 4D25 and the 220S, if it is the rate limiting
feature then one will see a bigger fraction of performance go down the
tubes on a faster processor.

This just goes to show the general unreliability of benchmarks
as a true measure of system performance.  As I tell my users,
the only way to know how a system will perform on a particular
problem is to try it.  Even Linpack doesn't really tell you much
about cache degradation, etc.

    rgb