Article View: comp.arch
Article #3226Re: 55 MIPS & 66 MIPS (really, embedded & military benchmarking)
From: John Mashey
Date: Thu, 30 Nov 1989 20:44
Date: Thu, 30 Nov 1989 20:44
82 lines
5267 bytes
5267 bytes
In article <5275@omepd.UUCP> mcg@ishark.Berkeley.EDU (Steven McGeady) writes:
>
>In article <31329@winchester.mips.COM>, hawkes@mips.COM (John Hawkes) writes:
>
>> The Atlantic Research Corporation, an independent group, has done some
>> comparisons between the MIPS R3000 (25-MHz) and a 20-MHz 80960 executing >Ada
>> programs (the "Common Avionics Processor Ada Benchmark Suite"), and they
>> discovered that the R3000 was usually more than twice as fast on hand-
>> coded programs, and overall was more than five times faster on
>compiled > > programs.
>The 20MHz 960 referred to here is the Military 80960MC part, *not* the
>960CA. The 960MC hit silicon in 1985 and has not been upgraded since
>then. ARC did not measure the 960CA, even though that would have been
>a more representative measurement. The part measured was running in a
>PC/AT plug-in board. The MIPS system it is being compared to is a full
>system with a significantly-sized off-chip cache.
>
>The 960CA would perform approximately 2x *faster* than the MIPS R3000
>on the handcoded versions of the benchmarks. For compiled code, if
>the code were written in C, we would also perform approximately 2x
>faster. The code in question was compiled with a beta-release Ada
>compiler available last spring. Mr. Hawkes is doing the expected
>in attempting to show MIPS' processor in the best light, but not in
>Mr. Mashey's spirit of "full disclosure". If people are more
>interested in these tests, I will see how much information JIAWG will
>allow to be released, and release it here.
Well, I'm not sure any of these means a whole lot. The tests were
done in April, so 960CA's weren't available, and of course MCs and CAs
are extremely different (people sometimes get confused by the variations
in Intel nomenclature of versions :-). John cited one of the few results known
to be available, as such results are not the easiest things to come by.
Also, in the spirit of "full disclosure", note that they may have later
ran it on a 25MHz R3000, but the report I saw used a 16.7MHz R2000 in
an M/120. The 960 was an EVA-960KB board, including 1MB of DRAM,
and 64KB of 35ns SRAM. "All benchmarks were run out of SRAM".
Note, of course, that for almost any chip, a single-board-computer
design is FASTER than a larger/expandable design with multiple boards,
because you usually can build a tighter memory system.
Thus, the fact that something is a plugin board to a PC is irrelevant:
the bigger system has to bear performance burdens that a plugin board does not,
and having everything in SRAM is likely to be faster than having SRAM cache
in front of DRAM.
The benchmarks I saw included some floating-point, which I suspect would
not have pleased the 960CA.....
Of course, it is hard to say much about any of this, as the ones I saw were all
small benchmarks anyway, hence taken with a grain of salt.
This certainly relates to the discussion at Microprocessor Forum
regarding the difficulties of benchmarking embedded systems,
i.e., doing UNIX ones is bad enough, but the embedded world is really
a zoo by comparison! I certainly expect the 960CA to be noticably faster.
I also note that even people are trying hard to do sensible and fair
benchmarking, it's easy to say things that are subject to argument.
(At the M-F, there was an interesting sequence between the i960 & AMD 29K
crews that illustrated this, especially with rgard to evaluation boards.)
anyway, peace.
Finally, it probably doesn't matter a whole bunch, at least in terms of
what fired all of this 960 vs R3000 stuff up in the first place.
As **most** people interested in this area know, the i960 and MIPS were chosen
last summer as the 2 architectures of choice by the JIAWG committee,
(after a "spirited" competition I believe). For various reasons having
nothing to do with computer architecture, these two choices have tended to
to ripple through the defense community as 32-bit military RISC standards,
which is why, of course, the JIAWG battle was pretty hard-fought in the
first place.
I'll soon post an analysis of a related effort [the SAE committee's
recommendations], as an example relevant to the difficulty of embedded
evaluations, and also relevant to one of my favored topics:
interpretation and (mis)interpretation of data. In preparation for
that you might want to read the Suntech Journal, Autumn isse, page ST8,
"SPARC Scores in DARPA/SAE Architecture Test", which reminded me of the SAE.
--
-john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com
DDD: 408-991-0253 or 408-720-1700, x253
USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
Technical Details
Message-ID:
<32468@winchester.mips.COM>Path:
arc1-ca.pugleaf.net!utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!usc!jarthur!bridge2!mips!mashReferences:
<31329@winchester.mips.COM> <1358@bnr-rsc.UUCP> <5275@omepd.UUCP>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!usc!jarthur!bridge2!mips!mash From: mash@mips.COM (John Mashey) Newsgroups: comp.arch Subject: Re: 55 MIPS & 66 MIPS (really, embedded & military benchmarking) Message-ID: <32468@winchester.mips.COM> Date: 30 Nov 89 20:44:30 GMT References: <31329@winchester.mips.COM> <1358@bnr-rsc.UUCP> <5275@omepd.UUCP> Reply-To: mash@mips.COM (John Mashey) Organization: MIPS Computer Systems, Inc. Lines: 82