Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!rochester!bukys
From: bukys@cs.rochester.edu (Liudvikas Bukys)
Newsgroups: comp.arch
Subject: Re: SPEC Bench-a-Thon
Summary: "compress" and I/O
Message-ID: <1989Jun26.130517.29616@cs.rochester.edu>
Date: 26 Jun 89 13:05:17 GMT
References: <2395@canisius.UUCP> <4042@eos.UUCP> <22197@winchester.mips.COM>
Reply-To: bukys@cs.rochester.edu (Liudvikas Bukys)
Organization: U of Rochester, CS Dept, Rochester, NY
Lines: 15

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.