Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!mips!apple!rutgers!uwvax!provolone.cs.wisc.edu!shekita
From: shekita@provolone.cs.wisc.edu (E Shekita)
Newsgroups: comp.arch
Subject: Re: SPECs and DBMS
Message-ID: <9951@spool.cs.wisc.edu>
Date: 16 Mar 90 06:05:16 GMT
Sender: news@spool.cs.wisc.edu
Lines: 24

> 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.

On a related tangent... Supposedly Sequents make pretty good machines for 
doing transaction processing. (In fact, I heard that 80% of their sales
are for transaction processing.) But I wonder how many processors it
takes to saturate their bus in such an environment. Probably not many 
because the cache hit ratio for data and instructions is going to be very 
low in a transaction processing system -- there's almost no locality at all.
And looking at the the performance curve of micros, you have to wonder how 
many processors it will take to saturate a Sequent bus in, say, four years 
in such an environment? Eight processors? Four? Over the long run, I think 
shared-nothing configurations (like Tandem offers) will prevail for 
transaction processing systems.