Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!usc!elroy.jpl.nasa.gov!ncar!acd!pack From: pack@acd.acd.ucar.edu (Dan Packman) Newsgroups: comp.benchmarks Subject: Re: SPECmarks Message-ID: <9135@ncar.ucar.edu> Date: 9 Nov 90 21:25:53 GMT References: <1990Nov9.012540.28546@aplcen.apl.jhu.edu> <4de7f24e.20b6d@apollo.HP.COM> Sender: news@ncar.ucar.edu Reply-To: pack@acd.UCAR.EDU (Dan Packman) Distribution: comp Organization: Atmospheric Chemistry Division/NCAR, Boulder CO Lines: 40 In article mutchler@zule.EBay.Sun.COM (Dan Mutchler) writes: >... >Well, maybe...If a the two systems X and Y have fairly balanced >performance then the single number is reasonable, but a current >example is the RS/6000. It comes in at 27 SPECmarks for the geometric >mean, but that is due largely to fantastic floating point performance >on vectorizable code. A user that does little floating point will find >that the integer portion of the system is about 15 SPECmarks, making >it much closer to its competitors. > >I agree with the original SPEC position. Look at all ten numbers and >only use the ones that mean something to your application. The boiled >down number can be just as misleading as MIPS. > >-- > >Dan Mutchler | ARPA/Internet: mutchler@zule.EBay.Sun.COM >Sun Federal System Engineer | UUCP: ...!sun!mutchler >-------------------------------------------------------------------------- Excellent point. The best benchmark is clearly ones own application or set of applications including multi-process loads. One nitpick is that the RS/6000 is not 'vectorizing' but pipelining operations. Typically the block-mode algorithms in LAPACK allow better vectorization on vector machines and better cache hit rates on scalar machines. This is presumably true of the more 'vectorizable' parts of the SPEC suite. Of some interest to me is that SUN products seem not to improve in performance with the new LAPACK versus the old linpack code where all other scalar machines I have tested do show at least a 20% speedup. Does this mean that SUN manages 100% cache hit rates on the old code? Or is there something specific to SPARC architecture here? Ideas? Dan Dan Packman NCAR INTERNET: pack@ncar.UCAR.EDU (303) 497-1427 P.O. Box 3000 CSNET: pack@ncar.CSNET Boulder, CO 80307 DECNET SPAN: 9.367::PACK