Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!purdue!ames!pasteur!agate!eos!jaw
From: jaw@eos.UUCP (James A. Woods)
Newsgroups: comp.arch
Subject: Re: SPEC Bench-a-Thon
Message-ID: <4042@eos.UUCP>
Date: 22 Jun 89 19:46:38 GMT
References: <2395@canisius.UUCP>
Organization: NASA Ames Research Center, California
Lines: 17

>>
>>as a benchmark, what's wrong with unix 'compress',
>>other than it messes up mipsco internal benchmark numbers?
>>
>  We used compress as one of many tests between a MIPS system and several
>  others.  It didn't "mess up" the MIPS in any way.  
> 
was referring here to the bit about how this integer benchmark,
since it scribbles semi-randomly over a sparse array bigger
than the cache, runs at about nine-ten vax mips on the m3000 system,
which is billed at twenty.

a mipsco employee informed me that the problematic memory write latency
exercised by 'compress' "dragged down their numbers for the r3000 chip"
during simulations.

other risc implementations, of course, may yield similar results.