From: mash@mips.com (John Mashey)
Newsgroups: comp.arch
Subject: Re: Why is MIPS in trouble? (long reply, including computer history)

In article <1992Apr30.075330.5817@m.cs.uiuc.edu> gillies@m.cs.uiuc.edu
(Don Gillies) writes:

>Can someone explain what exactly went wrong at MIPS?  I haven't been
>following the industry news closely enough to figure this out.
>
>For a long time MIPS was building processor chips that were two to
>five times faster than anything else in the industry.  Aside from the
>HP snake series (and possibly, IBM 6000 series), there is still not a
>line of machines with the same performance as those built from the
>R3000 and now R4000 series of chips.  What caused MIPS to lose their
>lead, and moreover, what caused them to fall into financial peril?

You may have heard the Mark Twain quote "The rumors of my demise
are greatly exaggerated" or words to that effect.
With regard to lead, no one in computing history has ever been able to
stay ahead forever...

Be warned: the following is long, with a lot of excursions into
computing history.  I've kept it as noncommercial as possible, but it
gets commercial on occasion. 

1) MIPS has something like $50M in the bank and no debt to speak of...
(This fact is often ignored).  That is *not* Chapter 11 stuff...

2) Because of the proposed merger proceedings, it is *illegal* for
MIPS & SGI people to talk publicly very much about what the combined
company would look like.  It is *possible* that the officers of these
companies, who happen to know about details of finances, deals in
progress (that can't be announced), systems synergies from hooking the
companies together and combining efforts, etc, *might* know more than
what is written in a trade rag...
As a result, people may hammer us in the stock
market, but at least part of that is because we cannot yet legally
talk publicly in detail about certain things, hence people expect the worst.
(This is not a solicitation to buy, etc, etc...)

I've said numerous times how you must treat press reports with care.
2a) Some journalists are objective and careful.  I like the ones who ask
tough questions, because I know they'll ask others tough questions.
If they've heard me out, and they still come to negative or mixed
opinions, I don't mind too much, even if the article says "They say X, Y,
and Z, but I have doubt because..."  That's OK.
2b) Some don't bother to check facts, but slam you anyway.
I'd swear some journalists must *never* talk to anyone who actually knows
anything, and sometimes they get facts wrong that could be checked in 5
minutes.
2c) Some come and talk to you for an hour, and then write a highly
skewed article.  By this, I don't mean just negative, but that they clearly
didn't care what you said, as long as they could extract *something*
damaging, and print only that, regardless of what else was said.
(I.e., this is where you said A, B, ... Z, and they pick out Q).
(I hope people understand, that if you give somebody a candid interview,
they can *always* make you look bad if they want to... which is why you
don't really see candid interviews very often. :-)
I know of one
particular case where we called somebody on this .. and the answer was
that they weren't interested in *objective* reporting, but having
a good story...  Well, at least that's honest, I guess :-)
Well, "high-flier crashes to the ground" is always a *wonderful* story,
regardless of whether or not, or how much, it is true, or regardless of
the industry & economic context.
BTW: this is not an attack on journalists in general; I sympathize with
them, as continual deadlines are nasty, they get manipulated by vendors
all of the time, and it is difficult to keep up with the increasing
level of esoterica.  However, some people try hard; others either take
cheap shots .. or just pass along marketese as Revealed Truth.

Anyway, don't believe everything you read.

3) The computer industry is into consolidation [it's that time];
the ante gets higher every round, and playing in some kinds of markets
requires a larger level of critical mass ... than when you could become
a computer systems company by porting UNIX off the tape and being a company...

One can argue that the MIPS systems business, by itself, didn't grow
quite fast enough, for whatever reasons. [Sometimes our screwups, sometimes
others', sometimes competition, sometimes the economy.  At least partly,
we devoted a whole lot of energy and $$ to creating certain
distribution channels, only to have the bottom drop out of those
channels' businesses all together... Well, that's life, but at least
one or two of these happened in a fairly mind-boggling fashion.]

Among other things, you may have noticed that the world has been in a bit
of a downturn, lately, and you want to be bigger in a downturn, not
smaller.  It would have been nice if we'd started a couple years early
and had the early 80s to grow in, when it was a little easier.
It would have been nice if there hadn't been the supply gyrations with
R6000s, and if R4000s had gotten out earlier, or if there hadn't been
a tougher-than-usual product transistion coupled with a few other
events outside our control.

4) MIPS has had, for a long time, a priority of making the architecture
widely used around the industry.  This is a long-term process, and sometimes
takes a while to pay off.  The American stock market, especially could care
less about long-term payoffs...  (long-term = next week).

MIPS has, on many occasions, shared early chips with other systems vendors,
even when it would have been nice to hoard every one for ourselves.
Since we've seldom been the largest consumer, the chip vendors have had
reason to supply other people well.
[As a potential thought question to illustrate this
(obviously, *I* don't know the answer): it will be interesting to see
*when* Solbourne gets plenty of SuperSPARCs....]

We've done things like listen to inputs from customers and make sure the
chips are useful in designs outside of the exact few configurations
we build for ourselves.  Sometimes this means it takes a little longer.

5) I don't like to do commercials, but I guess I have to, because the
"End of MIPS" tone of all this doesn't recognize a lot of things
that aren't so obvious:

5a) MIPS-based systems, as measured by end-user value, account for
about $10B installed base through YE91, according to InfoCorp.
I'd guess that the quarterly run rate in systems (can't tell about
embedded, too hard) is something like $1B-$2B (going from industry
analyses).  I have no idea how to add up service and software
components of these things.  This is not *huge*, but it's not bad.
IT ALSO MEANS THAT THERE IS A PRETTY WIDESPREAD MARKET OUT THERE.

5b) When you read the typical pie charts, you can get at least slightly misled
about what's going on, and for several reasons, the normal displays
happen to hide a lot of MIPS' usage out there, much more so than anybody else.
Let's try typical examples:
	a) Workstation pie chart - by unit volume - US vendors.
	Well, Sun likes, these, and should!
	These usually look like: Sun, HP, IBM, DEC, other.
	Sometimes SGI & Intergraph & maybe NeXT get in there.
	Unit volumes are very important ... however, value ($) is also
	important, and some charts show these.
	Of course, Sun = SPARC; HP = 68K + PA; DEC = VAX + MIPS;
	SGI = MIPS; MIPS = MIPS ...  that is, it is fairly easy to track down
	PA, SPARC (mostly Sun), IBM; it is harder to see the MIPS stuff.
	*IT IS ESPECIALLY HARD TO SEE THE MIPS STUFF BECAUSE IT IS THE
	*ONLY* SYSTEMS RISC THAT IS NOT CURRENTLY DOMINATED BY A SINGLE VENDOR.
	Hence, on many charts, MIPS is often an interesting piece of "other".
	(Of course, any of these pie charts beg the question of what you're
	counting when Macs & PCs aren't compared to SPARCstation ELCs;
	maybe there wil lbe a resegmentation or something, as PCs and
	workstations collide.  This is one of the reasons for wanting to
	include both units and value to understand what's happening.)

	b) Another anomaly happens, where, for example, you take US vendor
	sales (as above), *counting foreign sales of those vendors*....
	Unfortunately, they then *do not count* companies like NEC & Sony,
	who might possibly be important in Japan....
	(In general, some US press sources sometiems forget that the US
	is about 50% of the world market.)

	c) Various sources sometimes slice the market differently.
	I've seen cases where you ended up with apples-to-oranges
	comparisons (like counting all Sun systems in a pot, compared
	against HP (or MIPS) workstations & small servers, but omitting
	the bigger ones, under the justification that the bigger HPs or MIPS
	were multi-user systems and hence went on some other report,
	despite the fact that many of the bigger Suns were running the
	same DBMS-oriented apps as the HPs or MIPS!

5c) I think I can fairly claim that MIPS-architecture is used in a broader
variety of applications than any other RISC, in the following sense:
	1) It's used in systems applications.
	2) It's already used in a wide variety of embedded designs,
	despite the fact that the big ramp-up in embedded is really just
	happening (as some of the parts like the IDT305X or LSI LR33xxx
	have been designed in, and just really starting the ramp towards
	volume of the actual products.) I think I mentioned before that
	I know of just 3 wins that will likely ship together .8M-1M
	units over next 18 months or so.  (No, I cannot reveal the names,
	of course ... but these are next-generations of product families
	that have these sorts of run rates, so it's not wishful thinking...)
Most of the systems-RISCs have zero or little presence in embedded, and
vice-versa.  People are more familiar with systems, but please note that
MIPS chips are used in:
	1) Technical workstations.
	2) Technical servers, uni- and MP [contrary to what some Ross Tech
	guy was recently quoted as, MIPS chips have been used in MPs for
	years.]
	3) Commercial servers, including fault-tolerant ones, for years.
	(Recall that many of Tandem's Guardian-based systems are now based
	on MIPS chips, not just the UNIX-based Integrity S-2/S-3.)
	4) Telephone switches (Northern Telecom DMS-10 & AT&T Definity G3R PBX)
	5) Networking boards and terminal multiplexors, such as
	DigiBoard's newest, or Compatible Systems' RISC-Router.
	6) They're in X-terminals, as from NCD (NCD19r, using the LSIL LR33020
	variant that includes graphics ops with a mips-based core).
	7) They're in a *lot* of high-end laser printers / typesetters,	
	such as Adobe's Emerald board design, QMS, RasterOps, etc.
	Also, the Canon Color Laser Copier...
	[Most of these designs happened with R3000s.  I think you'll be
	seeing many more in lower cost designs as the lower-cost chips
	designed for them propagate around.]
	8) They're in disk controllers, such as Array Technology's RAID
	controllers.
	9) They're in both commercial and military avionics.
	10) They're in various VME or Futurebus+ boards.
	11) They will be in automobiles [again, can't say the names].
	12) *and a lot more, many of which are not announced, even though
	they started years ago [because that's how long it takes.]
	(Some people seem to think they'll magically wave a wand over a
	systems chip and turn it into in embedded control chip and make it
	successful.  I know something about the latter, but am hardly an
	expert.  Nevertheless, this is *hysterically* funny, because it takes a
	*huge* amount of industry infrastructure (software and hardware tools,
	support chips, appropriately-tweaked chip designs to cover the design
	space, chips at the right price and power levels, the right sorts of
	application engineers in the right places, etc, etc, etc) plus
	fairly long-lead-times for designs to materialize in some cases.
	(This is one of the reasons to have long-term industry semiconductor
	partners, as their own and derivative designs help cover this space,
	as well as providing useful differentation for them and their
	customers.  It's nice to have some of the largest semiconductor
	vendors in the world with us; it's also nice that some of our smaller
	partners continue to do really useful and innovative things with
	our technology.)

Now, helping all that to happen *cost* MIPS effort; if all you thought
was for the short-term, then it was utter stupidity.  It would have better to
concentrate on nothing but our own systems business, and especially,
have made sure we kept the good stuff for ourselves, or artificially held
things back, etc.  [This is why it is *extremely* irrititating when
people with *zero* close knowledge of the facts instantly say "Well,
MIPS merges with SGI; that's the end of open-ness." This whole thing was
honestly built on widespread access to this technology; maybe it wouldn't
have grown up this way if MIPS & SGI had been the same company years ago
(as many people have suggested on and off, given the closely-related
technology.) but it's there, and there are business practices and customers
in place, and that's not about to disappear.  [Think hard about it: if
you expect that MIPS-chips users are all about to disappear to another
of the RISCs because they worry they might compete with SGI, where do they
go that they *don't* compete with vendors who control *much* more of the
technology??  Be serious. It certainly does make sense for people
who are think SGI is their fiercest competitor to do something else;
there's not too many that don't already do something else...]

6) Now, as to why taking a long-term, "make it widespread" view might
be a good idea, as opposed to "keep it proprietary" and take the advantage,
despite the fact that the proprietary route may well be a much better
shorter term choice.

Over the last decade, and certainly going forward, you have and have had
the following choices:
	a) Keep a technology as proprietary as you can, and make lots of $$.
	[IBM AS/400]
	b) Make it "open" to some degree or other.  This can range from
	lip service, to a mixture [some open, but some playing-field
	tilt, i.e., like SPARC has generally been, whether or not it
	will be] to very open [like the MIPS world, in which there is
	*no* single systems vendor that is clearly dominant over the rest.]

I'd claim that for a *new* company, the evidence is that choice a) is no
longer much of a choice, except in a few niche markets, and even there,
unclear.  Even large companies well-known for proprietary histories
find this, these days.  It just costs too much to do everything that needs
to be done.,.. Also, *no one* (with the possible, and maybe arguable
exception of CRAY) has stayed #1 on performance at a wide range of
price points for more than a few years, i.e., there is a constant
leapfrog game; sometimes you're ahead, sometimes you're behind.
If you're new, you have to be ahead enough to get to exist.
Obviously market share helps protect you against when you're behind.
(In general, *most* customers tell us they don't make choices on who's
20% ahead at this instant, but they do want to pick architectures that
will stay in "the first flight" for a while, i.e., they don't want to
discover they're so far behind that they're out of it.)

Now, looking at computing history, people often forget that there used to
be a much larger number of architectures back when minicomputers had
come in.  Here's an interesting example, picked from Datapro70's 1987
listing of minicomputers, with following *distinct* architectures listed:
(Sometimes it's just the company name, with a proprietary CPU; sometimes
it's a more generic chip that often appears multiple times.
I apologize if some of these were not distinct architectures, but I
think most were.)  I'll explain later what the asterisks mean...

MINICOMPUTERS (i.e., 8-16 bits): (28)
Barrister Information Systems,
X86,
68K,
BTI-6000,
Digital LSI/11,
Computer Designed Systems Adviser,
Display Data Corp in*sight,
GEAC Computers Inc,
HP 1000,
HP 3000,
Honeywell DPS 6/22,
ICL System 25,
Integrated Digital Products Whetsone II,
IBM Series/1,
IBM System/36,
IBM System/38,
McDonnell Douglas Computer Systems M6400,
MDS Qantel (2901 bitslice),
Modular Computer Systems Classic,
Nixdorf 8850 (CMU/CMX),
Norsk Data ND-100 *(?)
SSCI,
TI99000,
TI990,
Unisys (Burroughs) B 90,
Unisys (Burroughs) B 1900,
Unisys (Sperry) System 80,
Wang VS5

SUPERMINIS (>=32 bits): (29 entries)
AT&T 3B5/15
AT&T 3B20
Barrister 3200
BTI-8000
Celerity Computing
CCI  Power6..
Computer Designed Systems CDS 2264
Concurrent Computer Corp 32xx
CDC 8xxA
DG Eclipse MV
DEC VAX
ELXSI
NS32xxx
Flexible Computer Flex/32 (?? I thought this was NSC32k?)
Gould Concept 32
Harris Hx00
HP PA
Honeywell DPS 6/xx (32-bits)
IBM S/360 (43xx,9370)
International Parallel Machines, INC IP-1
MAI Basic Four MPx
McDonnell Douglas Series 9200 or 18
MIPS Rxxx *
NCR 9000 ITX
Prime xx5x *
Pyramid Series 9xxx *
Ridge 32xx
Tandem  NonStop *
Wang VS6&up

Now, there's almost 60 entries there, taken directly from the book,
and I suspect there are more around that didn't get listed.
This was just their listing, which did *not* include workstations
(or Clipper would have shown up).
Also, not listed are the large number of supercomputer or especially
minisupercomputer architectures in existence or being worked on.

Without pointing fingers at anyone above, let me observe some
interesting facts:
	1) Of the 57 entries shown, I think I counted 35 that are no longer
	being built, including companies that went Chapter 11.
	I may have missed some. In any case, 60% aren't here any more.
  
	2) If I had a good list of minisuper companies, I suspect the %
	attrition would be even higher.

	3) The asterisked architectures are those where the company was
	founded and built on that architecture [i.e., as opposed to
	creating it after whatever else they did to get going, whether another
	architecture or something else] *AND IS STILL DOING IT*, i.e., actively
	engaged in building computers of that architecture.

	One might argue about Norsk (switched mostly to 88Ks, I think?),
	Prime (switching to PA), Pyramid (somewhat switched to MIPS),
	Tandem (partially switched to MIPS).
	If I had (mini)supers, certainly CRAY* and CONVEX* would be in
	there, although you might argue CONVEX (switching to PA?).

	4) In some cases, people thought the architecture was their advantage,
	and kept it proprietary.
	*New* companies that did this, especially in the 70s or 80s ...
	are almost all gone... although their systems business often
	grew very fast for a while ... and then it was all over.

	Anyway, the lesson was: get widespread ... or die (not: merge with
	a close customer and keep on going, but die off)

So, a bottom line is:
1) It looks like a merger is a good thing, because it helps to have
larger size to be able to afford to do more things in parallel,
and especially to be big enough not to have such sensitivity to
product line transitions.  I certainly don't mind merging with the
fastest growing workstation company...

2) There's still a lot of money in the bank, and there's a nice, fresh,
rapidly scaleable, product line starting to come out,
with pretty good performance from vanilla CMOS.

3) Summary
People may wish to write obituaries on all of this.  It's a bit premature.
People want to write off ACE.  ACE may end up being scaled down .. but
also better focussed, and there's still a lot of companies actually
doing real work and making progress; so we'll see... In any case:

	a) MIPS may well be the *last* new computer company created around a
	new general-purpose architecture and survive any length of time.
	(As noted in earlier postings, a few niche markets may be exceptions).

	b) MIPS appears to have been the *only* company *ever* created to
	build a microprocessor, where that microprocessor has gained
	widespread industry acceptance.  Even with all the gyrations
	of this industry, there is *still* a very large base of support
	for this thing, and it's much broader than you'd guess if all you
	do is read the trade rags...  However, there is no doubt, fighting
	architecture wars is a long, bloody fight, and getting a reasonable
	piece of the market is a victory for something that started with zero.

	c) *Numerous* microprocessors, some quite-well funded by large
	companies, have been held to a much smaller niche than expected,
	or have fallen by the wayside entirely, at least in some cases
	due to MIPS competition.

Anyway, like I said earlier: some of this demise talk is highly premature.
MIPS has managed to compete headon with much bigger companies that
are industry leaders, and actually win sometimes... and if we get bloodied
some, well, it's hardly surprising.

Cheers to all who managed to make it thru this.
-- 
-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 M/S 5-03, 950 DeGuigne, Sunnyvale, CA 94086-3650

Newsgroups: comp.arch,comp.benchmarks,comp.sys.super
From: mash@mash.engr.sgi.com (John R. Mashey)
Subject: Re: MIPS R8000 == TFP? [yes, and some SPEC #s and other benchmarks]
Date: Tue, 21 Jun 1994 22:25:46 GMT

In article <2te3ssINN314@pongo.cs.umbc.edu>, wrath@cs.umbc.edu (Vijay
Gill) writes:

|> The latest 21164 implementation of the Alpha Arch, is a two chip
|> module I believe.  And while DEC and HP have a lot more money to put
|> into their chip developement, 

It is nontrivial to get realistic numbers, but I'd suggest that there is
serious doubt regarding this assertion, or at least that the assertion is
very relevant, given how things have worked.  I.e., DEC or HP are bigger
than SGI alone, but for investment, you'd better count MIPS-camp,
PA-camp, Alpha-camp, and might want to ignore pieces of companies that
are irrelevant. [Since I don't understand what the HP-Intel deal means,
or whether it will get by the antitrust folks, I use below how things have
worked so far.]  Some facts, plus a few conjectures:

1) 1993 System revenues based on RISC: depending on whose numbers you
use, MIPS camp together accounted for $4B-$5B of systems built on MIPS.
I think HP PA was around $7B, i.e., higher.  DEC Alpha was, of course,
much lower than $4B, but this was first real year, so hard to compare.
Since, outside of DEC, it is unclear what's going on inside, it seems
odd to claim that DEC *has* "a lot more money"; the last I looked,
analysts are expecting DEC to sell off divisions to get enough money to
pay for layoffs...  As far as I can tell, about 1/3 of HP revenue is
from PA-RISC systems, and I wouldn't expect (fore example) PCs and
laser printers to pay for PA, as it stands.

2) 1993 chip volumes: MIPS was over 1M, ~8X that of HP's. AS far as I
can tell, about 80K-100K of the MIPS chips went into systems, rest into
other applications.

3) *Most* of the money in this game goes into process development and building
fabs, not into chip designs.  I suggest that the MIPS-camp chip vendors
invest a lot of money in these areas, more than DEC+Mitsubishi, or
probably more than HP+Hitachi+Oki.  new chip designs are measured in
small numbers of $10Ms, new fabs in larger numbers of $100Ms.
DEC has spent a lot of money building fabs that seem mostly used for CPUs.
HP has spent money, but I think that their fabs are amortized across more
different other CMOS chips than are DEC's. MIPS-camp chip vendors, of course,
produce large numbers of chips over which the fab costs are amortized.

4) It is a demonstrable fact that there are more different MIPS chips
designs on the market than there are for either HP PA or DEC Alpha;
again, to be fair, Alpha is fairly new.  The MIPS chips also cover a
broader range from top to bottom, since they already include:
- R2000, R3000
- numerous R3000 derivatives, including ones <$20 (IDT R3041), various
ASIC-core versions, and various combinations, as needed for different markets.
- R6000 (ECL)
- R4000, R4400, R4200, R4600 (QED's)
- R8000

Anyway, there are about 15-20 distinct variants.

[I've lost track of the number of HP PA implementations, but I think
there have been 8-10 different production ones, of which the PA7100,
7100LC, and 7150 seem currently in use inside HP, plus one each from
Hitachi and Oki for embedded use.  Correct me if I'm wrong; it is hard
to keep track of these things.]

With regard to economics of these things, I recommend the fine series
in Microprocessor Report: 5/31/93, 8/2/93, 9/13/93, 10/4/93, and 4/18/94.

|> problems.  Marketing counts for far far more sales than tech merit, as
|> I am sure we all know and SGI has it down pat.

Well, thanks, I think :-) but really, when selling to technical customers,
marketing may help, but technical merit still helps...

|>  Come to think of it, while the net has been buzzing
|> with the TFP announcement, the intro of the Convex Exemplar has passed
|> almost without a ripple and I think Mr. Mashey even commented on it in
|> this very newsgroup.

Hmmm, don't recall such comment, but maybe; I've been traveling.

-john mashey    DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP:    mash@sgi.com 
DDD:    415-390-3090	FAX: 415-967-8496
USPS:   Silicon Graphics 6L-005, 2011 N. Shoreline Blvd, Mountain View, CA 94039-7311

Re: [SGI] Help!!! Have I missed anything? (really: chips) [long]
From: mash@mash.engr.sgi.com (John R. Mashey) 
Date: Oct 03 1995
Newsgroups: misc.invest.stocks

In article <44jtml$b7c@news.nd.edu>, dkulkarn@aristotle.helios.nd.edu
(Dinesh Kulkarni) writes:

|> Thanks to John Mashey for the informative post. His posts on comp.arch
|> are always great but the above post was a pleasant surprise.  

Thanks for the kind words.

I'll take a stab ... as long as people understand I have to do some guessing,
and do not wish to misrepresent other people's products.

|> How do the four (or six?) microprocessor families compare in terms of
|> volumes:
|> 1. x86 (Intel + AMD + (HP at some point) ...)
|> 2. PowerPC (IBM + Motorola + ....)
|> 3. MIPS (SGI + NEC + ...)
|> 4. SPARC (Sun + Fujitsu + ....)
|> (5. Precision (HP + ?) and 6. Alpha (DEC + ?) - are these players as far
|> as volumes are concerned? - I don't know.)

1) X86's are a bunch more than any of the rest on the list above.

2) Gathered from various sources are *my* best understanding of the
numbers from CY1994; feel free to correct me if I'm way off; there is some
fuzziness due to different ways to measure; these assume a consistent model
of chip shipment for reasonably near-term incorporation into products,
and rounded to .1M's, and cross-correlated where possible with other
numbers.

3)  MIPS        1.7M
    PPC         1.3M (have seen conflicting numbers, might be a little higher)
    SPARC       0.6M
    HP PA       0.3M
    Alpha       0.1M

X86s (and MC68Ks) were way more, of course ... but I don't have the numbers
offhand here at home.

4) For the MIPS chips (where I'm actually fairly sure of the numbers):
1986:     a few hundred chips, I think
1987:     a few thousand "   "   "
1988:    .021M
1989:    .035M
1990:    .076M
1991:    .172M
1992:    .300M
1993:   1.0  M
1994:   1.67 M
As a wild guess, I'd expect 1995 to show up with 3M-3.5M, i.e., another
doubling.  While I'd love to have Intel's volumes ... this growth curve
is gratifying for an architecture done by a new startup with no installed base.

Of the 1994 MIPS chips, about 10% went into things you'd recognize as
computers; the other 90% went into embedded (and just starting)
consumer products.  In computers, SGI, NEC, Siemens-Nixdorf, Tandem,
Pyramid, Concurrent, DDE (Denmark), NetPower, and others use the
chips.  More of the revenue is in servers than desktops, of course.

I've lost track of many of the embedded apps, and often get surprised, but
they include things like:  airplanes, disk controllers, printers,
color laser copiers, X-terminals, network routers, telephone switches,
video games (although 1994 didn't have many of the latter), satellites,
and lots of other things.

As to what this has to do with chips in computers, the embedded/consumer
chips are derived, either directly or indirectly, from chips for computers,
i.e., an R3000 was once a $1000 chipset ... but there are now versions
under $20, and the later versions get leverage from the logic design,
software, and verification efforts of the earlier ones, and the volumes of
the latter help amortize the development cost, and help fill fabs.
This is good, since fabs cost money: next-generation fab+process development
costs ~1B, which is why we're glad to have partners in the volume chip
business who do this.  On the other hand, a current high-end RISC micro
*design* probably costs about $20M-$30M, depending on how much of it is
new, how aggressive it is, etc.  (Chip design teams cannot grow
indefinitely; trying to fit too many engineers into a small chip makes them
get in each others' way; transistor counts grow faster than design team sizes.)

I.e., the money is in the fabs, which is
why almost no one can afford to go it alone, and why there are now camps
that always include: 1) architecture 2) software 3) chip design 4)
process design 5) chip manufacturing 6) system design 7) system manufacturing
8) distribution 9) support ... with a bewildering variety of combinations,
but seldom with one company doing *everything* any more, with the closest
remaining one to complete vertical integration being Digital with Alpha.

At last count, there have been about 25-30 different flavors of MIPS chips
built since we started, and there are actually 64-bit versions starting
to show up in embedded & consumer applications (somewhat to my surprise).
(One may notice some of the other systems-RISC families beginning to have
embedded versions, i.e., PPC-variants from IBM & Motorola, Fujitsu
SPARClite, etc.  MIPS started very early in encouraging the embedded
market, and it turns out that it takes years for volume to happen; also
for embedded applications, there are different tradeoffs than
all-out big system chips.

MIPS of course does not (and never did) fab chips; MIPS went to the 
cooperative model fairly early, with long-term agreements with folks
like NEC, Toshiba, LSI Logic, IDT, NKK, Philips.  Some build the system
chips, others have licensed designs for use in creating their own chip
variants, which is especially needed for the embedded/consumer applications,
where' one needs numerous versions to cover the design space.
it is unclear what you call a video game

Note that both revenue and unit volumes count, although in different ways.

Note: other noticable/current 32-bit embedded and/or other micros
include MC68Ks (many), Intel i960s (more than MIPS, I think 4M), AMD
29Ks (about same as MIPS), ARMs, Transputers, and various chips found
in consumer devices.

As noted earlier, the 10% of the MIPS chips in systems led to about $5B of
hardware systems revenue.  I usually guess another $2B worth of "other things",
although it is extremely difficult to get a handle on this.  (One use of
MIPS chips is in electronics upgrades for F-16 figher planes ... do I
get to count $25M apiece as "installed base"? :-)  probably not...

As far as I can tell (again, feel free to correct):
1) PPCs, by volume are in a) Apple Power Macs b) IBM systems, c) Bull&others
        d) some embedded getting going.
2) SPARCs, by volume are in a) Suns b) others c) some embedded.
3) PA-RISCs are mostly in HP system, with some from Hitachi, Stratus, others.
4) Alphas, by volume, are almost entirely in Digital systems, with a few
in CRAY T3Ds, plus a few others.

So, that's a quick view of the RISC families that are visible in the
systems market.

-john mashey    DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP:    mash@sgi.com 
DDD:    415-390-3090    FAX: 415-967-8496
USPS:   Silicon Graphics 6L-005, 2011 N. Shoreline Blvd, Mountain View, CA 94039-7311

From: mash@mash.engr.sgi.com (John R. Mashey)
Newsgroups: comp.arch
Subject: Re: why is ia64 turning out so slow? (really: MIPS)
Date: 29 Jul 2000 20:12:38 GMT

This thread = kind of thing that discourages me from participating in
comp.arch any more, but one of our SEs asked me to look in, so:

How about some informed facts?

1) People comment that MIPS chips are behind in clock rate, and then ascribe
all sorts of architectural reasons to this.  This is mostly silly, as the
primary reason is some decisions (in my view, not good ones, but I was
distracted by a heart attack at the time) made by some no-longer-with-SGI
executives around 1995, which essentially starved the R10K team of resources.
In particular, they didn't staff the followon tuneup projects that engineers
begged for, in favor of staving 1 and then 2 separate high-end
projects (H1 & H2), both of which were eventually cancelled.

Anyone who has done chips before knows that at the time you release new
chip X, you ought to have had a serious team working on at least the next
tuneup, and somebody else working on the one afterwards, and that big-bang,
go-for-broke new designs are risky, and that you always want to iterate a
few times on what you have.  (HP PA has done this quite well, for example].

The bottom line was that we effectively lost 1-2 years, and anyone who
knows chip-making knows you don't fix that overnight.  The current
CEO, Bob Bishop, is 100% behind a long MIPS roadmap, and that helps.

2) The R12K was (in *my* opinion) substantially reshaped, and in support of my
opinion, I observe that besides the obvious changes, there were numerous other
small functional changes, but also, although some of the functional blocks
were identical, the R12K was mostly re-laid-out. Comparing the
chip layouts of the two, about 40% of the R12K consists of identical or
fairly similar blocks in the same place on the chip. The other 60% of the
chip was rearranged quite a bit, and of course, there was lots of new circuit
design.  Under no circumstances would anyone call this a simple shrink.
If anybody who doesn't have the chip plots in front of them wants to
believe otherwise, they can hold whatever fantasy they like...

3) MIPS R1xxx chips are targeted more at scalable multiprocessors than
anything else, and somewhat more for floating-point than integer,
and they have long been willing to give up a little uniprocessor performance
in order to get better thruput at reasonsable cost in mid-range & up machines.
One can debate whether or not this is the best strategy or not,
but there is no doubt that is what these chips are aiming for.

Likewise, different vendors make different decisions based on their
customers' workloads, and reasonable people can come up with different
answers.  For example, HP PA designers [who I respect highly], put a
1MB D-cache on-chip, and this is a plausible thing to do,
BUT  SGI would NEVER do that, if it that was the only data cache.
Why?
Because, we have a different workload, have long used designs with multi-level
caches, and have too much data from customers where use of 4MB, or even
better, 8MB caches makes a big difference in performance. [This effect
especially shows up when doing cache-blocking for certain matrix & vector
codes].

Hence, consider the current SPEC CFP2000 numbers, comparing the best
HP [N-series, 552MHz, 4 flops/clock, 2.2 GF/peak, an efficient 4P-8P-system
design; the bigger V-series are typically slower/CPU], versus
SGI 2x00 [400MHz, 2 flops/clock, .8 GF peak], a scalable ccNUMA design,
but of course, first shipped in 1996, and soon to be superceded by
SGI 3x00s, which are faster at the same clock rate for anything that gets
outside the cache.

Peaks:	CFP2K	CINT2K	CFPrate
			1P	2P	4P	8P	16P	32P	128P
HPN4000	369	379	-	7.84	14.4	23.04	N/A	N/A	N/A
SGI2x00	343	347	-	6.7	13.2	26.2	-	105.5 	406.6
Ratio	1.08	1.09	-	1.17	1.09	.88	-	-	-

HP/MIPS MHZ ratio = 1.38
HP/MIPS MFLOPS Ratio = 2.75

One might observe that the 552MHz N4000 is faster than a 400MHz O2000,
but much less so than the MHz ratios or especially, peak MFLOP ratios
would indicate.

Of course, SGI 3x00 [the first in the NUMAflex modular line], are faster
than SGI 2x00 for anything that gets outside the caches; the numbers aren't
yet official, but they are certainly enough better to exceed the N-series ...

As usual, it is difficult to do pure chip-chip comparisons, except when you
have 2 similar-type systems with close delivery dates, so that the
rest of the technology issues wash out. The systems should be similar,'
in that the best 1P performance is almost always from a small uni or dual
processor system with the leanest memory system.  So, a more direct
comparison for the O2000 would be with HP V-series, which however:
(a) Doesn't have current published numbers I could find.
(b) And, in any case, is about to be superceded by the HP "SuperDome".

An interesting comparison will be SGI 3x00 versus SuperDome.

4) A more complete table of relevant big RISC systems

This is the most coherent set of SPEC 2000 numbers I could get; there aren't
as many current numbers as one would like, and we await intro's of
new HP & Sun products to fill in the tables.
The systems are sorted roughly in order of performance, although
look at the numbers closely, and  note that some systems scale much bigger
than others.  I have in the past explained why we tend to use SPEC CFPrates
as useful indicators, among the widely-available benchmarks - they seem
to correlate better with the user workloads we actually see.

Anyway, the table concentrates on scalable systems, or closest equivalent.
As usual, there are faster 1-2P systems, but they usually don't have
rate numbers available.

CPQ GS = GS 160 or 320 = big machines, 6/731 = 731 MHz, 4MB Cache
SGI 3000 = 400MHz, 8MB Cache
IBM SP (High Node, 375MHz, 8MB Cache)

Peaks:	CFP2K	CINT2K	CFPrate
			1P	2P	4P	8P	16P	32P	128P
CPQ GS	444	397	5.2	-	-	-	73.3	147.8	-

SGI3x00 TBD (lower than previous, but higher than next)


HPN4000	369	379	-	7.84	14.4	23.04	N/A	N/A	N/A
SGI2x00	343	347	-	6.7	13.2	26.2	-	105.5	406.6
IBM SP	337	252	-	-	14.5	23.1	46	-	-

SUN  (no current & useful numbers)
Intel: no *rate* numbers available; the 1P #s for things like GHZ chips are quite good.

5) So, here's what I *think*, based on such data:

(a) As has been true for a while, Alphas remain fasest; this is not surprising:
good architecture, with a little more hindsight than the rest of us,
superb implementation by talented folks, and dedicated investment. [It is a bit
amusing that some of the great Alpha folks are now in other companies designing
MIPS ISA chips :-)]

(b) There's not a lot of distance between {HP N-series, IBM SP, and SGI 2x00}.
HP V-series are probably a little slower/CPU, but scale bigger than N-series.

(c) From past data, one would expect 400MHz Sun SPARCs, in E6500, E10000s,
to be below HP, IBM, SGI 2x00.

(d) Now, I know the numbers for SGI 3x00s, and will repost this table
when they get available, but I'd claim that the bottom-line is:

In medium+ -system designs, MIPS CPUs are quite competitive on these workloads
with HP & IBM (which has some of the best process technology in the world);
MIPS CPUs are ahead of SPARC CPUs, and the only CPUs that have a clear
per-CPU performance advantage in such designs is Alpha ...

I *think* (well, actually, I have the numbers),
a 731MHz Alpha (in GS) is maybe 10-20% faster than a
400MHz MIPS R12KS in SGI 3x00.  [I think 833MHz Alphas in ES40s are
faster, yet, but that's a different class of machine.]
If GS machines cost more than 20% more than similar SGI 3x00s, then
the latter will actually win on price/performance; of course,
such comparisons await more detailed pricing, and this is always a leapfrog
game.

We'll have to wait and see, of course, and we have to see the SuperDome and
new Sun products, but at least the CPQ GS and SGI 3x00 products appear
less than a quarter apart and at least attempting to do some of the same
things.

6) Clock rates: it is truly sad that the PC-mentality of
"ONLY clock rate matters" has infected comp.arch as much as it has.
Of course clock rate matters, and I wish our engineers hadn't lost that
year or two, but, even with that, MIPS CPUs are *still* quite competitive.

And since the development strategy, over the last few years, has turned
much more back into plausible upgrades, rather than big-bang things,
I believe this will remain true for some time.

--
-John Mashey EMAIL:  mash@sgi.com  DDD: 650-933-3090 FAX: 650-933-2663
USPS:   SGI 1600 Amphitheatre Pkwy., ms. 562, Mountain View, CA 94043-1351