bs@gauss.mitre.org (Robert D. Silverman) (12/10/90)
Does anyone have any experience with the (very) new Sparcstation/2? How does it compare with other SUN-4's and the Sparc/1+??? I understand this new Sparc had hardware integer multiply/divide. What other differences are there? How are the MMU and cache different? Any info will be appreciated. -- Bob Silverman #include <std.disclaimer> Mitre Corporation, Bedford, MA 01730 "You can lead a horse's ass to knowledge, but you can't make him think"
andras@alzabo.uucp (Andras Kovacs) (12/14/90)
Some data about the SPARCstation 2 Series (SUN info):
Processor performance: 21 SPECmarks (28.5 MIPS & 4.2 MFLOPS)
Floating point unit: SPARC IEEE standard 764
Cache: 64 KB
Memory management: Sun-4(tm) MMU
I/O interface: DVMA
Contexts: 16 in hardware (could someone tell me what is this about?)
Page mapped entry groups: 256 PMEGs
System bus type: SBus (32/32 address/data bus width)
I hope this helps...
--
Andras Kovacs
andras@alzabo.UUCPgillies@m.cs.uiuc.edu (12/17/90)
I think it's a laugh that Sun quotes "28.5 mips". That's 28 usable mips for normal every-day jobs, and .5 mips for the background task that emulates a vax/11-780 at half speed for pedagogical reasons. Seriously, who cares about this extra .5 mips? Why not 29 mips? Why not 28 mips? BUT NOOOOOOO 28.5 mips. Be precise. After all a "MIPS" is such a precise quantity anyway. Sheesh. This tells me Sun doesn't know anything about "significant digits". Am I going to buy a computer by a company that doesn't know about "significant digits"? How can I be sure the floating point will work properly if the company displays blatant ignorance of this notion in their advertising???!!!!!
mash@mips.COM (John Mashey) (12/18/90)
In article <3300233@m.cs.uiuc.edu> gillies@m.cs.uiuc.edu writes: > >I think it's a laugh that Sun quotes "28.5 mips". That's 28 usable >mips for normal every-day jobs, and .5 mips for the background task >that emulates a vax/11-780 at half speed for pedagogical reasons. > >Seriously, who cares about this extra .5 mips? Why not 29 mips? Why >not 28 mips? BUT NOOOOOOO 28.5 mips. Be precise. After all a "MIPS" >is such a precise quantity anyway. > >Sheesh. This tells me Sun doesn't know anything about "significant >digits". Am I going to buy a computer by a company that doesn't know >about "significant digits"? How can I be sure the floating point will >work properly if the company displays blatant ignorance of this notion >in their advertising???!!!!! These are, of course, Dhrystone-mips anyway.... hence, not only is the .5 useless, the whole number is mostly useless :-) Give them credit for supplying the SPEC numbers, thank goodness... -- -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, 930 E. Arques, Sunnyvale, CA 94086
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (12/18/90)
In article <3300233@m.cs.uiuc.edu> gillies@m.cs.uiuc.edu writes: | Seriously, who cares about this extra .5 mips? Why not 29 mips? Why | not 28 mips? BUT NOOOOOOO 28.5 mips. Be precise. After all a "MIPS" | is such a precise quantity anyway. You're right! I don't care about the extra .5 MIP. It doesn't offend me at all... Although I don't have the material at hand, I thought the figure was 28.5 SPECmarks. Now while I'm not offended by the idea of meaningless MIPS meaningless SPECmarks... well I don't much care about that either. What's the big deal? Data should be reported to some approximation of the reproducibility of their measurement. Can SPECmarks be measured closer than one part in 28? If so why not report the value measured? Maybe you can get some rightious indignation in the benchmarks group, but I doubt that either. I would consider publishing the extra digit of reported results about as important as the colors used for the yearly report to stockholders. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) VMS is a text-only adventure game. If you win you can use unix.
jdn@misc.Eng.Sun.COM (Jeff Nisewanger) (12/18/90)
In article <3300233@m.cs.uiuc.edu> gillies@m.cs.uiuc.edu writes: > >I think it's a laugh that Sun quotes "28.5 mips".... > >Seriously, who cares about this extra .5 mips? .... > >Sheesh. This tells me Sun doesn't know anything about "significant >digits". Am I going to buy a computer by a company that doesn't know >about "significant digits"? How can I be sure the floating point will >work properly if the company displays blatant ignorance of this notion >in their advertising???!!!!! I seem to recall seeing large IBM ads quoting 27.5 mips. -- Jeff Nisewanger ARPA: jdn@Eng.Sun.COM Window Systems Group UUCP: ...!sun!jdn Sun Microsystems, Inc. 415/336-5743
chased@rbbb.Eng.Sun.COM (David Chase) (12/18/90)
davidsen@crdos1.crd.ge.com (bill davidsen) writes: > Although I don't have the material at hand, I thought the figure was >28.5 SPECmarks. Nip this rumor in the bud, please. 21 SPECmarks for the SS2, using the beta compilers. David Chase Sun Microsystems
colwell@omews1.intel.com (Robert Colwell) (12/18/90)
>In article <3300233@m.cs.uiuc.edu> gillies@m.cs.uiuc.edu writes: >> >>I think it's a laugh that Sun quotes "28.5 mips".... >> >>Seriously, who cares about this extra .5 mips? .... Don, c'mon, that 0.5 is very meaningful. It makes it easy to compare this machine to the VAX-11/780 -- throw the 0.5 away, and what's left is the excess horsepower vs. the VAX. :-) Bob Colwell mipon2!colwell@intel.com 503-696-4550 Intel Corp. JF1-19 5200 NE Elam Young Parkway Hillsboro, Oregon 97124
hunter@oakhill.UUCP (Hunter Scales) (12/18/90)
Is there any truth to the rumor that the CPU has a Peltier
device (i.e. IceCap) to cool it?
--
Motorola Semiconductor Inc. Hunter Scales
Austin, Texas {harvard,utah-cs,gatech}!cs.utexas.edu!oakhill!hunter
#include <disclaimer.h>dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) (12/18/90)
In <3300233@m.cs.uiuc.edu> gillies@m.cs.uiuc.edu writes:
I think it's a laugh that Sun quotes "28.5 mips".... Sheesh.
This tells me Sun doesn't know anything about "significant
digits".
Assuming an uncertainty of 1.0, It's just as valid to say 28.0 +/- 1.0
as to say 28.5 +/- 1.0. But if the best available estimate is 28.5
rather than 28.0, then it's more accurate (and less misleading) to say
28.5 rather than 28.0 or 28.
The questions you should be asking are: (a) What is the uncertainty in
the quoted MIPS figure, and (b) why didn't Sun specify that too?
What if the best available estimate, based on (say) LINPACK, *is*
indeed 28.5 rather than 28?
(Actually Sun's MIPS figures assumes a better C compiler. The MIPS
rating using the SunOS 4.0.3 C compiler is closer to 24. This is the
rating you should use when comparing various Sun machines, because all
Suns will soon be running the same C compiler that the SPARCstation-2
comes with.)
--
Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com>
UUCP: oliveb!cirrusl!dhesichrism@phoenix.mips.com (Christopher Marino) (12/18/90)
: > In article <3300233@m.cs.uiuc.edu> gillies@m.cs.uiuc.edu writes: > > > >I think it's a laugh that Sun quotes "28.5 mips".... > > > >Seriously, who cares about this extra .5 mips? .... Actually, there are quite a few people that do.................. > > > >Sheesh. This tells me Sun doesn't know anything about "significant > >digits". Am I going to buy a computer by a company that doesn't know > >about "significant digits"? How can I be sure the floating point will > >work It seems to me that you are confusing significant figures in the mathematical sense with figures that you feel are significant. The SPEC ratio is the ratio of execution times compared to a VAX and can me measure quite accurately. Although I understand your position about the "significance" of the tenth of a SPECmark, I would much rather have more info than less.
khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) (12/18/90)
In article <4350@cerberus.oakhill.UUCP> hunter@oakhill.UUCP (Hunter Scales) writes:
Is there any truth to the rumor that the CPU has a Peltier
device (i.e. IceCap) to cool it?
Not in mine. Looks very much like my old 4/65, unless you look
closely.
.....someone else
Floating point unit: SPARC IEEE standard 764
754. The 64 was a typo introduced by the printers, or marketing, or
someone else ;> To the best of my knowledge there isn't a IEEE 764
binary floating point standard with which to be compatible.
--
----------------------------------------------------------------
Keith H. Bierman kbierman@Eng.Sun.COM | khb@chiba.Eng.Sun.COM
SMI 2550 Garcia 12-33 | (415 336 2648)
Mountain View, CA 94043it1@ra.MsState.Edu (Tim Tsai) (12/18/90)
>In <3300233@m.cs.uiuc.edu> gillies@m.cs.uiuc.edu writes: > I think it's a laugh that Sun quotes "28.5 mips".... Sheesh. > This tells me Sun doesn't know anything about "significant > digits". You are wrong.. The rating is 28.48123861234561234123441234123412342341 mips and rounded to 3 significant digits, hence 28.5.. I think Sun does know about significant digits.. Ha, just kidding.. I couldn't resist.. -- Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us. <Calvin>
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (12/18/90)
In article <4627@exodus.Eng.Sun.COM> jdn@misc.Eng.Sun.COM (Jeff Nisewanger) writes: | I seem to recall seeing large IBM ads quoting 27.5 mips. Please hold IBM bashing until January. That's when it's due to come around again. ;-) -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) VMS is a text-only adventure game. If you win you can use unix.
rro@debussy.cs.colostate.edu (Rod Oldehoeft) (12/19/90)
In article <44137@mips.mips.COM> mash@mips.COM (John Mashey) writes: >In article <3300233@m.cs.uiuc.edu> gillies@m.cs.uiuc.edu writes: >> >>I think it's a laugh that Sun quotes "28.5 mips". That's 28 usable >>mips for normal every-day jobs, and .5 mips for the background task >>that emulates a vax/11-780 at half speed for pedagogical reasons. >> ... text deleted ... > >These are, of course, Dhrystone-mips anyway.... hence, not only is >the .5 useless, the whole number is mostly useless :-) >Give them credit for supplying the SPEC numbers, thank goodness... Here's a small gotcha. The quoted performance numbers for a SPARC II (28.5 MIPS, 21 SPEC) are obtained by using the optional optimizing compiler, Sun C 1.1, instead of the bundled compiler. Cute. Anyone know the SPEC value using the default software? Rod Oldehoeft Email: rro@cs.colostate.edu Computer Science Department Voice: 303/491-5792 Colorado State University Fax: 303/491-2293 Fort Collins, CO 80523
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (12/19/90)
In article <11772@ccncsu.ColoState.EDU> rro@debussy.cs.colostate.edu (Rod Oldehoeft) writes: | Here's a small gotcha. The quoted performance numbers for a SPARC II | (28.5 MIPS, 21 SPEC) are obtained by using the optional optimizing | compiler, Sun C 1.1, instead of the bundled compiler. Cute. Is there some vendor who doesn't use the best compiler, largest cache, etc, when running benchmarks? As long as the conditions of test are given I don't have a problem with it. If some hardware or software not available to the public is used, or is used and not disclosed, then I think there's reason to complain. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) VMS is a text-only adventure game. If you win you can use unix.
mash@mips.COM (John Mashey) (12/20/90)
In article <3065@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) writes: >In article <11772@ccncsu.ColoState.EDU> rro@debussy.cs.colostate.edu (Rod Oldehoeft) writes: > >| Here's a small gotcha. The quoted performance numbers for a SPARC II >| (28.5 MIPS, 21 SPEC) are obtained by using the optional optimizing >| compiler, Sun C 1.1, instead of the bundled compiler. Cute. > > Is there some vendor who doesn't use the best compiler, largest cache, >etc, when running benchmarks? As long as the conditions of test are >given I don't have a problem with it. And neither does SPEC: this is perfectly legitimate on Sun's part, and is properly documented, as far as I can tell. Of course, it IS important for users to understand the differences, and not confuse numbers of various kinds: TIME axis: a) The numbers you get if you run them on the machine you have today. b) Numbers you'll get on a machine available X months from now. c) Numbers you'll get on a machine you have today, but later, when/if you get the next compiler release. VERSION axis: d) Numbers you'll get on a machine you have, but only if you buy a particular compiler. Everybody has to deal with the time axis. Fortunately, after the first few releases of a system, the change rate due to compilers slows down, although the SPEC results do show that even excellent compilers actually continue to improve. The VERSION axis is rather different, as there is a range of distinct cases: 1) One compiler: as in VAX/VMS, other proprietary systems, almost all MIPS-based systems, etc, there is effectively one standard compiler family, and that's what almost every binary in the world has been compiled with, and so the numbers are pretty representative. 2) Two compilers: the Sun case. Clearly, you'd want to get the difference calibrated to use as a rule-of-thumb, and this would probably not be too hard. I'd guess that Sun-provided software would use the better compiler. I'd assume at least some of the ISVs would also. I'd guess 88K case is also close, as I've seen just a few vendors. 3) Many compilers: 68K, and ESPECIALLY X86. (I say this because for whatever reason, there seemed to be less 68K compilers that you might find on a random 68K box, perhaps because many vendors (Sun, Apollo, HP) had their own compilers on own boxes). Maybe somebody can offer some comments here: I'd guess there is quite a large range in the delivered numbers among commercial products. What I can't tell is: a) How big is the range, reallY? b) Are the numbers published from the best ones they could find (probably)? c) Which compilers are mostly used out there, and what kinds of results do THEY give? I.e., if you buy software packages, were they compiled with the best-optimizing compilers, or with ones that were faster compiling, had better debugging environments, or supported various features that might not necessarily be available in the best optimizers? > If some hardware or software not available to the public is used, or >is used and not disclosed, then I think there's reason to complain. The SPEC rules were set up to try to do this, with the caveat that it was OK to gives numbers for something that was not yet available, as long as there was a date given. People should read the dates carefully, of course, but I think we've at least gotten out of the game of seeing numbers for laboratory "hot boxes" with compilers that might never be released. It is a typical practice that people report results for compilers that will actually hit the market in a few months, and I'd argue that this is OK (as long as people watch it), in that a number tends to stick for a while, and if you're going to be able to buy it in a few months, it usually means that: a) The compiler group actually froze it a while back b) It's been in QA for a while c) The compiler group is actually working hard on the next round Anyway, to summarize: Sun IS playing by the rules on this one. If customers also want to get the bundled-compiler numbers, they should tell Sun so, or run them themselves. -- -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, 930 E. Arques, Sunnyvale, CA 94086
anderson@lynx.cat.syr.edu (Joseph Anderson) (01/13/91)
In article <2810@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: >In <3300233@m.cs.uiuc.edu> gillies@m.cs.uiuc.edu writes: > > I think it's a laugh that Sun quotes "28.5 mips".... Sheesh. > This tells me Sun doesn't know anything about "significant > digits". > >Assuming an uncertainty of 1.0, It's just as valid to say 28.0 +/- 1.0 >as to say 28.5 +/- 1.0. But if the best available estimate is 28.5 >rather than 28.0, then it's more accurate (and less misleading) to say >28.5 rather than 28.0 or 28. > Um, stating the 0.5 means variation at that level; if the error were +/-1 then it would have been state 28.; they stuck their advertising necks out for 0.5 +/-0.1 mips, let them prove they can accurately measure out to +/- 0.5 mips anderson@cat.syr.edu =/- edn