|
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).
The Alpha->Itanium architectural change can be managed in a productive way.
It will require sound decisions on the part of many people, but it is by no
means an unreasonable risk. Admittedly, it is not a switch to a processor
with a proven track record, but it is NOT an abrupt, capricious act which
ensures problems.
The above represents my personal opinion. The
www site copy will be annotated with references and constructive questions
and answers as I accumulate material.
Subsequent Presentations (added September 2006):
|
Subsequent Publications (added June 2007):
|
Subsequent Presentations (added September 2008):
|
|