Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site spar.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!bellcore!decvax!decwrl!spar!freeman
From: freeman@spar.UUCP (Jay Freeman)
Newsgroups: net.arch
Subject: Re: 68020 benchmarks (and normalization thereof)??
Message-ID: <254@spar.UUCP>
Date: Mon, 20-May-85 14:20:47 EDT
Article-I.D.: spar.254
Posted: Mon May 20 14:20:47 1985
Date-Received: Thu, 23-May-85 02:23:22 EDT
References: <274@petfe.UUCP> <5598@utzoo.UUCP>
Reply-To: freeman@max.UUCP (Jay Freeman)
Organization: Schlumberger Palo Alto Research, CA
Lines: 20
Summary: 

/* libation to line-eater */

In article <5598@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes:
>It sure would be nice if Intel would normalize their benchmark reports
>to memory access times rather than clock rates, since different chips
>vary so much in the amount of work they do in one clock cycle.  But I
>guess their chips wouldn't show up so well then...  :-)
>-- 

Yes, but different chips also vary in the number of clock cycles it
takes to do a memory access.  Furthermore, it is conceivable that a
simple internal architecture, that accomplished relatively little work
per clock cycle; could be implemented with a faster clock than a complicated
architecture that did more per 'tick'.  I suspect that a better normalization
would be obtained by comparing the fastest parts actually available on a
given date:  Thus if 16 MHz 68010's and 12 MHz 80286's happen to be the
best that's real this week, we should compare them, at design clock, with
components fast enough to support them.
-- 
-- Jay Reynolds Freeman (Schlumberger Palo Alto Research)