🚀 go-pugleaf

> 
> > 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
> > ----------
> 

My 2 cents:

The numbers presented by Sun indicated that they do use far fewer loads/stores
than MIPs, which they attribute to reg. windows. On the other hand, this
was not enough overall to change # of cycles to favor SPARC.

They indicate problems with long floats (lack of double ld/st) which hurt
FP performance a lot (presumably fixed in the R4000)

They purported to show that annulled branches were superior to inserting
NOPs after branching. I believe that argument is, well, flawed & misleading,
shall we say. Although it causes more insts. to be executed, it doesn't
cause more cycles to be spent. Sun argues that future versions of SPARCs
won't spend an extra cycle executing after annulling branches. I say that
whatever technique they use to do that can be applied to NOPs after a
branch (not to mention the addition of annulling branches to the MIPs
architecture which may be in the R4000)

They indicated a big win for MIPs by allowing FP<->Int reg moves instead of
going through memory.

Sun used an unreleased (at the time of the study) compiler vs. a released
compiler from Mips.

Overall: instead of +20% for SPARC, a -12%->25%. (Suns own numbers showed
about -12%. With the equivalent generation of Mips compilers, it could
be as much as -25%.

Is +-10% meaningful? Is +-20%? It depends who you ask. Supercomputer vendors
might go to great lengths for a couple of percent. When you get to workstation
prices, its a bit more academic.