Thoughts on the Alpha->Itanium Announcement

July 2001

On Monday, Compaq/Intel announced that Itanium processors would replace Alpha processors on Compaq servers beginning in 2003. This announcement has prompted much discussion in comp.os.vms/info-vax. The tone of the comments has ranged from positive to damnation.

This posting attempts to summarize my opinions and perspectives on this issue. Admittedly, I am writing this posting without what I would consider normal due diligence and backup citations in the interest of timeliness. I am sure that the community, and the various Compaq personnel who read this forum will notify me of any gross errors.

Issues surrounding the Alpha/Itanium migration can be grouped into three categories: Technical, Trust, and Business.

• Technical Issues

  There has been much discussion over the past years about porting OpenVMS to different architectures (e.g. Pentium). My understanding has been that some of these efforts have not been successful (or have been successful with unacceptably limited performance). There have been several issues:

  • Access modes/Memory Management

    One particular issue has been the VAX/Alpha protection model, which uses four access modes: Kernel, Executive, Supervisor, and User. Most non-DEC/Compaq CPUs provided fewer modes, or substantially different memory management models. While a significant difference, memory management is not the totality of processor design. Memory management and access mode differences can be surmounted with modest effort.

    It is interesting to note that the announcement specifically mentioned the lock step modifications required for the NSK (Tandem) platform. My understanding of CPU implementation is that lockstep is a far more intrusive/extensive change than adjustments to access modes and memory management.

  • Conversion of Applications With functioning compilers, it is likely that the 64-bit port of applications software will be significantly easier than the prior port from VAX (32 bit) to Alpha (64 bit). For many codes, the VAX->Alpha port was not cataclysmic. Most of the problems encountered had to do with atomicity, precision, address size, granularity, and data alignment issues. These issues are likely to be non-issues in a 64-64 bit port.

    Presentations by OpenVMS development during the VAX-Alpha period were uniform in that the number of actual problems encountered were minimal. What has been done once, can be done again.

  • Architectural Differences

    Admittedly, this is less well defined, since I am writing this without having completely analyzed the recently released Itanium specifications. However, explicit parallelism such as that used on the Itanium is less of a difference than one might think from the compiler-produced (and CPU protected/assisted) parallelism on Alpha. Alternatively, it can be said that Alpha uses implicit parallelism which can optionally be exploited by a compiler (with a hardware scoreboard to ensure safety), while Itanium uses explicit parallelism under the control of the compiler. Both are quite manageable regimes, particularly if one accepts that virtually all actual executable code compiler-generated.

    Simultaneous multithreading is possible on Alpha; and equally possible on Itanium. In both cases, I suspect (admittedly without detailed benchmarks) that a significant portion of "normal" programs do not effectively use the full computational power of the CPU (admittedly one of the reasons that I have not been a great believer in EPIC). Simultaneous multithreading increases utilization and is clearly feasible in both cases.

    The translations between the two architectures may be more efficient than one might otherwise think. VEST-style conversion and just-in-time translation are also quite plausible technologies.

• Trust

  The issue of trust between a vendor and the customer base is a sensitive one. I for one, am somewhat upset by the apparent about-face on the viability and longevity of Alpha; but I will be the first to admit that if the technical and business issues are addressed in a constructive fashion, the trust issue is manageable.

  A formal committment to maintain the availability of spares and Alpha CPUs for the next several years would go a long way towards dealing with this issue. Ensuring that porting/emulation/coexistence issues (Alpha on Itanium; VAX on Itanium; mixed clusters VAX/Alpha/Itanium) are addressed quickly, and in an open way will also go a long way towards rebuilding trust.

  Demonstration systems demonstrating the viability of the new platform would also be a constructive step (particularly in light of Itanium's extended gestation). Small scale (e.g. desktop) systems for proof porting and experience building, at nominal cost are also important. These small systems need not have extensive performance, they must run OpenVMS on Itanium to permit customers to gain experience and comfort with Itanium as an OpenVMS platform.

  From a different perspective, Compaq management had a Hobson's choice: customers would be upset regardless of the way that this decision was implemented. They chose to announce early, be truthful, and inform customers. Alternatively, Compaq could have chosen to delay, defer, and obfuscate -- ensuring that customers would feel even more anger later.

  Early announcement raises the hazard of decreasing sales as customers "hold" position between announcement and first ship, a well-known phenomenon. I suspect (without reference to detailed numbers) that this was quite obviously present in the period from Alpha announcment through early shipments. On the other hand, this multi-year roadmap (which many customers have virtually demanded), does give adequate notice so that customers can mesh their procurement plans with product cycles (which was the reason for getting roadmaps in the first place). For the past 20 years, purchasing CPU/memory/storage capacity on more than a 12-24 month horizon has not been economically advantageous.

  Once again, early demonstrator/development boxes -- even with some limitations will go a long way towards restoring and enhancing customer trust.

  I hope I am paraphrasing correctly, but I seem to recall a senior Compaq manager making comments to the effect that six months ago we committed to making certain updates before the next meeting [DECUS], and we are here announcing the shipment of those updates. We are also announcing what the next batch of updates will be. Roadmaps in CPU/Disk technology beyond a year or two (basically items that are already in advanced development) are subject to large inherent inaccuracies. Committments (e.g. DII COE) are a different matter.

• Business

  The business issues about this architecture change are straightforward, and can be summarized as "Investment Protection". Customers need

  • product availability; and
  • investment assurance

  Small workstations at a reasonable price should be a priority in this process. Small workstations permit customers to port applications and gain experience in the new platform, with little risk. A small, limited performance workstation, perhaps based on a standard Intel motherboard, would in many ways be a better investment than even a small-scale advertising campaign. Nothing speaks louder than results.

  Small inexpensive workstations reduce customer perceived risk, and also provide a mechanism for ISVs to experiment with porting. Admittedly it is not high margin, but it pays dividends in customer relations and product growth.

  Commitments to investment assurance, similar to what was offered during the VAX-Alpha transition (if you buy an Alpha-based system past a certain point, it will be upgradeable to Itanium at no cost) are also important. Many firms cannot synchronize their acquisition cycles with major product cycles. Eliminating financial exposure on the architecture change is of great benefit. For those customers outside of the "free replacement" band, a program of graduated discounts (e.g. straight line depreciation-style) would also reduce customer's financial uncertainty.

  As an example, transition/coexistence paths for customers with GS-series boxes are an obvious point of concern. It would be helpful to know what will be the technical path for existing/future GS-series customers. The optimum possibility is an ability to run a GS-series box, with a mix of Itanium/Alpha processors (processors within a quad being the same type).