Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!mash From: mash@mips.com (John Mashey) Newsgroups: comp.arch Subject: Re: SPARC implementation or architecture Message-ID: <2637@spim.mips.COM> Date: 24 Apr 91 18:21:07 GMT References: <1991Apr17.183822.7681@elroy.jpl.nasa.gov> <8840030@hpfcso.FC.HP.COM> <51942@apple.Apple.COM> Sender: news@mips.COM Organization: MIPS Computer Systems, Inc. Lines: 53 Nntp-Posting-Host: winchester.mips.com 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: 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