Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!sun-barr!newstop!sun!chiba!khb From: khb%chiba@Sun.COM (chiba) Newsgroups: comp.arch Subject: Re: MIPS/MFLOPS ratio [long; here we go again; sorry] Message-ID: <114015@sun.Eng.Sun.COM> Date: 6 Jul 89 18:56:02 GMT References: <596@megatek.UUCP> <112807@sun.Eng.Sun.COM> <22792@winchester.mips.COM> Sender: news@sun.Eng.Sun.COM Reply-To: khb@sun.UUCP (chiba) Organization: Sun Microsystems, Mountain View Lines: 304 In article <22792@winchester.mips.COM> mash@mips.COM (John Mashey) writes: >1. INTRODUCTION > >In article <112807@sun.Eng.Sun.COM> khb@sun.UUCP (Keith Bierman - SPD Languages Marketing -- MTS) writes: > >1) Some comments about SPARC integer-vs-floating point that seem to >rewrite history from before when keith was at Sun, Fellow asked a question, I "reverse engineered" history as best I could. It is true that while RISC revolution was starting I was off doing Kalman filtering. > as well as some comments >about Hot Chips that need some balancing comments (which you can take either as>objective data, or as opposite-bias opinions; your call). The bulk of my posting was simply the schedule. The editoral comments were quite slight. A 400+ line rebuttal seems a bit of overkill. > >2) ``So the FPU ... >Marketing B.S. doesn't make something ("tilt") true; only being true makes >it true; in any case, in my opinion, the logic (only if MIPS smarter is there >no tilt towwards SPARC) is flawed, and I'll show why. Counted number of chip houses, etc. BIT is shipping ECL SPARC samples ... >------- >The following are quotes from the July 87 Sun-4 introductory material: >``Relative to other manufacturer's high-end offerings, >the Sun-4/200 excels in floating-point performance. Marketing hype is marketing hype. A Sun4/2xx was much faster for FP than a VAX. It was not as key to the design as, say, a Cray YMP. >3. FP PRESENT, INCLUDING COMPILER ISSUES >At least one SPARC architectural difference was described by Tom Pennelo of >Metaware at Hot Chips, but khb failed to mention: >passing FP arguments in the integer registers, and not having >direct moves to/from IU and FP, means that (in C, at least), >saying y = glurp(x), with floats x,y, gives you something like: Tom's point was well taken if: 1) Most FP codes pass by value rather than by address 2) If one wants to penalize machines w/o FP hardware a lot,vs. w/FP a bit 3) there wasn't an effective ABI in place ("offical" or not, solb. code etc. does run on a Sun, and visa versa). Clearly using the FP registers would be better. How much better depends on your model of the execution universe. Fortran codes (where FP is king) are all pass by address (language semantics) so until f88 or mass conversion to c++ this is not the huge issue portrayed. >I have no idea how often this happens; fortunately for SPARC, FORTRAN is >call-by-reference. Note also that conversions from int<->float go >thru a similar drill (which is truly architectural, not architecture+ >language convention, like the previous example, which, if not architectural >is probably so wired into things it would be nontrivial to change.) The convention is changable. The problems are more "political" than technical. If the statistics show that the convention should change, I have do doubt that it will. The int<->float is architectural, but there are few statistics to indicate that this is a serious bottleneck in SPARC performance. > 1) The SPARC multi-cycle loads and stores, which is is not ISA, > but SYSTEM architecture and implementation. agreed. I thought I made this clear. > 2) The MIPS FPUs have lower cycle counts. agreed, I thought the point of all those FPU talks we sat through was that SPARC cycle counts were dropping quite rapidly (new TI divide, sqrt, for example). > 3) The compiler thing is an open question; I haven't looked at > much SPARC FP code lately, so I don't personally know. Maybe > some UNBIASED third-parties would care to comment and give some DATA. My job is to break'em not build 'em. So I am relatively unbiased. Data will follow as time permits. > >4. ANALYSIS OF "TILTING TOWARDS SPARC", INCLUDING HOT CHIPS >4.2 WHAT MASH SAYS >Sigh. What does "tilting towards SPARC" mean? Does it mean that >SPARC is getting ahead, or might be catching up ("tilting back towards >parity")? I'm tired of this, but I can't let this >argument go past.... I believe SPARC is getting closer, but that doesn't >mean "tilting towards SPARC". Assuming BIT's marketing numbers are true (idealized assumption) they are shipping samples of 14Mflop DP linpack chips now. I am not in chip design. I am not in workstation design. Sun may or may not be using such chips. But sampling now at 14Mflops samples now are faster than MIPSco samples. >other machines, including early MIPS M/500s (before R2010s existed). >I'd use existing parts to get started, too; in fact, we did. >The original SPARC team was small, and didn't have infinite resources, >so this was all perfectly reasonable. In retrospect, [OPINION], the >only problem was in not having somebody going like crazy to build a >serious CMOS SPARC FPU early enough, and I have no idea whether somebody true. Wish we had someone like you with a bat to force 'em. >2) OPINION: The BIT+Sun ECL design looks well-done, with some reasonable >and informed thinking in many places. Maybe before SPARC victory is declared >by khb on the ECL front we maybe ought to wait for the first actual ECL systems >to be shipped, It was a chip conference. Not a systems conference. >3) OPINION: Pete Wilson's Prisma talk was delightful and fascinating; I admit >that MIPS is not, to my knowledge, building a GaAs supercomputer of >the $500K-$1M ilk, so I wish them well. Neither are we (I think). So we too wish them well. >4.4 HOT CHIPS, CMOS FPU SESSION >khb: "treated to three papers" > >FACT: we had a session with 3 CMOS SPARC FPUs (Weitek, TI, LSI), >followed by Earl Killian of MIPS. The session chair introduced Earl as someone >who would not talk about a SPARC FPU. This comment elicited a >noticable round of applause from the audience..... perhaps khb would >comment on that reaction to a "treat". I applauded also. I went to hear about non-SPARC stuff. So much of the audiance is already involved in SPARC that few really wanted to hear about the pin-outs again. > a) Gather all of the ACTUAL cycle counts of these various chips, > and put them in a table like the LSIL speaker showed, and post it here. > (This is data is clearly publicly available, I think.) Since Sun isn't in the business of using all known chips, and I am already working 16 hour days, and because the data is publicly available, I am not going to undertake that survey just know. Sorry John. > b) Give a clear description of the overlap characteristics of these > chips. I think most of them overlap {add/sub/conv, mul/div/sqrt, and > load/store}, and I don't think any of them are pipelined, but I > could be wrong. Again, a job for the chip vendors (at least until Sun announces products based on given chips). > c) Give a terse, clear description of these chips in terms of which > ones are used in which currently-public SPARC systems, and dispel any > confusion about already-cited benchmark numbers. [When I read the > trade press, I get confused, because they talk about things like > shipping some SS1s with TI parts, but enough WTL parts are now available > to use them instead, and I have no idea if that's press error, or real, > and if real, what difference it would make.] Sun ships wtl1164/65 old sun4/110 sun4/2xx TI8847 aka FPU2 current sun4/110, sun4/2xx wtl1170 SS-1 TI8847 SS-330 Since many of the chips are pin compatible, numbers with funny combinations are typically real. Just take out your toolkit ...:> > d) If there REAL benchmarks, or even simulations of the performance > of these things that exist somewhere public, point us at them. Rag on the chip houses. Or simply buy a machine and a chip and run your real codes. It is what we do for our customers .... > >MIPS: >of handcoded LINPACK inner loop peak performance, sometimes offered >in tables comparing them with measured LINPACKs on real machines.... >In fact, I think that only a few of the cycle counts on these >parts are better than the corresponding R3010 ones. All of them suffer the >(SPARC architectural) lack of direct data path between CPU & FPU. >Again, if khb, or somebody would post the actual cycle counts, we can see >whether my belief has any validity.) A posting with some of that data is forthcoming. > >Maybe they will, maybe they won't, but I'd suggest, that to add some >credibility, I'd ask for the following DATA: > 0) Talk about synchronizing the CPU and FPU at these speeds. > Do you have PLL's, or some other technique, or magic? > 1) What are the access times of the SRAMs needed to > run at 30ns, 25ns, and 20ns cycle times? (Some of these parts > were claimed to scale to 50Mhz, so the 20ns is relevant.) > 2) What are the sizes, part-numbers, costs, and availability > of those parts, and how many do you need? > 3) What are the rest of the pieces that you need to > run at those speeds? and when can you really get them? Does Macy's tell Gimbels ? C'mon John, why didn't you ask the chip vendors who were presenting ? >Basically, to use the RISCar metaphor, these are simple questions >to see if a million-RPM engine can actually be put into a >{buildable, sellable, maintainable} car, or whether the engine slows down. Since BIT is shipping parts, it is a question anyone with a yen to experiment can try out. > >model number, or some identification, so people can know what they're >measuring and label them correctly. And make life easy :> It would violate some sort of Marketing Policy, no doubt :> > >The corresponding MIPS sequence is: > 1) R2010, with R2000 (R2xxxAs are R3xxxs in R2xxx packages) (1987, 88) > 2) R3010 (shrunken R2010) with R3000 (which was changed some) (88, 89) Your naming convention is better than ours. > >4.5 "TILTING TOWARDS SPARC, UNLESS MIPS SMARTER THAN EVERYBODY" : UNPROVEN >Now, I finally get to the comment that set all of this off: ``So the FPU Then why didn't you just comment on this ? > 1) There is, as yet, little DELIVERABLE evidence for A, > with the exception that SPARCland is ahead of MIPSland in GaAs > supercomputers. The ECL verdict isn't in yet; so the rest of > this discussion covers CMOS, only. One can call BIT and order a chip. That means (to me) that one side is ahead. Perhaps not by much. But anyone can order. Did recasting an argument in symbolic logic form make clearer ? >Now, perhaps khb did not observe a difference in style or strategy >amongst the {SPARC FPUs} vs {MIPS FPU} talks. I did observe some, singular >a) Good simulation/analysis methodology for looking at design alternatives. Does anyone NOT use simulation ? Just because you are willing to publish many of your working notes doesn't mean that everyone doesn't use the tools! >b) Close coupling of chip designers with systems designers, and smart sw folks: Intel and Moto seem to disagree. But sun clearly agrees with you. :> >d) People who know CMOS technology, yield, reliability, testability, etc. all chip houses are more or less expert in these areas >e) CAD tools; diagnostics; design verification suites, etc, etc. ditto. >f) A whole lot of computing power to support all of this. of course. we all know verilog's appeite for cycles >g) Good chip technology and production. as def Stating the obvious eh ? > >Now, only a few of these are "smart people"..... which is what makes >the original khb thesis silly. To do well, you need to combine at least >most of the above (not necessarily, or even usually, in one company, >but at least in a team). Far from clear. d,e,f,g are all somewhat decoupled from a,b. Did Moto or Intel build the best systems ? Systems, ISA, and compilers need to be close (so I say, and it appears you agree). d,e,f,g can be dealt with as vendors. >2) There are plenty of reasons why competitive balance swings >back and forth, and only some are smartness. true. I think you are taking the point all out of proportion. >4) It would be nice to get some clear DATA posted about the forthcoming >SPARC FPUs. Chat with the chip folks. My lips are sealed. Keith H. Bierman |*My thoughts are my own. Only my work belongs to Sun* It's Not My Fault | Marketing Technical Specialist ! kbierman@sun.com I Voted for Bill & | Languages and Performance Tools. Opus (* strange as it may seem, I do more engineering now *)