Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!nrl-cmf!ukma!rutgers!att!mtuxo!mtgzz!drutx!druhi!cosmos
From: cosmos@druhi.ATT.COM (Ronald A. Guest)
Newsgroups: comp.arch
Subject: Re: SPARC vs. MIPS on gcc
Keywords: SPARC, MIPS
Message-ID: <3779@druhi.ATT.COM>
Date: 20 Dec 88 15:05:10 GMT
References: <82150@sun.uucp> <697@hscfvax.harvard.edu>
Organization: AT&T, Denver, CO
Lines: 24

In article <697@hscfvax.harvard.edu>, pavlov@hscfvax.harvard.edu (G.Pavlov) writes:
> In article <82150@sun.uucp>, edkelly%aisling@Sun.COM (Ed Kelly) writes:
> > 
> >             A COMPARISON OF SPARC VS MIPS ON A LARGE C PROGRAM.
> > 
> > For the comparison we chose a large portable C program (the GNU C Compiler rev
> > 1.24) and compiled the identical source on a Sun-4/280 with the SPARC compiler
> > to produce a SPARC binary, and on a MIPS M/1000 with the MIPS compiler to 
> > produce a MIPS binary.              ^^^^^^^^^^^
> 
>   Why did you not use a current-generation MIPS in the comparison ???

I agree.  Trying to pick the same clock rate is bogus.  What customers care
about is what they can get their hands on today.  MIPS has both a M/120 and
an M/2000.  Somehow I think if you had used an M/2000 you would have gotten
different performance results.  I could care less about subjective measures
of architectural nicety, since I am a CPU user.  What I care about is cost
and performance.  And who said a compiler was a good benchmark?  Is this the
only public program you did this test on?  Doesn't really matter, I suppose.
The mud-slinging does make this one of the more interesting 'technical' new
groups!

Ronald A. Guest, Supervisor     cosmos@druhi.ATT.COM  or  att!druhi!cosmos
AT&T Bell Laboratories          <--- but these are my thoughts, not theirs
12110 N. Pecos St.              Denver, Colorado 80234          (303) 538-4896