Itanic Readies for Final Sinking - Multiflow and HP Tech Aren't Enough

Alas, "itanic", aka "Itanium" is resurrected again, this time debuted by Intel as a "chip with two brains". But the critics aren't impressed, and to save money for senior management Itanium soirees, Intel middle managers are to be tossed into the cold big blue.

Well, this is no surprise to those chip-watchers who talked down Itanium from the beginning. While Dell and IBM have fled to calmer X86 waters with the likes of AMD, HP has been steadfast, selling 80% of the chips Intel has shipped.

Of course, many wonder why HP is such a firm holdout when everyone else is baling? To understand how we got where we are, we actually have to ask the question "Where did the Itanium come from?" If you think it all sprang fully formed from Andy Grove's head, you're quite wrong. And you'd miss the story of long-ago acquisitions, agreements, and ambitions...

A long time ago, in the go-go 1980's when Symmetric Computer Systems was building the first virtual memory single processor BSD system, there was a company called Multiflow Computers. They asked the very unmusical question "How many functional units can you keep busy doing interesting things on a die?" So they ganged together processors into very large instruction word (VLIW), wrote some patents and papers, and built a very interesting computer.

This question has been asked before, and we can read all about the 1960's era CDC 6600 and "scoreboard" - an attempt to control parallelization overlap in functional units (see John Louie Byers "Computer Systems Architecture", page 166-170). While the CDC 6600 did this with arbitrary functional units, Multiflow Computers examined how many instruction flows (instruction streams) could be kept going at any given time.

This problem arises every decade or so. Sun's recent foray into improving processor throughput is another in a series of projects to parallelize computation in a sequential world. In the 1980's, compiler design was cool, so it's not surprise that Multiflow used compiler technology as the agent for overlapping these functional units in parallel. If the result is overdone (because of dependency), the flow process is backytracked. If the result is underdone, the process is continued until completion. In other words, just branch code to "undo" or "finish doing" the missing pieces. I guess some folks liked it because Intel acquired Multiflow, and it became the basis for much of their innovation in Itanium.

Unlike Multiflow's static compiler approach, Sun is attempting to run a realtime interpreter on a prospector thread. Multiflow's 1989 patents are soon to expire, so we might see Sun try their older approach if Sun manages to last five more years.

Of course, there's more to Itanium than Multiflow. That's where HP comes into the picture. Itanium is also based on the HP PA-RISC implementation (aka the HP 9000 line), which Intel acquired along with HP's patent stucture, designed in competition with Sun and IBM's RISC machines of the time. This partnership merged the HP RISC architecture with Multiflow's smart parallelism of functional units. Intel knew we would eventually need multiple cores, and this seemed the smartest path.

The problem as processor designers see it (then and now) is how do you keep multiple cores appropriately busy? The way we humans write code is in languages that have no concept of parallelism. Our whole way of teaching programming is based on flowcharts worked sequentially. No surprise here - our mindset is sequential! Compilers are good planners of code, but in order to produce parallelized processing from sequentially designed code the compiler must be smarter than humans. And even compilers make mistakes, just like we do, so we have to build in error detection and correction which is effective and has reasonable overhead (in latency and storage).

The Multiflow approach made for a kind of "loose" parallelism because if it guessed wrong it just "backed out" of the problem. This avoided hardwiring into the code how many processors you're using and what they are used for, permitting more dynamic allocation of resource. Multiflow structured the compiler to create code combinations for a varying number of CPUs - a reasonable answer to the problem.

Alas, there is always the human factor, and ambition can serve as a vise as well as a goad. Intel always despised how they empowered their rival AMD and scores of other small vendors and resented the "second source" demands of customers of the 1980's. So this time, they decided to take the entire bet themselves. They locked up the compiler and systems technology under NDA, making it impossible for anyone to make money off of it but Intel. Thus the "itanic" disaster - Intel shouldered all of the multibillion dollar costs of this ambitious project so as to hoard all the profits that never materialized. I don't suppose that any exec at Intel who had dared to voice a concern as to the possible risk got anything more than a pink slip and a bad recommendation. Just another Governer "Evacuate? In our moment of triumph? I think you overestimate their chances" Tarkin moment.

BTW, these and other patents of this time will be expiring soon - Intergraph in particular had a number of legal spats with Intel over infringement, with Intel settling after lots of lawyer games. Intergraph was never an innovator, and these patents actually came from their Fairchild acquisition because they used the Clipper in their workstations - we played with that chip at Symmetric as well and considered it, but backed off completely once Fairchild was sold. After all, would you like to buy chips from one of your competitors?