Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!vsi1!wyse!mips!rnovak
From: rnovak@mips.COM (Robert E. Novak)
Newsgroups: comp.arch
Subject: Re: SPEC Bench-a-Thon
Message-ID: <22350@abbott.mips.COM>
Date: 28 Jun 89 01:52:16 GMT
References: <2395@canisius.UUCP> <4042@eos.UUCP> <22197@winchester.mips.COM> <1989Jun26.130517.29616@cs.rochester.edu>
Reply-To: rnovak@mips.COM (Robert E. Novak)
Organization: MIPS Computer Systems, Sunnyvale, CA
Lines: 24

In article <1989Jun26.130517.29616@cs.rochester.edu> bukys@cs.rochester.edu (Liudvikas Bukys) writes:
>In article <22197@winchester.mips.COM> mash@mips.COM (John Mashey) writes:
>>compress, to be used for SPEC, had to be made to run much longer than
>>the case MIPS uses internally.  In doing so, it now turns into a benchmark
>>that: a) either does serious I/O, or b) has elapsed time that might be
>>substantially longer than CPU time.   We're going to be working on
>>a coherent policy of handling such things, but we'd like to get
>>the first tape out the door first.
>
>Perhaps it would be acceptable to replace all the input with a pseudo-random
>stream (it's easy to find all the occurences of "stdin" and "getchar").
>
>Output checking is harder; does the SPEC suite check the answers from
>the other benchmarks?  If not, then the new benchmark-compress could
>just throw away the output; otherwise, maybe just checksumming the
>output would do as a first-order correctness check.

The SPEC benchmarks check their results against known good results.  This
was mandatory to guarantee that every machine was computing the same
algorithm.
-- 
Robert E. Novak                                     MIPS Computer Systems, Inc.
{ames,decwrl,pyramid}!mips!rnovak      928 E. Arques Ave.  Sunnyvale, CA  94086
rnovak@abbott.mips.COM (rnovak%mips.COM@ames.arc.nasa.gov)       +1 408 991-0402