Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!brutus.cs.uiuc.edu!jarthur!bridge2!mips!winchester!mash From: mash@mips.COM (John Mashey) Newsgroups: comp.sys.m88k Subject: Re: DG's use of m88k Message-ID: <36461@mips.mips.COM> Date: 26 Feb 90 21:44:02 GMT References: <7521@imag.imag.fr> Sender: news@mips.COM Reply-To: mash@mips.COM (John Mashey) Organization: MIPS Computer Systems, Inc. Lines: 55 In article tom@ssd.csd.harris.com (Tom Horsley) writes: >In article <7521@imag.imag.fr> despoix@imag.imag.fr (Frederic DESPOIX) writes: >> Benchmark numbers are relative to VAX 11/780 = 1.0, so higher numbers are >> better. The programs gcc, espresso, spice, doduc, nasa7, ll, eqntolt, >> matrix300, fpppp and tomcatv are real programs, not synthetic or toy codes. >> The SPECmark is the geometric mean of the ten benchmark programs (the Nth >> root of the product of the membmers of a list with 10 members). >If you believe that all these benchmarks are real programs and not toys you >have been reading SPEC literature, not the benchmark source. Matrix300 >spends 99.99% of its cycles in a single line of code, even Whetstone is a >better benchmark than this. Espresso is not much better, spending 90% of its >time in the compare routine it passes to qsort(). >> If someone could supply more information about each benchmark, and each >> system (cache size, CPU clock rate, etc), that might prove enlightening. > >There are lots of different clock rates/cache sizes/compilers out there. >This is the information you are supposed to pay hundreds of dollars to get >from SPEC. > >One thing that is worth noting is that ALL of the floating point benchmarks >are strictly double precision, and double precision is somewhat slow on the >88100 architecture implementation because internal paths are only 32 bits >wide. > >There are quite a lot of applications areas that do not need double >precision (graphics processing is often a good example, when you only need >to map images onto a screen 1000 pixels wide, double precision is overkill). >The SPEC benchmark suite needs to have at least one or two single precision >benchmarks added to give it a better balance. (I am quite aware that there >are also applications requiring double precision, I just want to see some >single precision numbers in SPEC, don't tell me I claimed no one need double >precision). All these criticisms are well-taken, althought the programs are either real ones, or derived kernels from real ones where the bulk of the time is spent in small loops (that's the way many scientific codes really are). There is no doubt that some of the ones that are there will drop out sooner or later as we find better ones; the point of this exercise was to start getting some real data out into the open that people could pound away at, get a good process in place, and start making progress. With regard to single-precision: we'd love to have some, and I suspect there are some on the list of candidates; nobody could find one fast enough for the first round that could make it thru all the rest of the criteria, whereas we had 64-bit ones in plenty. We welcome more people joining and doing work..... -- -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