mash@mips.COM (John Mashey) (05/09/89)
In article <658@pitstop.West.Sun.COM> (Adrian Cockcroft) writes: >In the real world the main thing to optimise is price/performance so we >should be looking at what MIPS/MFLOPS can be achieved within a given >development timescale, development budget and unit cost. Thats fine for Yes. >embedded controllers but for Unix boxes there is also the issue of applications Yes. >software. SPARC has over 500 applications, increasing at a very high rate. >What do the other vendors claim? Sun claims that SPARC has more >applications software than all other RISC systems put together in a recent >SPARCware glossy. Counting applications is even harder than counting mips-numbers. I believe Sun has a very good 3rd-party catalog, but counting total numbers is very akin to counting average-mips numbers. I'm tracking down some current data on this and will post something next week. What I do know is that Sun is ahead in some application areas, but not others... >Given the same development resources and the same types of implementation >that might be true. Right now there are more design teams working on more >different future SPARC implementations because it is licensed to TI, Fujitsu, >Cypress/Ross Technology, LSI, Prisma, Solbourne etc. The 88K only has >Motorola and MIPS do all the chip designs themselves. I think that the >competition between SPARC vendors to have the best performance will >encourage more innovative developments. Right now Cypress has 40 MHz SPARC >available, MIPS are at 25 MHz? 88K at 20 MHz? I thought this was a dead topic, but since it has now been raised again, I'm forced to point out some FACTS (note that the above discussion is a mixture of FACT (SPARC is licensed...), OPINION ("I think"), and FACTOID ("Right now Cypress...") (well, I will offer a few OPINIONs, too :-) 1) (OPINION): N overlapping chip designs for the same architecture are not necessarily better than one really good design, for the same reason that having N software teams doing the same job may (or may NOT) be as effective as having one really-experienced team doing a project. I observe that there are relatively few world-class, leading-edge, proven, high-performance VLSI microprocessor design teams around, who can do good architecture AND implementation. Anybody who is trying to play in this game, with their own design, but without such a team is probably wasting their time. (FACT) Anyway, there are 2 opposing OPINIONS: a) (SUN OPINION) it's better to have lots of designs, and let them compete. b) (MIPS OPINION) it's better to do one design, get multiple pin-compatible sources for it, plus (maybe) variants of packaging and other attributes as needed. Right now, Adrian's OPINION is just that. I'll suggest below some data points that might help evaluate this OPINION, plus some milestones for the future. 2) Mr. Cockcroft apparently believes the Cypress numbers mean something. 33MHz parts were supposed to be sampling almost a year ago, and certainly were supposed to be in production 3Q/4Q 88. Why do I think this is meaningless? ANS: because you must build a SYSTEM out of this stuff, not just an integer unit. For a UNIX system, in particular, you must buy/build a SYSTEM that runs at the given speed, i.e.: CPU (Integer Unit = IU) MMU cache control cache FPU (and FP controller, if you need a separate one) external memory interface any other glue needed Trumpeting the speed of the IU alone is silly, if you can't get EVERYTHING to run at that speed. Some controller applications might omit the FPU, and have a simplified MMU, of course. We only have one data point: 33MHz Cypress IUs were sampled almost a year ago; nevertheless, I know of NO 33MHz Cypress-based SYSTEMS on the market, delivered in production form to end users. Given that SPARCstation/system 300s (25MHz) have 60-90-day AROs, that means that the approximate date of (25MHz) shipment is something like June/July 1989. (Note these are the small 300s; the big ones are 120-150 days ARO, I think). I'll be glad to hear if anybody is shipping 33MHz Cypress-based systems to update this. Note: Sun: 1) is a fine systems organization, experienced in turning out designs that push technology, and doing it fairly quickly 2) participated heavily in the design/implementation of this chip, so nothing about it should surprise them. There was STILL a year elapsed time between IU samples and shipped product, even by a quick, knowledgable organization. I suspect this means that it will take most others a while longer to get there. I often use a car analogy, with the CPU as engine. It doesn't do you any good to have a high-RPM engine if you can't build the rest of the car to match. FACT: R3000s first sampled about a year ago; at least 2 companies (MIPS & SGI) have shipped 25MHz systems, as early as 4Q88. I suspect you may see a few others soon, in the 20-25MHz range. 3) [FACT] To get back to observable reality, let's look at dates, clock rates, and relative performance of chips in SYSTEMS, using dates of production shipment (not beta, or selected ISVs, but when you as a random customer, get one after you call up and order it.) This reduces the difficulty of comparing things that are shipping with those that are "announced", but you can't get. (Note that in these days of big performance jumps each year, something that is spectacular at one point is ho-hum if delivered 6-12 months later. (EEK! life is harder than it used to be!) Unless you're right in the middle of things, it's hard to tell what's real, and what's just "announced".) To keep this simple, assume that Dhry-mips are Dhrystone mips, and VAX-mips are VAX-relative mips the way MIPS measure them. In both cases, for simplicity here, these are just single-program integer performance ratios, ignoring both floating-point and multi-tasking ones. People can argue with me on the integer VAX-mips assignments (*), but I claim that the numbers in the MIPS Performance Brief show rough parity amongst the systems that I gave similar numbers to, at least on integer performance. (this is not necessarily the case on floating point or multi-user performance, although the later SPARCs have improved at least some on the former. I have no data on the new ones for the latter. All I've got on the newest SPARCs are Dhrystone (1.1, no gimmicks), and DP/SP FORTRAN LINPACK. Still, one can gain some data from these. There's a new Performance Brief that will be out in another week or so, that has all these numbers integrated, so I won't duplicate that here.) OF COURSE, SINGLE-NUMBER MIPS-NUMBERS ARE Wrong Things, but here are the machines generally on leading-edge of performance curve for uniprocessor RISC chips, ignoring other machines done with lower clock rates in meantime: CMOS RISC micro uniprocessors: Sorted by date, with MIPS using numerics and SPARC using alphas: Code Clock Dhry VAX date machine MHZ mips mips 1 12.5 11 8 2Q87 MIPS M/800, R2000+128K cache 2 15 13 10 4Q87 MIPS M/1000, R2000+128K cache A 16.7 11 8* 4Q87 Sun-4/200, Fujitsu+128K cache 3 16.7 16 12 2Q88 MIPS M/120-5, R2000+128K cache 4 25 24 20 4Q88 MIPS M/2000, R3000+128K cache B 25 16 12* 2Q89 SPARCsystem 300s, Cypress+128K cache C 33 20 16*? 4Q89? SunRay, Cypress+?? Now, let's graph this, with uniprocessor performance as shown in earliest production ships of the faster machines: VAX- ---- 1987 ----| ----- 1988 ---| ---- 1989 ----| mips 1Q 2Q 3Q 4Q 1Q 2Q 3Q 4Q 1Q 2Q 3Q 4Q 20 4 18 16 C? 14 12 3 B 10 2 8 1 A 6 4 2 ------------------------------------------------------- Now, one can argue about jiggles of a few months, or a vax-mips, but some useful conclusions so far: a) The A-B-C curve didn't double performance every year. Assuming the SunRay gets out 4Q, it will be two years. b) It is hard to find any evidence in this chart that the 3 different implementations (A, B, C) are providing FASTER systems EARLIER than the 2 related implementations (1-2-3, 4). It is impossible to predict the future, however. c) (OPINION): I don't think the CPU-kit costs for the SPARC implementations cost less than the MIPS ones. This can be seen, for example, in LSI Logic selling (last fall) both SPARC & MIPS CPUs for $10/mips (using the vendor's ratings of mips). R3010 FPUs usually cost 1.5X-2X the corresponding CPU. 12.5MHz R3000s have recently been quoted at $60 in quantity. If you compare against the new Sun products, the MIPS ones always save on the MMU, and cache control, and sometimes save on an FPC (except versus SPARCstation1, which uses the Weitek single-chip solution; the 300's use an FPC+TI8847.) They probably use a few more chips for write-buffers. Anyway, I suspect the cost of the complete kit is usually lower for MIPS, based on counts of the big and/or fast parts in such designs. Both SPARC and MIPS need the same speed vanilla SRAMs at the same clock rate, I think, Given that C (SunRay) increases the clock rate of B by 1.32, unless something unusual is being done, if the performance of B and 3 are comparable, the performance of C will be around 16-real-vax-mips-on-the-MIPS-scale. (In fact, to actually achieve performance scale-up with clock rate, one MUST do something extra, as DRAM latency (in cycles) is worse; presumably, as a high-end, one would expect the SunRay to have ECC (the SPARCsystem300 seems to have parity-only, even when offered as a rack-mount server), and ECC often costs you a cycle. Hence, the SUnRay will ahe to work harder to get the clokc-rate scale-up. Possibilities include bigger caches or deeper write-buffers, for example (if it's a write-thru cache). Another way to put this: if somebody can ship a 40MHz Cypress SPARC, in a production system, this year, they'll catch up with the 25MHz 4Q88 MIPS product.... This illustrates the next rule of RISCars: there's RPM at the engine, and there's speed on the road.... FACT: here's a fairly straightforward head-to-head comparison: Both Cypress CY7C601 and MIPS R3000 are full-custom CMOS, and Cypress says that its process is the best, that "the competition is 2 to 3 generations behind". (quote from Cypress seminar book.) If this is so, the effective performance in a system STILL hasn't caught up with those chips that are in processes "2 to 3 generations behind".... (OPINION: This generation stuff is nonsense, by the way.) FACT: There's another good head-to-head coming up. As has been widely published, Sun is building an ECL system with technology from BIT (Bipolar Integrated Technologies). Although it has NOT been widely published, but has been admitted to, MIPS is also building an ECL system, also working with BIT. As it happens, these two projects actually started about the same time (late 1986), and they use exactly the same technology, so there will be a really fascinating comparison in early 1990. (BTW: related to some earlier discussions in this newsgroup on the structure of the industry, (OPINION) either or both of these VLSI ECL RISCs are going to cause serious trouble in some parts of the mini-super business, as they should have ridiculously low cost/mips for mainframe-class CPU performance, with no special programming required, and with inexpensive and plentiful low-end systems to have gathered software. (OPINION) one must also assume that DG's claim of 100-mips ECL 88K's in 1991 is sandbagging: CMOS/BiCMOS chips will be banging around near that performance level that year also, so ECL should either be earlier or faster.... >For a really nice multiprocessor implementation check out the Cypress CY7C605 >Multiprocessor Cache/MMU (CMU-MP). It is designed by the people who left >the Motorola 88K design team to set up Ross Technology. Cypress gave a series >of seminars earlier this year and there is a good description in their RISC >seminar notebook. (OPINION) The CY7C605 looks like a nice part. (FACT) Note that it is not shipping yet. Note that it seems different from the Reference MMU specified a while back, which is also different from the ones Sun uses in most SPARC-based products. (OPINION): there would be a lot more design wins for SPARC if this part and it's cousin, the CY7C604, had been designed along with the IU. Many wins have been lost over the confusion of different parts and combinations thereof. Presumably there will time for Cypress to make some money on these things before the Sun/TI BiCMOS thing obsoletes them.... Finally, since this whole topic was raised by Mr. Cockcroft, there are are a few facts that he may not have been aware of, and then I have a few questions that I just can't resist: FACT: it is well-known that Sun is working very hard with TI on the next-generation BiCMOS superscalar superchip, i.e., the moral equivalent of the Intel i860 or MIPS R(something). Presumably, Cypress will second-source this. I have no idea whether Fujitsu or LSIL get to second-source it or not; Solbourne is of course working on its own. FACT: the MIPS semiconductor partners were picked, at least partially, to both overlap some (to have true multiple sources & competition), but also to have enough different specialties that they all make money and be able to stay in this game for multiple rounds. Note that our partners don't spend a ton of money designing CPUs from scratch; they spend that money in marketing, support, support chips, or chip variations, yield improvements, etc.....i.e., things that semiconductor companies do especially well. Now, for some questions (my opinions on the answers appear later): Q1: what is the first year in which some other vendor will ship more SPARC-based UNIX systems than Sun? Q2: what is the first year in which all other UNIX vendors put together will ship more SPARC-based systems than Sun? Q3: what is the first year in which some other vendor will ship more SPARC-based systems than Sun? Q4: If you're a semiconductor vendor, and you do a SPARC design from scratch (not second source), you spend a lot of money, especially if you're serious about architecture. What happens if you aren't one of the close-coupled partners for the "next round"? Do you do one on your own to stay competitive, or do you drop out? (OPINION: looks like LSIL is the big winner in the current round, if they are indeed supplying all of the IUs for the SPARCstation1, which is of course, the high-volume product. Perhaps some of the units are from Fujitsu, which otherwise appears not to be supplying ANY of the parts on this round.... maybe next round, or maybe they've got plenty of alternate customers, as Sun-4/[12]xxx go away.) OPINIONS: A1: never. (since, after all, this means than somebody appears from nowhere and beats out Sun at building SPARC-based workstations; Solbourne is clearly the front-runner in this race so far....) A2: probably never. less clear; it certainly won't happen this year. Sun claims it will ship 30K SPARCstations in 1989, 100K+ in 1990, and 240K in 1991. Unless a few more vendors appear quickly, it is hard to believe that any bunch of them will beat this. If you are doing a SPARC workstation design, you'd better be doing something at a different design point than the SPARCstation1, because it's a nice design, and you're unlikely to beat Sun on volume (and therefore, probably on cost). A3: maybe sometime, since presumably Xerox will get them into printers or copiers. Presumably there are some more embedded applications lurking around out there, although we haven't seen them much in that domain, atlhough enough of it is indirect that we might not anyway. (Perhaps the 29K or i960 folks might care to comment; or the Sun folks to mention embedded designs that are public.) We REALLY won't know until products are actually announceed and shipped (as some of the companies listed as SPARC-committed are not as committed as all that.... so it is very hard to know what to believe of "design-win" counts.) A4: I wouldn't be surprised to see one (I don't know which) of the partners drop out by next year, at least on doing independent new designs. SUMMARY: 1) Objectively, Sun has a fine 3rd-party catalog. One does need to do more than counting total applications, and I'll see if I can dig out some relevant info in the next week or so. (that's a whole separate discussion, and this is already long enough.) 2) The OPINION that it is better to have a whole bunch of overlapping designs going on, is a OPINION. So far, I haven't seen much evidence to support that opinion. Maybe there will be in the future. We'll see how the ECL war comes out; we'll see when CMOS SPARCs catch R3000s in performance in a delivered system; we'll see when we get the comparison of the super* chips in 1990. 3) Note that this whole discussion started when somebody asked for some objective criteria for comparing RISCs....objective criteria, not marketing OPINION. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
bcase@cup.portal.com (Brian bcase Case) (05/10/89)
If John Mashey can post 300+ lines of marketing counter-measures, then I can post a few lines about my OPINIONS too. I think these discussions are very interesting, after all, I did read all of John's posting, but they are nearly completely inappropriate for comp.arch, IN MY OPINION. Even the note that precipitated John's note was dicey. I understand why John posted: there is a sensitivity to inaccurate statements, perceived or actual, that are interpreted as slurs against one's own stuff. How many times I have resisted the urge.... But, my gosh, there was so little architecture content that I was distressed. Disclaimers: I am not without sin in this area. I still like and encourage your postings, John. This group would certainly be dry without a little "feet on the ground, how to sell this stuff"-type discussion. Yes, I can simply skip any particular note or complete discussion that I don't like. Maybe I am alone in my interpretation of John's note. If so, just tell me to go away. BUT, this seems on the verge of getting out of hand. I mean, the performance brief stuff is one thing. However, when I see terms like "price-performance" etc. in a comp.arch posting I look sideways at the content. Again: I am not without sin here. Witness this note! I am saying we should all work harder to stay true to the subject.
stein@oscsuna.osc.edu (Rick 'Transputer' Stein) (05/10/89)
In article <18154@cup.portal.com> bcase@cup.portal.com (Brian bcase Case) writes: >Again: I am not without sin here. Witness this note! I am saying we >should all work harder to stay true to the subject. There's an old saying that goes like: "Strong minds discuss ideas, average minds discuss events, and weak minds discuss people." -- Richard M. Stein (aka Rick 'Transputer' Stein) Office of Research Computing @ The Ohio Supercomputer Center Ghettoblaster Vacuum Cleaner Architect Internet: stein@pixelpump.osc.edu
mpogue@dg.dg.com (Mike Pogue) (05/10/89)
John Mashey says: >(OPINION) one must also >assume that DG's claim of 100-mips ECL 88K's in 1991 is sandbagging: >CMOS/BiCMOS chips will be banging around near that performance level >that year also, so ECL should either be earlier or faster.... DG is typically VERY conservative about schedules and performance estimates.... This is in stark contrast to most of the chip vendors (Intel is a major culprit here) who announce "available now" when they mean "we have built a few and they kinda work", and "clock frequencies of N Mhz (where N is large)" when they really mean "it works at room temperature at N Mhz, if you have 5ns zero wait state RAMs". As an example: I took a look at the Intel i860 Processor Performance brief (Release 1.0), and it quotes 40Mhz CPUs (although their benchmark system is only 33Mhz), and at that frequency they quote ZERO WAIT STATE MEMORY, and BUGFREE silicon! Intel's Linpack numbers are not even on real hardware. They are simulated, using assembly coded BLAs, and they assume that all the y[i] reside in the cache. The BLAs are written unrolled (4 results per 17 clocks). And they say "The projected performance takes into account future improvements in the vectorizer, compilers, and vector libraries." In my experience: MIPS is a LOT better at providing real numbers, and Sun is better than Intel (although I understand that their claims for the Sparcstation are still more like PEAK numbers than sustained numbers. Anybody have any REAL data?). My preference is to have a third party do the numbers (no fudging allowed!). Look for an upcoming issue of MIPS magazine for a relatively unbiased set of numbers on our AViiON ($7995) workstation. Anybody know how the SPEC group is doing (John Mashey?)? Mike Pogue Data General Corp. Westboro, MA. These are my opinions, nobody elses....
rodman@mfci.UUCP (Paul Rodman) (05/11/89)
In article <18154@cup.portal.com> bcase@cup.portal.com (Brian bcase Case) writes: >brief stuff is one thing. However, when I see terms like "price-performance" >etc. in a comp.arch posting I look sideways at the content. > But remember that "factory-cost/performance" is quite to the point of comp.arch. Paul K. Rdman rodman@Multiflow.com
lamaster@ames.arc.nasa.gov (Hugh LaMaster) (05/12/89)
In article <19088@winchester.mips.COM> mash@mips.COM (John Mashey) writes: (many things: summary: a comparison of RISC systems, etc.) >OF COURSE, SINGLE-NUMBER MIPS-NUMBERS ARE Wrong Things, but here are >Sorted by date, with MIPS using numerics and SPARC using alphas: >Code Clock Dhry VAX date machine > MHZ mips mips >1 12.5 11 8 2Q87 MIPS M/800, R2000+128K cache >2 15 13 10 4Q87 MIPS M/1000, R2000+128K cache >A 16.7 11 8* 4Q87 Sun-4/200, Fujitsu+128K cache >3 16.7 16 12 2Q88 MIPS M/120-5, R2000+128K cache >4 25 24 20 4Q88 MIPS M/2000, R3000+128K cache >B 25 16 12* 2Q89 SPARCsystem 300s, Cypress+128K cache >C 33 20 16*? 4Q89? SunRay, Cypress+?? There has been enough of this kind of traffic over the last few years to probably justify a separate newsgroup for *performance* : comp.perf? It *is* interesting to *me* to hear arguments over whether Mips, SPARC, or 88000 based RISC systems provide the most CPU power for the dollar, as well as performance summaries on various benchmarks. Since these things are a little more "commercial" than many would like to see comp.arch, as well as more "personal" (facts vs. opinions, etc.), it would help keep an eye on more architectural issues if they were in a separate newsgroup. A few quick questions: The chart supplied shows R2000 based systems falling in at about MIPS = 2/3 MHz, with R3000 based systems at MIPS = 8/10 MHz. (1 data point, but you could also look at claims by other companies using the Mips CPU's...) (Agreed: Single number MIPS ratings are Wrong Things, but since we are looking at Integer Benchmarks within a particular architecture, maybe it is possible to ask a question or two...) What is the explanation for this change? Could we expect to see the next generation of SPARC systems make a similar leap forward (why or why not)? How do 88000 based systems stack up, using the same criteria? Hugh LaMaster, m/s 233-9, UUCP ames!lamaster NASA Ames Research Center ARPA lamaster@ames.arc.nasa.gov Moffett Field, CA 94035 Phone: (415)694-6117
henry@utzoo.uucp (Henry Spencer) (05/12/89)
In article <18154@cup.portal.com> bcase@cup.portal.com (Brian bcase Case) writes: >I think these discussions are very interesting, after all, I did read all >of John's posting, but they are nearly completely inappropriate for comp.arch, >... >Maybe I am alone in my interpretation of John's note. If so, just tell me >to go away. Please go away. :-) It suffices that the discussions are interesting, factual (an all too common problem area for many posters, but *not* John), and more or less relevant. Splitting hairs about whether it "really belongs" in comp.arch is silly; where else would it go? Like it or not, issues of implementation affect architectures. -- Mars in 1980s: USSR, 2 tries, | Henry Spencer at U of Toronto Zoology 2 failures; USA, 0 tries. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
mash@mips.COM (John Mashey) (05/12/89)
In article <169@dg.dg.com> uunet!dg!mpogue (Mike Pogue) writes: > MIPS is a LOT better at providing real numbers, and Sun is better than Intel >(although I understand that their claims for the Sparcstation are still more >like PEAK numbers than sustained numbers. Anybody have any REAL data?). OPINION: this is a typical difference between a systems company and a chip company; not surprising, given the differing natures of business. > My preference is to have a third party do the numbers (no fudging allowed!). >Look for an upcoming issue of MIPS magazine for a relatively unbiased set of >numbers on our AViiON ($7995) workstation. This will be good to see. The only caveat to be careful of is that nobody is better than the vendor at optimizing code for their own machine, i.e., they really know the options and how to use them. This leads to a good set of rules of thumb: The best benchmarks are run by a 3rd-party, with a vendor looking over their should saying "Use -O3!". Even with the most honest attitude in teh world, a vendor will always use the best options on their own machine, and may miss some when running the same benchmark on somebody else's. > Anybody know how the SPEC group is doing (John Mashey?)? Yep. We're closing in the the contents of the first tape, which basically represent mostly technical [CASE, system commands, ECAD, MCAD, scientific] benchmarks for the first round. We're busy trading benchmarks around and checking them out, with the following sorts of rules: 1) code has to be reasonably portable 2) code must be public-domain, or copyleft, or something whose source can be given out for benchmarking purposes. 3) The program has to have a nontrivial I-cache or D-cache use, or both. 4) The program should run, at least, about 60 seconds on an 8-VUPs machine; preferably more like 5-10 minutes [but you'd be surprised how HARD it is to get reasoanble benchmarks that do this.....] 5) The benchmarks must be real applications, or at worst large hunks of code from real applications. 6) There must be some added value in us working on this, i.e., there is little value for us to include Livermore Loops, as it already does what it does, is widely used, etc. I'll publish some more details a bit later; right now I'm in frenzy state getting the details together for a "bench-a-thon: or "SPECtacle", where we hook up a bunch of machines and do the last crunch of trying to get exactly the same sources, and well-paramaterized makefiles, and consistent documentation, for this. This will happen in June, followed by a 2-month review by all of the rest of the SPEC members, and then we'll issue the first round tape as we continue evaluating benchmarks for the next round. In second round we hope to get more systems-y and/or commercial benchmarks. [In fact, if by some miracle, somebody out there has some really good COBOL benchmarks....] That's all for now; more later. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
jkrueger@daitc.daitc.mil (Jonathan Krueger) (05/12/89)
In article <169@dg.dg.com>, mpogue@dg (Mike Pogue) writes: >My preference is to have a third party do the numbers (no fudging allowed!). My preference is for a first party: me. If you publish figures from commonly available benchmarks, I can replicate them later. And I'm more inclined to trust them in the meantime. Third party benchmarking is exactly as good as the third party. I have no better basis to evaluate their work than yours. "No fudging allowed" is a pious hope. The history of testing organizations does not support it. Does MIPS magazine get its support exclusively from its readers? For how many years? When the goal is measurement, why shouldn't the test conditions and predicted outputs be made publicly available? If a "third party" were to announce cold fusion, we'd all be forgiven for wanting to see outside replication. And although it may be hard to believe right now, computer benchmarking is actually a more sordid business than nuclear physics. Well, okay, it's close :-) >Look for an upcoming issue of MIPS magazine for a relatively unbiased set >of numbers on our AViiON ($7995) workstation. Oh, I see...the DATA is ELSEWHERE? Please, how about some real data? You find it convenient enough to post your product name and price in this forum. Why then is it too much trouble for you to provide data, for instance the specific data to back up your performance claims? -- Jon Jonathan Krueger ...uunet!daitc!jkrueger jkrueger@daitc.mil (703) 998-4600 My opinions are not necessarily those of my wallpaper.
thomson@hub.toronto.edu (Brian Thomson) (05/13/89)
In article <25294@ames.arc.nasa.gov> lamaster@ames.arc.nasa.gov (Hugh LaMaster) writes: >There has been enough of this kind of traffic over the last few years to >probably justify a separate newsgroup for *performance* : comp.perf? .... > Since these things are a little >more "commercial" than many would like to see comp.arch, as well as more >"personal" (facts vs. opinions, etc.), it would help keep an eye on more >architectural issues if they were in a separate newsgroup. > I would agree, except I think these issues are too closely related to be profitably separated in the way suggested here. Performance and cost of manufacture are two primary, mutually antagonistic, driving forces in architectural innovation today. Divorcing them from the architecture discussion would make comp.arch a wasteland of conjecture, unsupportable assertion, surmised value and supposed benefit. Hmm, maybe not such a big change after all ... -- Brian Thomson, CSRI Univ. of Toronto utcsri!uthub!thomson, thomson@hub.toronto.edu
mccalpin@loligo.cc.fsu.edu (John McCalpin) (05/13/89)
In article <18154@cup.portal.com> bcase@cup.portal.com (Brian Case) writes: >I think these discussions are very interesting, after all, I did read all >of John's posting, but they are nearly completely inappropriate for comp.arch, >IN MY OPINION. Even the note that precipitated John's note was dicey. >... >BUT, this seems on the verge of getting out of hand. I mean, the performance >brief stuff is one thing. However, when I see terms like "price-performance" >etc. in a comp.arch posting I look sideways at the content. It seems to me that in the "real" world, price is an unavoidable factor to consider along with performance. I think it is very interesting to see these unofficial representatives of the various vendors slugging it out. The only one who writes what look exactly like advertisements is Robert Cousins of Data General. The Sun and MIPS folks have been remarkably restrained, in my estimation. I don't know what fraction of the comp.arch reader base I represent, but I read this newsgroup as an interested layman and low-volume customer. I think that I learn more about the merits of the various products by a somewhat heated debate than by an entirely sanitized one. -- John D. McCalpin - Dept of Oceanography - Florida State University mccalpin@masig1.ocean.fsu.edu mccalpin@nu.cs.fsu.edu mccalpin@fsu (BITNET or MFENET) SCRI::MCCALPIN (SPAN)
khb%chiba@Sun.COM (Keith Bierman - SPD Languages Marketing -- MTS) (05/16/89)
In article <169@dg.dg.com> uunet!dg!mpogue (Mike Pogue) writes: > > MIPS is a LOT better at providing real numbers, and Sun is better than Intel >(although I understand that their claims for the Sparcstation are still more >like PEAK numbers than sustained numbers. Anybody have any REAL data?). The widely published Sun figures are derived from taking popular (but generally silly) benchmarks and computing the geometric mean vs. the mvII. I am sorry, but I must refuse to debate the merits of this approach publically. There are groups at Sun who run customer benchmarks (up to a million lines of code or so) and turn the results over to the customers. Personally I believe those results much more than I do contrived benchmarks. Of course the result is typically only something the owners of the program fully understand ... or have any right to see (it is, after all, their code .. not ours :>). Overall the SS-1 is slower than a DECstation 3100 which is slower than a SS 330. Mileage varies from code to code; and often from dataset to dataset. It should also be noted that the compilers are under constant improvement.... so the performance changes from time to time .... (this is true for all other vendors also) I hope to have a white paper of sorts in a month or so; with some case studies. > > My preference is to have a third party do the numbers (no fudging allowed!). Typically no understanding of the machine either. In former incarnations I was on the user side. It was (and still is) that most third parties don't know how to run the machine right. So as a customer I got each vendor to run my code, and explain what they did. The more complex the machine (say a vector machine, or a VLIW or hypercube) the more imperative it was (is) to get a very savvy (yet honest) benchmarker to do the actual work. On the Cydra 5, for example, knowing how to run the compiler and employ compiler directives could increase performance fourfold .... It has been my experience that _most_ vendors tell the truth in these tests; though they may shade it a bit :> >Look for an upcoming issue of MIPS magazine for a relatively unbiased set of >numbers on our AViiON ($7995) workstation. The folks at MIPS mag seem very well intentioned; and I wish them the best of luck. But the two issues I've studied do not reflect very much depth. The AIM benchmark they rely on does not, IMHO, do a very good job of characterising a system. (* it does seem kinda odd that they chose the name of the mag w/o realizing that it was in use by one of the companies they would be covering .... :> *) 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 *)
mpogue@dg.dg.com (Mike Pogue) (05/16/89)
In article <104996@sun.Eng.Sun.COM> khb@sun.UUCP (Keith Bierman - SPD Languages Marketing -- MTS) writes: >> >> My preference is to have a third party do the numbers (no fudging allowed!). > >Typically no understanding of the machine either. In former >incarnations I was on the user side. It was (and still is) that most >third parties don't know how to run the machine right. So as a >customer I got each vendor to run my code, and explain what they did. >directives could increase performance fourfold .... Yes, I agree that it is important to get somebody knowledgable to run the benchmarks. Just any third party will not do (sorry I didn't make this clearer). > >It has been my experience that _most_ vendors tell the truth in these >tests; though they may shade it a bit :> Actually, some vendors shade the data quite a bit. e.g. Intel quotes simulated, unrolled BLAS, no-wait-state memory, and bug-free chips in their i860 benchmarks. Also, Sun made quite a mistake in claiming that their new Sparcstation 1GX could create 3D polygons twice as fast as Silicon Graphics Personal Iris (Sun's new machine doesn't even handle 3D polygons). (NOTE: To be fair, Sun has claimed that their error was an honest mistake, although it seems to me to be amazingly to their benefit to make such a mistake.) And this is exactly my point. Vendors who do stuff like this cast doubt on ALL the vendor numbers, making a third party solution important (and, as you mention, the ultimate benchmark is the CUSTOMER's application). > > [They] chose the name of the mag w/o realizing that it was in use by one of >the companies they would be covering .... :> *) Actually, as I understand it, MIPS magazine had the name before MIPS (the company) was created. :) Mike Pogue Data General Co. Westboro, MA. My opinions are my own....
khb%chiba@Sun.COM (chiba) (05/17/89)
In article <173@dg.dg.com> uunet!dg!mpogue (Mike Pogue) writes: >In article <104996@sun.Eng.Sun.COM> khb@sun.UUCP (Keith Bierman - SPD Languages Marketing -- MTS) writes: >>> >>> My preference is to have a third party do the numbers (no fudging allowed!). >> >>Typically no understanding of the machine either. In former... > > Yes, I agree that it is important to get somebody knowledgable to run >the benchmarks. Just any third party will not do (sorry I didn't make this >clearer). My point is that very few third parties can do justice to a relatively new machine ... and even for an older machine it should be someone who lives and breathes performance studies .... > >> >>It has been my experience that _most_ vendors tell the truth in these >>tests; though they may shade it a bit :> > > Actually, some vendors shade the data quite a bit. e.g. Intel quotes >simulated, unrolled BLAS, no-wait-state memory, and bug-free chips in I meant this comment about honest to be restricted to customer level benchmarks... "standard benchmarks" have become a different ball game entirely. But if I had a circuit simulation (or given my background a kalman filter code) to someone (with input and sample output to verify correctness) I find that I am generally given a truthful time back. There are exceptions.... >their i860 benchmarks. Also, Sun made quite a mistake in claiming that their >new Sparcstation 1GX could create 3D polygons twice as fast as Silicon For the NPI there was a huge amount of handouts. For "internal" (oem, field force, etc) use alone there was an inch binder full ... the details of the GX board show up in multiple places... and the "SGI typo" occurs in one place... of course the press only reads the summaries and cannot be expected to notice that the document was INTERNALLY inconsistent ... >Graphics Personal Iris (Sun's new machine doesn't even handle 3D polygons). >(NOTE: To be fair, Sun has claimed that their error was an honest mistake, although >it seems to me to be amazingly to their benefit to make such a mistake.) Thanks for giving us the benefit of the doubt. > Actually, as I understand it, MIPS magazine had the name before MIPS (the >company) was created. :) Nope. MIPSco is several years old. This is the mag.'s first year of operation. I expect that MIPSco will win their case in court (unless Lemmons finally backs down). But note that I am not a lawyer, I only play one on the net :> Cheers 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 *)
les@unicads.UUCP (Les Milash) (05/17/89)
In some article someone wrote: >> Actually, as I understand it, MIPS magazine had the name before MIPS (the >>company) was created. :) i can't believe it's easier to get 2 generations of killer processors fab'd & designed into products than it is to get volume 1 number 1 of some mag off the presses. (but then again i can't believe that the american public went for bush/quayle.)
mash@mips.COM (John Mashey) (05/17/89)
In article <173@dg.dg.com> uunet!dg!mpogue (Mike Pogue) writes: >> [They] chose the name of the mag w/o realizing that it was in use by one of >>the companies they would be covering .... :> *) > > Actually, as I understand it, MIPS magazine had the name before MIPS (the >company) was created. :) No. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
jwest@pitstop.West.Sun.COM (Jeremy West) (05/18/89)
I'm sorry that it has taken so long to respond to John's mega message,
(I don't get to read news often enough) but I wanted to make a few points.
A large number of comp.arch readers are interested in embedded
realtime and a large number of SPARC designs are in this category.
For them an integer unit is all you need. I take the points about
availability of full chipsets at hign clock rates.
John's questions about clones exceeding Sun in SPARC production rates
were interesting, how long did it take for IBM to drop below 50%
of the PC market? What happened to the (uncloned) DEC Rainbow in the meantime?
(The above is not architecture but it is short - don's asbestos Y-fronts.. :-)
On architecture, my OPINION is that there are a lot of good design tems
around and that anyone who wants to build their own processor can
have a lot of implementation freedom while still being SPARC binary
compatible and getting the software base without having to
start from scratch.
On cost issues, John says:
> Both SPARC and MIPS
need the same speed vanilla SRAMs at the same clock rate, I think,
I disagree and so do Cypress (who sell SRAMs to MIPS?) MIPS need much
faster SRAMS because of their two phase memory bus at a given clock
rate. We could try to compare the 25MHz 4/330 CPU to a
MIPS based CPU board to settle this.
Adrian Cockcroft disclaimer: these are personal opinions
Sun Cambridge UK TSE
sun!sunuk!acockcroft
(Borrowing Jerry West's account at Mountain View to get at USENET)doug@ross.UUCP (doug carmean) (05/22/89)
I am going to risk the wrath of Mr. Case so that I might reply to Mr. Mashey's "marketing counter-measures" (<19088@winchester.mips.COM>) which was posted around May 9th. All of the included comments are Mr. Mashey's. In reference to the number of software applications running on SPARC: >Counting applications is even harder than counting mips-numbers. >...but counting total numbers is very akin to counting average-mips numbers. >I'm tracking down some current data on this and will post something next week Yes, counting applications is a somewhat esoteric process, usually warped to benefit the person that is doing the counting. Please remember that when someone quotes the number of applications running on MIPS processors, those applications may or may not be portable across MIPS based workstations. This is largely due to a major difference in byte sex between several major vendors. It would appear that the MIPS/DEC alliance has caused a real dilemma for companies designing MIPS based workstations. Do you try and be compatible with the closed system philosophy of DEC? Do you try and be compatible with the MIPS M/series workstations? Or, do you try and establish your own standard? In reference to the open license philosophy of SPARC: >I observe that there are relatively few world-class, leading-edge, proven, >high-performance VLSI microprocessor design teams around, who can do good >architecture AND implementation. I have to agree with this observation and point out that Sun has given several leading-edge, proven VLSI design houses a big break by giving them a good architecture to start with and improve upon. Sun's philosophy is to let these world-class companies compete with their various offerings of SPARC processors. I keep forgetting how bad competition is for the electronics industry. Without this terrible competition we would still be paying >$10,000 for personal computers. On Cypress: >33MHz parts were supposed to be sampling almost a year ago, and >certainly were supposed to be in production 3Q/4Q 88. The Cypress CY7C601 WAS sampled almost a year ago and WAS in production by Q3 of 88. Yes, the full chipset is not yet available, but Cypress does currently offer an IU, FPU and FPC. The MMU, cache control, cache-tag (CY7C604) and the cache RAMs (CY7C157) will be available VERY SHORTLY! Much to my disappointment, Sun did not announce a 33Mhz 601 based system with the 25Mhz system. I can say with certainty that other companies are not as far behind Sun as Mr. Mashey would lead you to believe. Look for SEVERAL 33Mhz 601 based system to be announced late summer/early fall. On high frequency systems: >FACT: R3000s first sampled about a year ago; at least 2 companies >(MIPS & SGI) have shipped 25MHz systems, as early as 4Q88. It would be interesting to compare the total number of 25Mhz R3000 systems shipped to the total number of 25Mhz SPARC based system in Q4 of 89. Would you rather be supplying parts to MIPS & SGI or just Sun? I'd take the latter. On multiprocessing (CY7C605): >(FACT) Note that it is not shipping yet. Note that it seems different >from the Reference MMU specified a while back, which is also different >from the ones Sun uses in most SPARC-based products. Mr. Mashey should get a new copy of the reference MMU spec from Sun and compare the new spec to the 604/605 descriptions. Like many other preliminary specs., the reference MMU underwent several revisions before it finally became a full fledged spec. Both the 604 (uniprocessing) and the 605 (multiprocessing) conform fully to the SPARC reference MMU specification. The reference MMU is different than the MMU that Sun has been using in most of it's SPARC based products. I don't quite see the problem with this. A well written operating system only requires a change to a single driver to port it to a new MMU. This does not render applications unexecutable on systems with different MMUs. Mr. Mashey continues: >Presumably there will time for Cypress to make some money on these >things before the Sun/TI BiCMOS thing obsoletes them.... If Mr. Mashey knows about the Sun/TI thing, Cypress must know about the Sun/TI thing. I guarantee that Cypress/ROSS would not be putting forth the effort to design the 604 and 605 if there was not a proper time and place for them in the market place. I think that Mr. Mashey failed to realize the power of multiprocessor systems that utilize the 601 IU and the 604/605 CMU chips. Arix Corp. has announced multiprocessor systems for Q1 of 90 that are based on the 601/604 set. It is clear that all of Mr. Mashey's benchmarks and extrapolations on future performance are based on uniprocessor systems. How will the 25Mhz R3000 stack up against a 4 processor 40Mhz 601 system? Mr. Mashey pointed out that it is difficult to design systems that run at 40Mhz, and his point is well taken. Consider that the 25Mhz R3000 requires two bus transactions per clock cycle, effectively running the bus at 50Mhz. Even if MIPS could design a 40Mhz Rx000, could you design a system that allows bus operations at 80Mhz? One of the lures to the MIPS camp has been their very high performance compilers that they have touted as the best in the industry. I think that Sun's new compilers will seriously challenge the MIPS compilers as the best in the industry. We should see some hard data on this soon. Finally, Mr. Mashey brings up the question of other vendors producing more SPARC based systems than Sun. Is this important? I think the important assertion is that other vendors will be able to thrive supplying the world with SPARC based systems. Out of the companies that are currently working on Sun clones, several may emerge to dominate the low priced workstation market. If the industry can support Sun and several major clone manufacturers, it would appear that at that point SPARC had become the industry standard for workstations. -- -doug carmean ross!doug@cs.utexas.edu -ROSS Technology, 7748 Hwy 290 West Suite 400, Austin, TX 78736 -Coming soon: Low Calorie Fusion
steves@ross.UUCP (steve studulski) (05/22/89)
In article <19088@winchester.mips.COM> John Mashey writes: >1) (OPINION): N overlapping chip designs for the same architecture >are not necessarily better than one really good design, for the same reason >that having N software teams doing the same job may (or may NOT) be as >effective as having one really-experienced team doing a project. >I observe that there are relatively few world-class, leading-edge, proven, >high-performance VLSI microprocessor design teams around, who can do good >architecture AND implementation. Anybody who is trying to play in this >game, with their own design, but without such a team is probably wasting >their time. And in article <19182@winchester.mips.COM> John gives the following excuse for this article (the article he is replying to is <18154@cup.portal.com> by Brian Case): >>If John Mashey can post 300+ lines of marketing counter-measures, then I can >>post a few lines about my OPINIONS too. > >>I think these discussions are very interesting, after all, I did read all >>of John's posting, but they are nearly completely inappropriate for comp.arch, >>IN MY OPINION. Even the note that precipitated John's note was dicey. > >Well Brian is probably right on this [and I wouldn't have been as long, >except I'd just been reading a Cypress brochure that claimed SPARC >had "thousands of times more lines of code than all other RISCs put >together." among other things that stirred me up.] I'm afraid I'm going to have to use the same excuse as John for writing this article. After reading the first article above, I was also stirred up. John implies that MIPS has cornered the market on "world-class, leading-edge, proven, high-performance VLSI microprocessor design teams around, who can do good architecture AND implementation." I have to take serious exception to this statement. First off, is MIPS a semiconductor company or systems company? How can MIPS possibly suggest that they are "the" major force in silicon design and implementation if they are a systems house, and NOT a semiconductor house? What sort of economic forces are going to force them to keep their processor architecture and implementation state-of-the-art without direct competition? And by competition I don't mean companies who second source your implementation, for they will not compete on architecture or implementation, they will only compete on processing technology. With SPARC, there are several (ie Texas Instruments, Fujitsu, LSI Logic, Cypress Semiconductor (aka Ross Technology)) semiconductor houses working on advancing processing technology, architecture, and implementation. All of these companies have extreme economic incentives for working diligently on advancing their products. Yet, even with all of these different implementations of the SPARC architecture, you can take any binary database and binary code and execute it on any system and it will produce the same results. This can NOT be said of systems which use the MIPS processor. Because of the byte-sex difference between MIPSco systems and DEC systems, it is NOT possible to take the same binary database and code and get the same results on both systems even though they both use the same MIPS processor! As far as personnel goes, how can John possibly imply that MIPS has cornered the market on experienced and proven microprocessor design teams. At Ross, we have no lack of experience in semiconductor architecture or design. All of our personnel are members of the elite club you described (ie world-class, leading-edge, ...). Ross Technology founders include the program manager/chief architect and the circuit design manager of Motorola's 88000 RISC processor. Our design team has personnel with the following credentials: - Designers of the only commercially available 40Mhz RISC processor (Cypress Semiconductor's CY7C601). - Designers of the 68000 processor family (including the 68030 and 68040). - Designers of the 88000 processor family (besides the founders). - Designers of the 29000 processor. - Designers of a 100Mhz, 200 Mflop VHSIC CMOS processor with over 2,000,000 transistors (sorry, not a commercial part). - Designers of the Zilog Z8 microcontroller family. Our design methodology includes state-of-the-art silicon compilation technology, and our process is state-of-the-art 0.8u CMOS. We have personnel who were offered positions with Intel's i860 group, and with the Sun/TI processor group you alluded to, but who chose Ross over these groups because of our state-of-the-art design methodologies and design expertise. (Do either of these groups or MIPS have anyone who chose them over Ross Technology? I think not.) Although I know very few members of the Sun/TI design team previously referred to, I know they have people with exceptional qualifications also, such as: - Program manager of the 80386 program. - Designers of the 80386. - Designers of the HP Precision Architecture. Unfortunately, I don't know people at LSI Logic or Fujitsu or even the vast majority at Sun working on SPARC and so can not comment on their accomplishments and qualifications, but maybe others reading this can. I apologize for taking up comp.arch space with this article, but I am a member of Ross's design team, and I take it personally when people imply that me and my company lack the expertise needed to design high-performance microprocessors. I hope I have set the record straight on the quality of personnel implementing the SPARC architecture at Ross Technology and elsewhere in the industry. -steve studulski ross!steves@cs.utexas.edu -ROSS Technology, 7748 Hwy 290 West Suite 400, Austin, TX 78736 <As usual, I speak only for me, and not for my company> -- -steve studulski ross!steves@cs.utexas.edu -ROSS Technology, 7748 Hwy 290 West Suite 400, Austin, TX 78736 <As usual, I speak only for me, and not for my company>
andrew@frip.WV.TEK.COM (Andrew Klossner) (05/24/89)
doug carmean (doug@ross.UUCP) writes:
"I keep forgetting how bad competition is for the electronics
industry. Without this terrible competition we would still be
paying >$10,000 for personal computers."
I had to read this twice before I understood the real contents.
Let's please leave the sarcasm out of our postings? .. it doesn't add
anything to a technical discussion.
"The reference MMU is different from the MMU that Sun has been
using in most of its SPARC based products. I don't quite see
the problem with this. A well written operating system only
requires a change to a single driver to port it to a new MMU."
An MMU is not a "device," to be "driven" easily by a single module.
Big MMU differences cause ripples throughout the kernel, and in extreme
cases can affect user code.
-=- Andrew Klossner (uunet!tektronix!orca!frip!andrew) [UUCP]
(andrew%frip.wv.tek.com@relay.cs.net) [ARPA]nawaf@apollo.COM (Nawaf Bitar) (05/25/89)
In article <3390@orca.WV.TEK.COM> andrew@frip.WV.TEK.COM (Andrew Klossner) writes: > > "The reference MMU is different from the MMU that Sun has been > using in most of its SPARC based products. I don't quite see > the problem with this. A well written operating system only > requires a change to a single driver to port it to a new MMU." > >An MMU is not a "device," to be "driven" easily by a single module. >Big MMU differences cause ripples throughout the kernel, and in extreme >cases can affect user code. In actual fact it does not hurt to think of an MMU as a device that is being driven by a single module. The Mach operating system does precisely that, and experience has show that porting to differing MMU architectures has only required changes to the single MMU driver (pmap module). In order to accomplish this successfully the virtual memory system has to be carefully structured such that no assumptions about a specific underlying MMU architecture are made. This is certainly not the case in BSD, VMS, SunOs 3.* and, no doubt, others. -- Nawaf Bitar nawaf@apollo.com Apollo Computer, Inc. 330 Billerica Road Chelmsford, Massachusetts 01824
guy@auspex.auspex.com (Guy Harris) (05/25/89)
>An MMU is not a "device," to be "driven" easily by a single module. >Big MMU differences cause ripples throughout the kernel, and in extreme >cases can affect user code. Whilst I would not argue that support for a new MMU trivially plugs into the SunOS 4.0/S5R4 VM system, with the SunOS 4.0 VM architecture the ripples don't go as far as they do in some other systems; support for the "standard" Sun MMU, the 68030 on-chip MMU, the 80386 on-chip MMU, and now the Campus-1 err sorry SPARCStation-1 MMU (4KB pages, rather than 8KB pages, as in the standard Sun-3/Sun-4 MMU) fit in fairly cleanly. I think Mach is also supposed to be set up to cleanly support a variety of MMUs as well. I think it's been ported to machines with "conventional" N-level page table MMUs, Sun-style static-RAM MMUs, and "inverted page table" MMUs (is not the IBM RT PC's MMU of this type?). The SunOS 4.0 one hasn't been ported to the latter, yet, as far as I know; I don't know how difficult it would be. I assume one of the goals of IBM's VM modifications in recent or forthcoming AIXes is similar (since they have to support the RT PC, 80386, and 370 - and, presumably, since OSF plans to pick up the AIX kernel, right? they also will have to support the VAX and MIPS MMUs, and Apollo's MMU(s?), and HP's, and...). So, whilst I'll agree that it's not necessarily the case that "A well written operating system only requires a change to a single driver to port it to a new MMU.", a well-designed VM system can handle a fairly wide range of MMUs with pretty localized changes to VM code.
mcg@mipon2.intel.com (05/30/89)
In article <674@pitstop.West.Sun.COM> jwest@pitstop.West.Sun.COM (Jeremy West) writes: > > >A large number of comp.arch readers are interested in embedded >realtime and a large number of SPARC designs are in this category. >For them an integer unit is all you need. I take the points about >availability of full chipsets at hign clock rates. In this late response I wish to avoid the protracted debate (name-calling?) currently happening between SPARC and MIPS advocates. Let me say simply that, as a contended in the embedded processor market (with the Intel 960), I do not believe that many people are taking SPARC seriously as an embedded controller. The chips require too much board space and support logic, they require a cache (almost always out of the question for embedded designs), have unpleasant code expansion characteristics, are too expensive, and have too little development support (e.g. no In-Circuit Emulators) for most embedded applications. Having said that, the same is pretty much true for MIPS. This is not a reflection on the quality of their architectures for the workstation world. It is a statement about their (current) *implementations* in the embedded world. I suspect that Sun is beginning to attempt to position SPARC in realtime and embedded markets: a) as a fallback position in case they don't succeed as thoroughly as they hope in the workstation market; and b) because the volume of design wins and chip sales in 32-bit embedded control is (conservatively) 10x the workstation market. This is the same strategy that drove AMD to move the 29k out of workstation land, as well as Weitek and the XL8xxx, and (of late) National and the 32k series. S. McGeady Intel Corp.
tim@crackle.amd.com (Tim Olson) (05/30/89)
In article <m0fRxlf-0001fDC@mipon2.intel.com> mcg@mipon2.UUCP (Steven McGeady) writes: | I suspect that Sun is beginning to attempt to position SPARC in | realtime and embedded markets: a) as a fallback position in case they | don't succeed as thoroughly as they hope in the workstation market; and | b) because the volume of design wins and chip sales in 32-bit embedded | control is (conservatively) 10x the workstation market. | | This is the same strategy that drove AMD to move the 29k out of | workstation land, as well as Weitek and the XL8xxx, and (of late) | National and the 32k series. While this may be true for SPARC and the 32k series, the Am29000 was PDP'ed (Product Design Plan) as an embedded controller (because of the volumes) -- it certainly isn't a "fallback position". That is not to say that we wouldn't *allow* our chips to be used in workstations ;-) -- Tim Olson Advanced Micro Devices (tim@amd.com)
jwest@pitstop.West.Sun.COM (Jeremy West) (05/31/89)
In article <m0fRxlf-0001fDC@mipon2.intel.com>, mcg@mipon2.intel.com writes: > In article <674@pitstop.West.Sun.COM> jwest@pitstop.West.Sun.COM (Adrian Cockcroft) writes: > > > >A large number of comp.arch readers are interested in embedded > >realtime and a large number of SPARC designs are in this category. > >For them an integer unit is all you need. > > In this late response I wish to avoid the protracted debate (name-calling?) > currently happening between SPARC and MIPS advocates. Let me say simply > that, as a contended in the embedded processor market (with the Intel 960), > I do not believe that many people are taking SPARC seriously as an embedded > controller. The chips require too much board space and support logic, they > require a cache (almost always out of the question for embedded designs), You do not need a cache if you make your RAM out of SRAMS, you also avoid having to worry about refresh on DRAM's. Note that the 4/110 uses static column or fast page mode DRAM's without a cache also. If you want deterministic response times then caches are also a pain. Cypress publish an evaluation board circuit that uses SRAMs only. > have unpleasant code expansion characteristics, are too expensive, and have > too little development support (e.g. no In-Circuit Emulators) for most > embedded applications. There is a class of realtime applications where you need the fastest thing you can get for a reasonable price. SPARC has a place here. One of the reasons that SPARC is being used is *precisely* that it has a lot of development support in the shape of the Sun4/SPARCstation machines and the development tools that run on them. e.g. dbxtool. In-Circuit Emulators for SPARC are coming. It also has Wind River Systems real-time OS running now and VRTX being ported. > > I suspect that Sun is beginning to attempt to position SPARC in > realtime and embedded markets: a) as a fallback position in case they > don't succeed as thoroughly as they hope in the workstation market; and > b) because the volume of design wins and chip sales in 32-bit embedded > control is (conservatively) 10x the workstation market. > This is the wrong way round, Sun was surprised by the level of interest from realtime embedded systems people and has belatedly made some attempts to service an apparent demand. e.g. making SPARCsim generally available. Most of the push has come from the semiconductor vendors rather than Sun since they have most to gain from selling chips. One thing that has happened is that Sun has trained a group of pre-sales technical support engineers to be SPARC specialists, one for each sales region around the world and we (I am one) can spend some of our time helping people who want to build SPARC systems. Since the engineering people at mountainview are too busy designing to post to comp.arch I'm trying to keep the record straight myself. It is worthwile in that I can try out the things we have been told and get corrections on MIPS from John Mashey etc. BTW do people know about SPARCsim, the SPARC architectural simulator? It lets you simulate a IU/FPU/MMU/IO/Cache/Memory system and run unmodified SPARC binaries on it to see how it performs or to debug device drivers or kernels. The sun4 kernel was up and running on SPARCsim on a Sun3 before any Sun4 hardware existed. All the local SPARC specialists have a copy for demo's. I don't know of any design wins that I can name but one that I know of is doing a high speed signal processing system and has taken advantage of LSI logic's capability to use a SPARC IU as one corner of an ASIC with all the other stuff they want round the edge. The SPARC IU takes about 12000 gates out of a 50000 gate ASIC. This is a neat way to customise the interfaces to remove glue logic. > S. McGeady > Intel Corp. Adrian Cockcroft Sun Cambridge UK TSE sun!sunuk!acockcroft (Borrowing Jerry West's account at Mountain View to get at USENET)