shekita@provolone.cs.wisc.edu (E Shekita) (03/16/90)
> 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.
mash@mips.COM (John Mashey) (03/16/90)
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: <generic disclaimer, I speak for me only, etc> 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
jrg@Apple.COM (John R. Galloway Jr.) (03/16/90)
In article <9951@spool.cs.wisc.edu> shekita@provolone.cs.wisc.edu (E Shekita) writes: > >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. Wellll sort of. I am quite familar with the performance of both Informix and Oracle on Sequent systems (yes they do sell a lot of OLTP systems) as measured by the debit/credit benchmark (i.e. perhaps having nothing to do with "real" performance). Generally the systems are I/O limited, add more disks and it goes faster. You usually see little bus contention, but that can be misleading. Most benchmarks now are run with what Sequent calls "processor affinity", which binds a set of processes (usually front and backends) to a particular cpu. One might think (as I did) that this would be bad, since there is a good chance that a process that is ready to run won't even though another cpu might be idle. However just the oppisite is the case. Processor afinity offers 10-20% (if I remember correctly) greater overall performance, even though there IS 20% more cpu idle time. Looking at the bus one finds that there is a much higher percentage of "useful" bus activity due to a higher hit ratios (of code or data we don't know). It is apperently worth waiting for "your" cpu due to the increased likelyhood that your stuff will still be cached. Typically in these cases there are only 2 code segmetns active (the front end and the back end), a very large shared data space between backends and a significant private data space for both. So the lesson (I guesss) is that the question asked "How many processors does it take (in a DBMS env) to saturate the Sequent bus" is likely to simplistic a model. The bus typicall does not get satureated, yet improvements in cache hit rates still make a significant difference in system performance (again measured by debit/credit, now being obsoleted by the new TP1 standard being developed). -jrg -- internet jrg@apple.com John R. Galloway, Jr. applelink d3413 CEO..receptionist human (408) 259-2490 Galloway Research These are my views, NOT Apple's, I am a GUEST here, not an employee!!
rnovak@mips.COM (Robert E. Novak) (03/17/90)
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. The second SPEC BENCHATHON is wrapping up today. As of the time that I left, there were 6 programs that still appeared viable (they had successfully been ported and run on ten different architectures) as tests of I/O. As John Mashey already pointed out, we will need correlative data (perhaps through the efforts of the TPC). SPEC is not currently pursuing the topic of transaction processing for DBMS'. That work is best left to the TPC In addition to the I/O benchmarks, there are 2 graphics performance candidates and 2 multi-tasking candidates. Note that 2 graphics programs will not allow us to create a 'SPECgraph' measure of performance, but the SPEC members feel that it is important to get 'standard' copies of programs under the SPEC license control into the hands of as many people as possible. SPEC is currently shipping a little over 1 copy of the SPEC Suite Release 1.0 per day. As more and more people become aware of SPEC, we anticipate that that number will accelerate. (For more info on SPEC, please contact Waterside Associates @ 415-792-2901 or shanley@cup.portal.com)