Path: utzoo!attcan!uunet!lll-winken!brutus.cs.uiuc.edu!usc!snorkelwacker!husc6!encore!xenna!skeller
From: skeller@xenna.Encore.COM (Shaun Keller)
Newsgroups: comp.arch
Subject: Re: Latest SPECmarks
Summary: Clock
Message-ID: <11130@encore.Encore.COM>
Date: 13 Feb 90 14:57:14 GMT
References: <8859@portia.Stanford.EDU> <5190@convex.convex.com> <1850@cbnewsi.ATT.COM> <2938@oakhill.UUCP> <3085@rtmvax.UUCP> <7377@pdn.paradyne.com>
Sender: news@Encore.COM
Reply-To: skeller@xenna.UUCP (Shaun Keller)
Organization: Encore Computer Corp, Marlboro, MA
Lines: 22

In article <7377@pdn.paradyne.com> alan@oz.paradyne.com (Alan Lovejoy) writes:
...
>			SPECmark eqntolt matrix300 fpppp tomcatv  CPU/MHz
>Moto Delta Model 8612   17.8     20.7    21.5      15.3  14.9     88000/33MHz 
>MIPS M/2000             17.6     18.3    13.3      20.4  17.7     R3000/25MHz
>Sparcserver 490         17.6     17.6    22.5      18.8  12.3     SPARC/33MHz
>MIPS RC3260             17.3     17.9    13.1      20.0  17.3     R3000/25MHz 
>Solbourne 5/801         16.3     17.2    22.6      17.9  11.8     SPARC/33MHz
...
>...Such
>things as cache size/speed, memory speed and disk access speed must contribute
>significantly to the results.

Well, why is comparing a 33 MHz 88k to a 25 MHz R3k a useful comparison?
These are RISCs!  Clock speeds should be roughly equal since the
instructions per clock cycle are about equal.  MIPs still looks like a more
efficient design.  Sure, these are complete (shipping?) system performance
numbers, but in comp.arch we should look at basic architectural
characteristics that we can isolate and study. :-)

-Shaun Keller (skeller@encore.com)
"Reductio ad absurdum performed while you wait."