🚀 go-pugleaf

In article <51942@apple.Apple.COM> baum@apple.com (Allen Baum) writes:
>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)
Yes, and in R6000.
>
>branch (not to mention the addition of annulling branches to the MIPs
>architecture which may be in the R4000)
Yes, and in R6000.
>
>Sun used an unreleased (at the time of the study) compiler vs. a released
>compiler from Mips.
P.S.  I have no problem with them using an unreleased compiler,
and certainly they couldn't get our unreleased compiler.  It would have been
nice had such a caveat appeared in the paper ....  because, this is a
perfect example of the necessity of appropriate caveats to obtain
defendable conclusions, i.e., the paper in question analyzed the
question "How does SPARC with current compilers compare with MIPS
with 1-year old compilers?" and got some answers. I analyzed the
question "How do MIPS and SPARC compare with both having current
compilers?" and got a different answer.

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

Note that the paper was about INSTRUCTION COUNTS, which is not the same
as performance.  Also, note that people used to fight pretty hard over
10-15% differences on 2-mips products, and if you get 10-15% on 20 ... or 50,
you're talking about adding/subtracting a 386 or 68030's worth of
performance, which is pretty amusing, when you think about it.
Why it may or may not be relevant to workstations, is that sometimes
interactive code has some minimum requirement for speed, or lese people
won't tolerate it. If a compiler boost makes the difference,
then it's very relevant.

Finally, once again, it is good to see such analyses of substantial
chunks of code, rather than tinker-toys.  Everybody should be reminded to
include careful caveats about the dates of software, to avoid naking
general conclusions that are clearly invalidated by software releases
that happen simultaneously with the paper.
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	 mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash 
DDD:  	408-524-7015, 524-8253 or (main number) 408-720-1700
USPS: 	MIPS Computer Systems MS 1/05, 930 E. Arques, Sunnyvale, CA 94088-3650