Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!ssbell!mcmi!dsndata!wayne From: wayne@dsndata.uucp (Wayne Schlitt) Newsgroups: comp.arch Subject: Re: SPECmarks Message-ID: Date: 23 Feb 90 15:17:36 GMT References: <7393@pdn.paradyne.com> <76700146@p.cs.uiuc.edu> <1990Feb22.175317.12898@utzoo.uucp> Sender: wayne@dsndata.UUCP Organization: Design Data Lines: 31 In-reply-to: henry@utzoo.uucp's message of 22 Feb 90 17:53:17 GMT In article <1990Feb22.175317.12898@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: > > In article <76700146@p.cs.uiuc.edu> gillies@p.cs.uiuc.edu writes: > >I don't disagree that you need to test a spectrum of operations; the > >SPEC benchmark is good in this respect. But keeping SPEC large is a > >poor way to test for caching affects. > > Why? Most of the applications that people will be running are similarly > large. Surely the way to test for caching effects on large programs is > to run large programs? i dont really disagree with what henry says, but i would like to point out not all real programs are large and not all large programs need to have large caches. i am sure there _are_ real programs that can fit entirely in the 68030's massive (:-) 256 byte data and instruction caches. i am sure there are a lot more real programs that can fit entirely in a 8k cache. i am sure that a lot of real programs will fit nicely in 32k-128k caches. i dont think it is necessary nor is it correct to make your benchmarks bust every sized cache. i think the SPEC approach is correct. use real programs that need a reasonable range of cache requirements, and let the user be the judge as to whether the SPECmark is applicable to the real programs that they want to run. -wayne