Skip to main content

Redeploying Itanium Chip Designers -- Part One

The Itanium is Doomed

The Itanium is doomed; of that I have no doubt. That means that soon an entire ecosystem of architects and engineers will be looking for something to do. I suggest that we move them to a 'skunk-works' where they can recharge their batteries and reflect on lessons learned from their time working with the Itanium. [As an aside, I was informally asked if I wanted to work on the Itanium in the very early days of the project. I demurred, but mostly because it could only be as an employee and I worked for myself. But for the Grace of God ...]

Problems Itanium Had to Solve

The Itanium was intended to replace the x86 by addressing a variety of problems with the IA32 x86 architecture. It failed entirely in that mission.

In no particular order, here is an incomplete list of the x86 deficiencies as they occur to me:

It was 32 bits. Without getting into what 'bitness' might mean for a processor, it was not big enough.

Addressing more than 2^32 bytes was difficult or impossible (depending on circumstance). No 'flat address' space larger than 2^32 bytes wide could be addressed by one pointer.

It had a crufty old instruction set with a variety of 'hacks' to make it backward compatible over a number of generations spanning from the 8008 (released before the 4-bit 4004 and worked on by the same people). The nature of the instruction set made the chip awkward to program.

It did not have enough registers.

It had (at least for me) an odd addressing scheme and odd protection modes.

It was not well suited to multi-processor configurations.

It had bandwidth problems. Feeding the CPU with instructions from memory was about to become a bottleneck.

It made some compiler optimizations difficult or impossible.

It was not fast enough.

Problems Solved by the competition (x86-64)

In the years since the IA32 architecture was the last generation x86 architecture, some of the problems have been addressed in chips presenting the x86-64 architecture (such as Opterons, XEONs, etc), .

The chip is now 64 bits rather than 32 -- that is better.

It is now possible to address 'flat' address spaces much larger than 2^32 bytes.

There are more registers. That's also better.

I am not entirely sure where we stand with the addressing scheme, but for practical purposes, you can use a 64-bit flat space for most things that concern me. Messing around with segment registers is long behind me now.

With respect to the protection schemes, this is still messed up, in my opinion.

The chips are all now much better suited to multi-processor configurations. In addition, they all can support multiple cores. Both AMD and Intel will support 4 socket designs. AMD supports a 4-socket design with 12 cores per socket for a total of 48 cores. As of this writing, even a consumer grade machine can have 6 real cores or 4 that look like 8 cores with hyperthreading.

Bandwidth problems will always be with us, but the bandwidth situation has been very greatly improved through a variety of techniques.

Certainly EPIC style optimizations are still not possible. However, as in past CPU upgrades, modern x86-64 chips have a variety of built-in extended instructions that can be used to further optimize code.

Chips will never be fast enough, but the current generation is significantly faster than the chips were in 1989 when HP first contemplated building the EPIC based system that they began developing with Intel in 1994. In 1989, the problem they were solving (performance-wise) was an upper speed limit of 25MHz with a nominal limit of 1 instruction per clock cycle. Even by 1994 when they began in earnest, clock rates were hovering around 100MHz. Today, as this is being written, consumer systems can deliver performance in the 3.46GHz range across 6 cores -- effectively delivering more than 20,000MHz -- more 200 times the power of the chips the Itanium was supposed to best, (nominally) 25 times the power of the first Itanium released a decade ago. None of the top ten supercomputer sites use Itaniums. Most use Itanium's x86-64 rivals.

Business case is an EPIC Fail

In fairness to the Itanium, I think there may be lots of ways that a given off-the shelf Itanium box can best an off-the shelf x86-64 box. There *is* some merit in the EPIC notion and the chip accomplishes at least some of its goals for scaling well with certain types of workloads. However, for any workload I am likely to have, it is no contest and when making a business case for a purchase like this you are not comparing 'box to box', you are comparing 'cost per usage' to 'cost per usage'. On that basis, there is no ordinary scenario where the x86-64 does not flatten the Itanium. If you factor in the cost of re-writing your software on the Itanium before you can run it, it is hopeless. That last may seem extreme, but the Itanium has a very small ecosystem and the ecosystem has to somehow support the cost of that port.

The Good News

The Itanium, as I say, is doomed. That's the bad news. The good news is that those systems people are due to come free one way or another. That means that we have a team of experienced and battle-hardened veterans with (at least many of) the skills needed to solve the remaining problems with the x86 architecture. Just because they got it wrong with the Itanium does not mean that all of the ideas were bad or that their skills are lacking. Just because the x86-64 replacement of the x86-32 architecture does a better job of improving things than the Itanium does not mean it has actually done a good job or that no more problems remain.

In another posting, I will make some notes as to the x86 landscape as I see it and how I think it can be improved.

--- Copyright (C) Bob Trower. You may use this freely as you wish, but please attribute the work if you can ---

Comments

Popular posts from this blog

The system cannot execute the specified program

It always annoys me no end when I get messages like the following: "The system cannot execute the specified program." I got the above error from Windows XP when I tried to execute a program I use all the time. The message is hugely aggravating because it says the obvious without giving any actionable information. If you have such a problem and you are executing from a deep directory structure that may be your problem. It was in my case. Looking on the web with that phrase brought up a bunch of arcane stuff that did not apply to me. It mostly brought up long threads (as these things tend to do) which follow this pattern: 'Q' is the guy with the problem asking for help 'A' can be any number of people who jump in to 'help'. Q: I got this error "The system cannot execute the specified program." when I tried to ... [long list of things tried] A: What program were you running, what operating system, where is the program? What type of

Coming Soon: General Artificial Intelligence

The closer you get to experts who understand the nuts and bolts and history of AI, the more you find them saying that what we have is not nearly General Artificial Intelligence (GAI), and that GAI seems far away. I think we already have the roots in place with Neural Networks (NN), Deep Learning (DL), Machine Learning (ML), and primitive domain limited Artificial Intelligence (AI). Things like computer vision, voice recognition, and language translation are already in production. These are tough problems, but in some ways, machines are already better than humans are. I expect GAI to be an emergent property as systems mature, join, and augment one another. I was around during the 70s AI winter, and was involved in the 80s AI winter as one of the naysayers. I built a demonstration system with a Sperry voice recognition card in 1984. I could demonstrate it in a quiet room, but as a practical matter, it was not production ready at all. Around 1988 we built demonstration expert systems usin

Your call is important to us, but not much.

Rogers entire network is down and Rogers either does not know why or sufficiently disrespects its customers that it won't say. I was on the advisory committee for the largest private network in Canada serving 150,000 employees countrywide. I was also an active participant building out that network. I installed the first Local Area Networks there. I wrote a code generator responsible for the most critical portion of Bell's mobile network. I also wrote a portion of code for a system in the United States that detected and pinpointed line breaks in their network before they happened. For a time, I held the title 'Networking Professor' at our local College. I registered my first domain name in the 1980s. I have administered Internet network servers for decades. In one capacity or another, I have worked with most of the telecommunications providers in Canada past and present. Nearly a billion devices use a small network codec written by me decades ago.  Except that Rogers was