🚀 go-pugleaf

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)