[net.arch] 68020 benchmarks

freeman@spar.UUCP (Jay Freeman) (05/20/85)

/* 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)

dave@soph.UUCP (Dave Brownell) (05/24/85)

In article <I'm a bug -- fix me!> freeman@max.UUCP (Jay Freeman) writes:

>	       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.

This also seem simplistic.  If a given system (say the 80286) needs a
memory system that's twice as fast and three times as expensive as another
(say the 68010), I get no benefit from such a benchmark.  Of course, if you
can spend more money you can get better performance!!!!!

What we really need is multi-dimensional benchmarks:  compare the fastest
available processors with two or three different standard speed memory arrays.
This would give designers usable numbers on what kind of *system* performance
(the only kind that matters) can be expected for a given cost or design
complexity.
-- 
	Dave Brownell
	EnMasse Computer Corporation
	enmasse!dave@Harvard.ARPA
	{genrad,harvard}!enmasse!dave