Path: 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 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: 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 Brought to you by Super Global Mega Corp .com