Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!mips!winchester!mash From: mash@mips.COM (John Mashey) Newsgroups: comp.arch Subject: Re: SPECs and DBMS Message-ID: <37102@mips.mips.COM> Date: 16 Mar 90 06:45:08 GMT References: <9951@spool.cs.wisc.edu> Sender: news@mips.COM Reply-To: mash@mips.COM (John Mashey) Organization: MIPS Computer Systems, Inc. Lines: 29 In article <9951@spool.cs.wisc.edu> shekita@provolone.cs.wisc.edu (E Shekita) writes: >> Except the cache properties of databases tend to be very different >> than those for the tests in SPEC. The instruction set size tends to >> be very large, and there is a high degree of contention for common >> data values, which causes a higher than expected data cache miss rate >> on multiprocessors. > >This is a good point that people sometimes overlook in this newsgroup. >The SPEC benchmarks do a great service, but most computer sales are for >transaction processing, not number crunching. I don't think the SPEC >benchmarks tell you much about how a system will do in a transaction >processing environment, where there is going to be heavy load on the >I/O system and really rotten cache hit ratios. As far as I can tell, no one involved in SPEC has ever claimed that any of SPEC Release 1.0 benchmarks predict anything at all with regard to transaction processing performance. At best, there might be some gross correlation between the integer benchmarks and transaction performance, but saying anything more than that (which, statistically, said almost nothing :-) awaits: a) getting definitive measures of transaction performance b) seeing if there is indeed any correaltion, and if so, how much. -- -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