Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!usc!apple!sun-barr!sun!chiba!khb From: khb%chiba@Sun.COM (Keith Bierman - SPD Languages Marketing -- MTS) Newsgroups: comp.arch Subject: Re: MIPS/MFLOPS ratio Message-ID: <112807@sun.Eng.Sun.COM> Date: 28 Jun 89 08:06:35 GMT References: <596@megatek.UUCP> Sender: news@sun.Eng.Sun.COM Reply-To: khb@sun.UUCP (Keith Bierman - SPD Languages Marketing -- MTS) Organization: Sun Microsystems, Mountain View Lines: 67 In article <596@megatek.UUCP> mark@megatek.UUCP () writes: >This seems a little out of whack... it seems that older scientific >processors had ratios in the 3-4 range. Current SPARC implementations (chips and system) from Sun were intended for "more general purpose use" hence the (relatively) narrow gap between integer performance on a Cray to a 4/330. While floating point is fun (and is typically my reason for existing on a project) I spend most of my day doing compiles, editing, runing schedtool, and other nonFP things. So using the 80-20 rule... the first machines should be the ones we need 80% of the time. > >Looking a published info on MIPS, and some hand waving gets me a ratio >of about 5-6, better but still slow (an aside: what are the MIPS guys >doing to get the speeds up higher than the SPARC guys? compilers?) Compilers is often stated, but according to my weeks of staring at huge volumes of data, it seems that the compiler differences are minimal on large codes. The current sun compilers are somewhat less clever about certain operations, but not enough to explain the difference in performance. What is interesting is that the benchmarks which SPARC does worst on are highly FP and memory intensive (say 30-50% loads and stores). MIPSco built their own FPU and tightly coupled it to their IU. This resulted in early units which were superior to the SPARC implementation philosophy (let's buy whatever is laying around and glue it in -- in the first implementations that meant a weitek 1164 and 1165 and a controller ... "leftovers" from the sun3/fpa project). At yesterday's IEEE HOT CHIPS conference, we were treated to three papers about dedicated SPARC FPU's in addition to the papers focused on FPU's BIT is already sampling ECL SPARC chips. So the FPU integration/implementation variable is tilting towards SPARC (unless one assumes that MIPSco is smarter than Ross, Fuji.,BIT, LSI, TI, Solb., Prisma and all the others. As for loads and stores current IMPLEMENTATIONS of SPARC use 2 and 3 cycle parts ... this is NOT part of the arch. but was a concession to low cost system design. High performance SPARC systems (i.e. those designed to use all the implementation tricks) are just now appearing (not anything we have announced :< but these "low performance" models are actually quite snappy ... a 4/330GX makes a VERY nice personal workstation). > >Why is the floating point lagging integer performance so much? What is >being done to get this back in balance? Well, ld/sto is key ... linpack is about as kind as it gets, and that is 1.5 memory references for every FLOP. Second, chips designed from the ground up to be SPARC FPU's rather than random bits of sand are just now available (weitek 3170 and 71 TMS390C602, LSI 64814 to name just 3). PRIMSA delievered a system level paper about their 250 MIPS (native, say 100vaxmips) 100Mflop SPARC machine. Not sampling just yet, but probably 2nd qtr next year (my guess, from the presentation; no solid info; last press release said a working machine in Jan ... but I assume that they might want to test it before shipping it :>). Keith H. Bierman |*My thoughts are my own. Only my work belongs to Sun* It's Not My Fault | Marketing Technical Specialist ! kbierman@sun.com I Voted for Bill & | Languages and Performance Tools. Opus (* strange as it may seem, I do more engineering now *)