Itanium Rising
Nobody may know more about Itanium than Mike Fister, and he's talking
By Justin Kestelyn
As the first member of intel's IA-64 family, slated for general availability in Q4 2000, Itanium is an important vehicle for Intel's data center aspirations. Whether you want to call it a "RISC killer" or dead on arrival, you have to accept that it may strongly influence business processes. Just as Microsoft OLAP Services delivered data analytics to an entirely new audience, Itanium's price-performance ratio may put the computing power e-business and business intelligence requires into the hands of the have-nots for the first time.
Michael Fister leads the organization that develops, markets, and supports Intel's "building blocks" for enterprise computing, including IA-32 and IA-64 processors, chipsets, and platforms for workstations and servers. By virtue of his position, he is intimately familiar with the design and marketing of Intel's Pentium, Pentium Pro, Pentium Xeon, and now Itanium, processors. We recently spoke with him about issues near and dear to the hearts of IT executives.
IE: IA-64 represents a strategic leap not only for Intel, but also for the business and IT executives who will be evaluating it as a deployment platform for their business-critical applications. What do they need to know about Itanium in order to properly plan a migration strategy?
Fister: First of all, they should know which new applications will best exploit its architectural benefits. There's a common, desktop-oriented misconception out there that a new, faster processor will always completely replace the previous one. In reality, the people who buy big computers are more interested in the range of new computational engines enabled by a 64-bit platform, as opposed to replacing everything they have.
Itanium has features that customers can exploit instantaneously for applications involving big databases, such as data warehousing, decision support, and Web-enabled ERP. For example, it offers a big, flat addressing space that you can use to run databases in memory or to access large, single images of databases, as opposed to splitting them across some architectural boundary, whether it be a logical cluster in a NUMA [nonuniform memory addressing] sense or a physical cluster. That's how big computers such as symmetric 64-way boxes or mainframes operate. So if you want to bring Itanium into the back end of your Web transaction system or into your glass house, that's a good way to start.
Itanium's mathematical capability -- a single processor can deliver 6.4 gigaflops at peak performance -- is another interesting feature. Historically, the performance of Intel's offerings has been underwhelming compared to RISC-based alternatives. The connotation has been that Intel architecture isn't a good choice for workstation applications, but actually, some server apps exploit floating-point capability as well. For example, data mining or analysis systems do a lot of double-precision, floating-point calculations to crunch massive amounts of information.
Itanium is also going to offer the kind of Unix support that you don't have in the 32-bit architecture today. The 32-bit Pentium 6 [P6] generation was very much a Windows NT platform; although it supported SCO Unix and 32-bit Solaris, it never achieved the commercial uptake to penetrate huge, back-end configurations. With IA-64, we've got support from IBM [AIX 5L, formerly Project Monterey], HP [HP-UX], Linux, and Novell. So Itanium will probably support the OS that is important to you in terms of migrating legacy configurations to take advantage of IA-64's price-performance ratio, which is positive news.
IE: There are already several 64-bit platforms out there, such as Compaq's Alpha and IBM's Power and RS64 III. What makes IA-64 different?
Fister: Today's 64-bit RISC architectures are extensions of 15- or 20-year old technology. A lot of changes have occurred over that time: Memory bottlenecks are increasing and object-oriented code is more popular, just to name a few. Unlike RISC, IA-64 is designed from the ground up to be an enterprise-class architecture. Although IA-64 is similar to RISC in some respects it's competitive on the floating point and has similar addressing limits -- it also contains advanced features to overcome memory latency and code bottlenecks.
Like those other platforms, IA-64 has features embedded into it to help you build really big computers, such as the built-in management features that are so important for administering servers and large configurations, but it also contains further advancements in error recovery for high availability. Those features are embedded across the platform as well as the microprocessor architecture.
However, the most important difference is the evolution path to price-performance we've already demonstrated with IA-32. Absolute performance won't be an issue at the outset; instead, when looking at targeted applications such as decision support or data mining, people will be amazed by how the price and performance points can help them ride the "proliferation curve" as time goes along.
IE: Doesn't your strategy to target Itanium for specific kinds of new applications suggest that large-scale migration of legacy business-critical apps is unlikely?
Fister: It's a fair question. The trite answer would be "of course not," but I wouldn't tell you that. We'd be naïve to think that the legacy transition will be over quickly. Mainframes have been with us for 25 years, and they're not going anywhere. People want to tightly control migrations from those platforms because they have millions of dollars and the critical elements of their business riding on them.
It's more realistic to expect people to make changes as they do new things. E-business is exciting because people can launch into all kinds of new business models and applications. As they do so, it's a natural opportunity for them to think, "Hey, I want to move from the very expensive, narrow systems I was working with to those that are more mainstream and have more life to them."
The opportunity to move from that "legacy" to more choice in platforms, operating systems, and applications is very exciting. We're working with the software industry to not only enable new applications, but also identify the best legacy ones for migration. And as with any microarchitecture, we want to give those apps some ability to run in a native mode for maximum performance.
We don't have this inflated view that IA-64 will instantaneously replace Alpha, Power, or even IA-32. But the momentum from partners announcing new operating environments, applications, and computers is signaling the opportunity to more aggressively select best of breed in all three areas.
IE: How will Itanium's support for very large memory architectures and higher instruction parallelism influence these applications, particularly business intelligence apps?
Fister: The most important factor here is a customer's ability to attack data analysis problems on a scale that would have been difficult before. Whereas such apps previously were present only at the upper tiers of very large businesses, now they can be available more broadly to smaller companies.
Itanium's price-performance ratio will also let customers consider distributing those systems as single-image entities across their business. Most organizations don't have a true enterprise view of their business; rather, they divide it up into business-to-business, business-to-supplier, business-to-customer, and business-to-employee portions. The business ecosystem is just expanding like crazy, and it has a million different pieces. The ability to integrate those pieces through a distributed architecture -- perhaps using extensible markup language [XML] as a transition language -- is very exciting. The addressing architecture in four-processor and eight-processor IA-64 can provide more single image uniformity for that process.
IA-64 also gives second-generation dot-coms the ability to re-scale their businesses as they intersect new e-business trends or run into the problem of distributing business processes across the complexity of their growing enterprise. We work with those companies to apply various concepts of vertical and horizontal scale depending on how their needs evolve -- such as replicating the Internet front end on one- and two-way servers and making the load balancing happen by itself; building large, vertically scaled machines; or building clusters, which are kind of in-between.
IE: Jim Kahle, chief architect of IBM's Power4 processor, has said that he believes the highly interactive nature of new applications now make bandwidth within the processor more important than pure execution speed. To what extent is that observation reflected in IA-64?
Fister: I agree with Jim's observation, and I believe that his idea is reflected not only in our processor technology, but in the total platform as well.
Let me draw you a picture. Megahertz is a prudent benchmark for a consumer purchasing a desktop, but that fact has driven a common misconception that megahertz is the only thing that matters. Rather, building a big computer is like building a balanced, finely tuned race car. If you put a 1,000-horsepower engine in a Yugo but you don't adjust the transmission, you'll just burn the tires off the car.
IT executives are sophisticated buyers; the design approach we take for them goes far beyond just cranking the clock as fast as it can go. Furthermore, in IA-64 or Power processors, instructions flow through the machine in a novel manner. We know that you're going to have gigabytes of memory and hundreds and hundreds of gigabytes of disk associated with your system, and that it will be attached to massive networks.
To continue with my metaphor, we have to design a "balanced race car" to contend with those factors -- for example, by including features such as cache memory, which makes main memory look much faster to the processor. We're also working closely with the other 169 companies in the InfiniBand Trade Association [a consortium working to develop a common I/O specification based on channel-based, switched fabric technology] to drive a next-generation I/O technology stack, which will be a significant component of that balanced race car we're talking about.
Furthermore, we want to give customers the means to superlatively manage that resource; to cluster nodes of processors so that they can do effective work in a highly distributed fashion. We've been able to demonstrate scalability in four-processor systems to eight-processor systems, or even for companies building 32-way or 64-way systems. With the Itanium processor, they'll even be able to build systems exploiting hundreds of processors.
IE: That's a good segue. In order to take full advantage of Itanium's instruction-level parallelism, customers must compile their software with IA-64 compatible tools that are tuned for the application at hand. What is Intel doing to ensure such tools are available?
Fister: The big servers we're discussing here do indeed have features, such as explicit parallelism, that are enhanced by compiler techniques. Consequently, software tools surrounding the processor are just as important as what goes inside the computer itself.
I should note that to achieve full performance for any architecture, optimized software tools are required. Companies that make big computers, such as IBM and HP, have been using this approach for years. Similarly, at Intel, we have a huge organization that builds tools for this purpose, that develops compilers, simulators, debuggers, and the technology around them. We're aggressive about licensing that technology to software tool vendors and developers to help them adapt and drive their code, to make the best use of their architecture. These tools help most applications vendors seamlessly port and tune their applications to IA-64 without complex manual optimization.
IE: If core e-business applications are particularly well-suited for Itanium, doesn't Sun Microsystems' lackluster support for the platform present a problem? You've said yourself that there is currently "no momentum" for Solaris development on Itanium.
Fister: Good question. Although the P6 generation did run Solaris, Sun never vigorously supported it. The fact that we were highly biased toward Windows NT and heavily dependent on SCO in the Unix arena was an impediment to getting that support.
With IA-64, we've observed the same factors at work. Furthermore, we just aren't seeing commercial enthusiasm or excitement for Solaris on Itanium, especially among the software vendor community -- the people who create new, innovative applications. We are working with Sun to get that support, but it's not a high priority. The supply sources for applications running on IBM Monterey, HP-UX, or even Linux are much more aggressive.
A credible Unix option is very interesting to customers and a crucial factor if we want IA-64 to permeate the back end. We have viable Unix support from very capable companies, so I don't think the lack of robust Solaris support is much of an issue. Rather, the issue lies more with the application developers. It's important for us to enable IA-64 operating systems to become the first "port of choice" for those developers in the future.
IE: Perhaps it will be Linux? How important is Linux support for Itanium?
Fister: Very important. Linux is already broadly deployed in the front-end Web servers that touch the Internet. The developer community is very excited about it, and so are customers. Even in targeted vertical niches such as technical and scientific computing, people are going to use Linux to build some amazingly large systems.
IE: Some analysts believe -- and I believe you've said this yourself -- that a volume market for high-end, IA-64 compatible software won't exist for at least a year. Thus, what do you say to customers who may suspect that Itanium is just a "development environment" for the IA-64 platform? Why shouldn't they wait for a future IA-64 processor, such as McKinley (due in 2001) or Deerfield (due in 2002)?
Fister: The first member of the family is always something that you can question that way, because you don't know what the adoption momentum will be. It all depends on your perception of volume. Most people think of volume in terms of millions and millions of units, because that's what their desktop experience tells them. But that isn't the way servers work, especially big ones.
It's logical to expect application migration momentum to start small and increase over time. We think this momentum will accelerate in the first half of 2001. That doesn't mean that you aren't going to see some deployments in October; you will. And the companies involved aren't doing a science-fair project; they're doing something material with the technology.
These people also realize that "getting on the boat" early will only support their ability to exploit the second generation even faster when it arrives in a year or so. That's because many of them did the same thing with the P6 generation. First-movers can reap the benefits of the second generation faster than second-movers.
All products go through an S-curve of evolution from early deployment to broad acceptance or volume, whatever your perception of volume may be. I think that the fact Itanium started early on that curve, despite the absence of a simple launch, is appreciated by the industry.
|
