Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!deimos!uxc!uxc.cso.uiuc.edu!mcdurb!aglew From: aglew@mcdurb.Urbana.Gould.COM Newsgroups: comp.arch Subject: Re: SPARC vs. MIPS on gcc Message-ID: <28200254@mcdurb> Date: 17 Dec 88 20:16:00 GMT References: <82150@sun.uucp> Lines: 75 Nf-ID: #R:sun.uucp:82150:mcdurb:28200254:000:3172 Nf-From: mcdurb.Urbana.Gould.COM!aglew Dec 17 14:16:00 1988 Wow! I suppose Ed Kelly has started a performance analysis war between MIPS and SUN. Don't worry, I'm not getting into it - I'm new enough in Motorola that I don't want this much exposure just yet. :-( Ed, can you give us any floating point comparisons between SPARC and MIPS? I'm sure someone from MIPS will make a detailed response. Me, I just want to ask a few questions: >loads 3,242,293(19.9%)3,928,710(21%) +686,417 >stores 1,175,530(7.2%) 2,037,266(10.9%)+861,736 Phew! Now I'll expose how new I am at this game by giving a big sigh of relief. I had to do some explaining a while back about why my measurements were showing load/store ratios of 2-2.5:1, as opposed to the 3:1 everyone KNEW was the typical ratio of loads/stores. (NB. this was not On an 88K. I cannot report any 88K data.) Investigation showed that many of the extra stores were in register saves - which may also be shown by the above difference between the SPARC with register windows and the MIPS without. Does anyone at MIPS have breakdowns for their load/store traffic according to purpose? > The bottom line about NOPs is SPARC is better due to the annulling >ARCHITECTURE feature. Just so long as annulling doesn't cost you anything in cycle time. As I am sure everyone will point out. >instructions 16,313,907 18,635,185 >----------------------------------------------------------- >total raw cycles 25,522,476 18,999,172 > >cache miss cycles 4,427,524* 14,000,828* >----------------------------------------------------------- >total machine cycles 29,950,000 33,000,000 Well, I'm afraid that I don't see these numbers as expressing a fundamental difference between the two processors. Architecturally SPARC wins out with fewer instructions. Implementationally (is that a word?) MIPS wins out with fewer cycles - but SPARC might always be implemented with fewer cycles per instruction (but then, so might a VAX :-). SPARC takes fewer cache misses, due to register windows and better code density - but it is always possible that in a future version of MIPS a better memory system, possibly in the form of a large on-chip cache using the space that register windows occupies, might win this back (one of my favorites is caching the first word of every cache lines on chip, with the rest off-chip -- but then, I was thinking about vector processing mostly in my last job (that's head of vector caching)). Finally, for the next step in microprocessor architectures, I'd guess that it would be easier to dispatch more than one at once of MIPS' instructions, rather than SPARC's comparatively complex instructions (addressing modes and condition codes are a bitch). Once again, before the wars start - I'd like to thank Ed Kelly for presenting this data. Andy "Krazy" Glew aglew@urbana.mcd.mot.com uunet!uiucdcs!mcdurb!aglew Motorola Microcomputer Division, Champaign-Urbana Design Center 1101 E. University, Urbana, Illinois 61801, USA. My opinions are my own, and are not the opinions of my employer, or any other organisation. I indicate my company only so that the reader may account for any possible bias I may have towards our products.