But what's an architect to call a new, highly parallel design? "RISC" these days means 1980s stuff. "Superscalar" has similarly been beaten into the ground: It implies four or five execution units, a huge overhead in scheduling hardware and low clock frequencies. "VLIW," despite its technical accuracy for many new designs, carries a baggage of inflated claims, unprogrammability and market doom.

So it's not surprising that every new processor idea is gift-wrapped, free, in its own little vocabulary. No one wants their creative, if largely derivative, architecture to be burdened with the shortcomings of its predecessors.

This trend has obscured the close family resemblance among many processors, whether aimed at the X86, communications or signal-processing markets. They are all joined in one key idea that has been around in silicon design circles for generations.

Any computable problem can be broken down into a network of tasks connected by data flows. The topology of this network is all-important. In the ideal case, all the tasks are completely independent, and all could be executed in parallel. In the worst case, all of the tasks must be executed in sequence.

Unfortunately, except in some deeply embedded and well-characterized problems, little is known about this network. It may change from instance to instance, or from minute to minute.

But the job of the designer is to create a network of processing elements and control elements that achieves a particular cost/performance ratio, however cost and performance are measured for the application. Obviously you can get very short latency by providing one processing element for each independent task in the network. Obviously that costs a lot of silicon. Conversely, you can save a lot of silicon by designing a single, highly flexible processing element and reusing it for every task. The blizzard of "new" architectures we are seeing just expresses architects' uncertainty about the problem network, and their differing choices in cost/performance points.