News Focus
News Focus
icon url

Heidegger

10/14/02 5:47 PM

#1668 RE: Heidegger #1667

The dangers of a monoculture in design and manufacturing.


To expand on my last post:

"Fourth, this really illustrates a deeper issue which needs a lot more discussion: the "all the eggs in one basket" with IA-64 when in fact designs and processing _can_ be decoupled.
(To give a hint of where I'm going with this, look at H-P's claims that they could not afford to continue to develop advanced processors based on PA-RISC by themselves, that wafer fabs such as Intel was building have just gotten too expensive. So now we have essentially all computer vendors, except Sun and IBM, awaiting a good performance version of the Itanium. While I am hopeful that Madison, Deefield, Chivano, etc. will give the performance needed, it's painfully clear that the consolidation of manufacturing and design gives _less_ opportunity for evolutionary exploration and learning. Instead of several competing families of architectures, using the best processsing money can buy (at IBM, UMC, TSMC, even Intel), we have a gigantic chip using EPIC architecture...which may turn out to be an expensive detour.)
"

Here's an analogy which may make the point clearer. Imagine a world where an application producer or OS producer decided it could could do a more "integrated" job of optimizing the app or OS if it also built the computer. (This is what Apple chose to do, by the way.)

Sometimes this works, sometimes this backfires.

What worked in the Wintel world was a separation into roughly three equal components: Intel/AMD/etc. for the processor, box makers for the box itself, and Microsoft and other key developers for the OS and apps.

Now imagine that a wafer fabrication plant is essentially a certain kind of computer: input instructions of the proper format and the output is a chip with certain performance and cost characteristics.

By analogy with what Apple has done, Intel and H-P/Compaq can be seen to have made this decision: "The cost of designing an architecture and fabricating it is so high that we think only a combined operation can do it."

Intel designs the code and builds the computer (the wafer fab) to run it on.

Which is often fine, allows close integration, allows more aggressive designs, etc. (Just as Microsoft used its OS expertise to bypass conventional graphics interfaces and write directly to the screen.)

When it becomes "not fine" is when either half--design or computer--falters.

Now I have seen no convincing argument a complex design (a program, a chip design) must be tightly-coupled to a computer (a computer, a wafer fabrication process and plant) that the same physical company must do both. This is like saying a program maker must also design the computer it runs on, to ensure tight coupling.

The link between design and manufacturing is captured by design rules.

(By the way, I am not in any way, shape, or form arguing for legal action, antitrust action, etc. I'm just noting a consequence of accepting the argument that today's designs are so complicated they "must" be done by the same company actually doing the manufacturing.)

Of course, companies usually figure they'll make more money if they bring things in-house, so chip foundries start designing, and chip designers covet having their own fabs.

In the past, there were several major microprocessor design effors, and several major production companies. Mostly the designs matched up with the production. Sometimes foundries were used (Sun is the leading example).

The IA-64 is an Apple-like (Mac) and Microsoft-like (Windows, .NET) move toward "putting all the eggs in one basket."

And we'll know in 2015 which retrospectively-promising approaches to architecture and design were missed out on because of the Intel's new slogan: "Let us be your one-stop design and manufacturing center."

While I am not suggesting Intel should become a foundry, I am worried about this trend.

(And I should mention the obvious parallels with monocultures: increased susceptability to disease. In this case, a problem if either part of the package falters.)

--Tim May