Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!sdd.hp.com!hplabs!hpfcso!jvm
From: jvm@hpfcso.FC.HP.COM (Jack McClurg)
Newsgroups: comp.arch
Subject: Re: SPARC implementation or architecture
Message-ID: <8840030@hpfcso.FC.HP.COM>
Date: 22 Apr 91 15:58:57 GMT
References: <1991Apr17.183822.7681@elroy.jpl.nasa.gov>
Organization: Hewlett-Packard, Fort Collins, CO, USA
Lines: 34

> There is an interesting paper in the ASPLOS-IV proceedings that compares the
> MIPS and SPARC architecture and claims that SPARC actually executes
> significantly fewer instructions for a given set of benchmarks (SPEC).
> This would imply that it does not have an architectural disadvantage.
> 
> Does anyone who is familiar with that paper have any comments on it?
> 
> Michael Slater, Microprocessor Report  mslater@cup.portal.com
> ----------

One thing that struck me as strange about this paper was the data for the li
benchmark.  SPARC executes 4.7G instructions while MIPS executes 6G
instructions (29% more).  Recent published SPEC results show a 25MHz R3000
executes li in 270.5 seconds while a 40MHz SPARC executes li in 267.7 seconds.
This may be explained by the time difference (MIPS has improved their
compilers?), but I do not think so.  The authors of the paper made no attempt
to explain an obvious contradiction between what could be concluded from the
paper (SPARC runs li much faster) and reality (MIPS runs li much faster).  I
could postulate that since li has greater stack depth than the other
benchmarks, it shows some architectural differences between SPARC and MIPS
very plainly.  I was disappointed that the li results were not explained
better.

Although the paper is clearly intended to concentrate on instrucion
utilisation, I thought it would have been improved with cycles per instruction
data for each of the benchmarks.  This is important for benchmarks like
matrix300 where TLB misses dominate execution time hence instruction set
use is not very important.

The two things above were the few problems I had with the paper.  Overall I
thought that the paper was excellent.  It has myriad data.  The explanations
for the data are quite good.

Jack McClurg