Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!mtune!codas!usfvax2!pdn!alan
From: alan@pdn.UUCP (Alan Lovejoy)
Newsgroups: comp.arch
Subject: Re: brash micros versus the Big Iron: not yet
Message-ID: <1202@pdn.UUCP>
Date: Fri, 28-Aug-87 19:23:29 EDT
Article-I.D.: pdn.1202
Posted: Fri Aug 28 19:23:29 1987
Date-Received: Sun, 30-Aug-87 06:45:34 EDT
References: <622@winchester.UUCP> <12953@amdahl.amdahl.com> <630@winchester.UUCP>
Reply-To: alan@pdn.UUCP (0000-Alan Lovejoy)
Organization: Paradyne Corporation, Largo, Florida
Lines: 64

In article <630@winchester.UUCP> mash@winchester.UUCP (John Mashey) writes:
>Thanx for the posting!  This yields the amusing thought that the
>5890 acts like a RISC, according to the (simplistic) MHz/mips ratio:
>
>mips	MHz	MHz/mips	CPU / System
>2	16.7	8.3		68020 (in Sun-3/160)
...note that Sun's MIPS figures are converted to VAX equivalent,
and the '2' figure widely quoted represents the equivalent VAX MIPS;
the 'native' MIPS figure is about 3...
>5	33	6.6		Fairchild Clipper
>4	25	6.2		68020 (in Sun-3/260; caches help)
...see the comment above for the Sun-3/160...
>6	22.2	3.7		VAX 8700
>33	66	2.0		Amdahl 5890-190E
>10	15	1.5		MIPS M/1000
>
>This is a good illustration of the well-understood fact that
>you can keep the cycles/mips ratio pretty low, even for a clearly
>non-RISC architecture.  The cost is enough iron to give enough
>parallelism to permit heavy pipelining.
>

 mips*   MHz    MHz/mips         CPU/ System
 6       16.7   2.78             68030
 4       20     5.0              80386 (assumes native mode 32-bit code)
 10      30     3.0              32532
*based on manufacturers' claims

It cannot be denied that a low Mhz/mips ratio is a good thing, and
as the numbers above demonstrate, the major players appear to be
steadily reducing this statistic for their products.

However, as Motorola pointed out in one of their benchmark reports,
a CPU can have fewer MIPS but higher 'performance'.  The statistic
that REALLY is important is work-accomplished/time.  That is admittedly
much harder to measure.

It is amusing to see the hardware people champion "simplicity" of design
at the expense of software complexity, while software people clamor
for "simplicity" of design at the expense of hardware complexity
(for example, Niklaus Wirth).  Shifting complexity around between
hardware and software is just irresponisble sleight of hand unless
you can prove, on a case-by-case basis, that a given function
is more efficiently handled either in the hardware or the software. 

--alan@pdn

please
ignore
this
attempt
to 
prevent
the
new/old
ratio
checker
from
sending
my 
article
to
nya-nya
land