This is the year Intel finally joins the big leagues when it comes to the server market. After gradually creeping up the Unix food chain with its Pentium and Xeon processor lines, the Santa Clara company hopes to finally stand on equal ground with the RISC (Reduced Instruction Set Computer) processors that have fueled rival processors like PA-RISC, PowerPC, and UltraSPARC. The key? Intel’s next-generation line of 64-bit microprocessors: Itanium.
The idea behind Itanium is to decouple the operating system providers from their hardware design. As microprocessor manufacturing became more complex in the early 1990s, Hewlett-Packard began to suspect that the cost of producing their own chips was exceeding the benefits of controlling their design. The company licensed some technology to Intel, and the two companies began work on what they hoped would become an industry-standard microprocessor design.
One by one, the RISC systems vendors came on board: IBM, Digital Equipment Corp (now Compaq), SGI, Fujitsu, Bull, and so on. As the Itanium PR campaign picked up steam, companies began jockeying to become the standard operating system provider for the new platform. IBM, Sequent, and SCO teamed up to create a standard Itanium Unix, code-named Monterey [IBM has since renamed the project AIX 5L -Ed.]; Sun positioned Solaris as a possible contender; HP had its own HP-UX; and, as always, Microsoft waited in the wings.
And then along came Linux.
And what of Transmeta, the high-profile microprocessor start-up that employs Linux’s creator, Linus Torvalds? Transmeta recently strengthened the AMD camp by licensing its x86-64 technology, thus paving the way for a line of low-powered, Hammer-compatible chips based on Transmeta’s Crusoe processor.
Though Transmeta is now best known as a laptop chipmaker, it has begun marketing Crusoe as a server alternative to IA-32 chips. Last spring, a number of high-profile Compaq refugees formed a company named RLX Technologies and launched the first line of server products based on Transmeta’s TM5600 chip. By 2002, RLX expects to be shipping X86-compatible systems with five watt, 800 MHz to 900 MHz processors. Transmeta’s AMD deal means that server vendors like RLX will now be able to ship 64-bit systems with more than 4 GB of memory, though Transmeta’s CTO Dave Ditzel says that day may be five to ten years down the road.
While it employs Linux’s creator and has sponsored its own Linux distribution, the free OS is not of particular strategic importance to Transmeta. “We see Linux as another one of the many operating systems that runs upon X86-compatible computers,” says Transmeta’s Ditzel. He adds, “Linus was hired because he is a very smart programmer — not to work on Linux, but to work on our code morphing software.”
Chip analyst Nathan Brookwood says that the fact that Transmeta has licensed the x86-64 instruction set could help AMD gain Microsoft’s support. “Microsoft prefers to do software that does not support a single vendor’s proprietary standard,” says Brookwood. “I think it could make a difference.”
Empire of Itanium
Linux’s association with Itanium began even before the first test chips were produced. Four years ago, Intel began to think about testing the IA-64 instruction set that would become the basis for Itanium. The engineers working on IA-64 wanted to try porting two operating system kernels to IA-64 emulators they had developed to test for bugs before actually making the chips — a process called presilicon validation. According to Intel engineer Stephan Zeisset, one of the kernels chosen was the Mach kernel, because his team had some experience working with it on an earlier project. The second was Linux. “In the case of Linux, the fact that its source was readily available made it easy to become familiar with,” says Zeisset.
Though the Itanium project had already enlisted the support of a variety of commercial OS kernel providers — Microsoft, Hewlett-Packard, and IBM to name a few — when it came time to do the very first porting work, the Intel engineers decided it was better to simply pick up the Linux source code off the Net. Besides the fact that Linux’s source code was freely available, it had the additional benefits of being cleanly written, being 64-bit compatible, and being designed from the ground up to be ported to a variety of hardware architectures.
Even as Intel’s engineers were taking advantage of Linux, their managers were beginning to sense the popularity and strategic importance of the free operating system. By 1998, Intel’s Enterprise Server Group had picked up on the fact that Linux was popular in the fast-growing ISP space, and the chipmaker began to support Linux in the ways it knew best. It made sure that Linux developers had access to the latest Intel hardware; it sponsored a project (called Trillian) to port Linux to Itanium; and it began to spend money. To help seed the pool of Itanium-ported apps, Intel set up a $250 million fund chartered with investing in companies that develop applications for Itanium. To date, this “Intel 64″ Fund has invested $100 million in over 29 companies, a fair bit of which has gone into the Linux community.
Since 1998, Intel has backed a number of Linux companies, including Turbolinux, SuSE, VA Linux, Red Hat, and even premature IPO wannabe Linux One. Intel has also paid a number of open source companies to port tools and applications to the IA-64 platform.
Another major initiative has been Intel’s investment in the $24 million Portland, OR-based Linux Development Lab. Run by Intel’s long-time Linux evangelist Tim Witham, the 11,000 square foot lab is a place where open source developers can get access to high-end systems they might otherwise be unable to test their applications on. The lab has a number of 4-, 8-, and 16-way systems that are now being used by open source developers.
Victor Krutul, Intel’s Linux Technology Manager, says that from the start, his company was very much aware of its weight in the industry and was determined to step lightly in the Linux space. “We spent a lot of time looking at how to work with the community without breaking it,” he says. “Our number one concern was that Intel could unintentionally do something to break the Linux momentum.”
Enemies at the Gates
|The only way they were going to get their 64-bit extensions implemented in a timely fashion was from a source outside of Microsoft. — Kevin Krewell, Microdesign Resources|
Microdesign Resources’ Kevin Krewell says that one company in particular lies behind Intel’s remarkable embrace of Linux: Microsoft. “It allowed them to have some leverage against Microsoft,” he says, “And anything that keeps Microsoft off-balance is a good thing for Intel.” Of course, Krewell acknowledges Microsoft is not without its own leverage. And these days, one of the ways it exerts pressure on Intel is by supporting its rival chipmaker, Advance Micro Devices (AMD). “It’s like a little sniping war. They are both trying to erode the power base of the other guy.”
For a company that has built its business cloning Intel’s IA-32 chips, their move to Itanium could have seemed like a death knell for AMD. Because Itanium’s IA-64 is a complete departure from the IA-32 line, AMD would essentially be starting from scratch if it chose to clone Itanium, and it could take years for the company to catch up with Intel.
So the AMD engineers began evaluating their options and they decided that the switch to Itanium represented an opportunity. Though Itanium processors would be able to run programs written for Intel’s 32- bit machines, they would do this in an emulation mode and would surely suffer from poor performance. People who truly wanted to take advantage of Itanium would need to run applications that had been compiled specially for it’s IA-64 architecture.
What if they had another choice, though? What if AMD offered 64-bit chips that extended IA-32? These machines could run any IA-32 application just as well or better than a Xeon system, and if people wanted to run 64-bit applications, they’d be able to do that as well. Soon AMD was working on its very own line of 64-bit chips, called the Hammer line. They would be based on AMD’s very own X86-64 architecture.
There were just a few problems. For one thing, the clone-maker didn’t have experience promoting its own chip architecture. For another, it didn’t have $250 million to spend on the AMD equivalent of an Intel 64 Fund. AMD’s solution? At first, says Microdesign Resources’ Krewell, the company avoided Linux, focusing instead on its partnership with Microsoft. “And then when they didn’t get quite the rousing support from Microsoft that they had hoped,” he says, “they started to openly embrace the Linux community.” He adds, “I think they realized that the only way they were going to get their 64-bit extensions implemented in a timely fashion was from a source outside of Microsoft.”
Ports, Love, and Linux
|We got comments on our public mailing list from people that were interested in the port, but not affiliated with AMD. — Andreas Jaeger, SuSE|
The company’s courtship of Linux developers began in August 2000, when AMD released the architectural specification to X86-64. By October, it had publicly released an X86-64 emulator and launched the X86-64.org Web site, which was to be the home base of the X86-64 porting effort within the Linux community.
Being a decided underdog to Intel has both allowed and necessitated that AMD act with an unprecedented degree of openness toward Linux developers. AMD’s extension of the IA-32 architecture is not the same kind of radical redesign that Intel engaged with Itanium. Furthermore, AMD has realized that the goodwill of Linux developers may be its best chance at popularizing its 64-bit instruction set. Whatever the reason, AMD’s approach to the Hammer represents a whole new modus operandi for the chip business, where secrecy, not openness, is the norm, and where Linux has historically been an afterthought. “Three years ago if you had asked a hardware company for specs,” says SuSE CTO Dirk Hohndel, “most likely you would not receive an answer at all, or you would receive a polite ‘go away.’”
Today neither Intel nor AMD are telling Linux developers to “go away.” Though the information came at a later point in the chip design process, Intel too has released the architectural specification for IA-64 as well as an emulator and a community Web site for its 64-bit Linux port.
The difference between the two companies is not so much what information they are making available, but rather when it becomes available. AMD says that one message it heard consistently from Linux developers was that they wanted to be involved at the earliest possible stage of development, so the company made a conscious effort to release information as early as possible, even at the risk of divulging information it would rather have kept from its competitors.
“AMD got going on the project before they had the hardware,” observes GNU C Compiler developer Mark Mitchell, whose CodeSourcery LLC company maintains the X86-64 Web site. “They showed up at LinuxWorld and threw a party. They made themselves visible in the Linux community,” he says, adding, “They gave the community a chance to get involved in the design process.”
In open source fashion, the community involvement led to new ideas. “We got comments on our public mailing list from people that were interested in the port, but not affiliated with AMD,” says SuSE developer Andreas Jaeger.
When AMD released the spec for x86-64 at LinuxWorld, it wasn’t just open source developers that noticed. The move caught the attention of a small Swedish software company called Virtutech AB, which just happened to be in the business of writing commercial simulators. Virtutech’s engineers cobbled together a hybrid simulator, using their own Simics software. The Virtutech developers waited until AMD released its own simulator (called SimNow) a few months later. They figured that if they could get their own simulator to run significantly faster than AMD’s, it might catch the chip-maker’s attention.
After looking at SimNow, “we figured that we could run Hammer code about 100 times faster,” remembers Virtutech CEO Peter Magnusson. “They came to us and said, ‘Hey, we have this simulator,’” says AMD Marketing Manager Bob Mitton, “and we said, ‘you’re kidding.’ And we looked at it and went, ‘Holy! This is great!’” Soon AMD had purchased a few thousand copies of the simulator and began to seed the open source community with them.
|Intel refuses to open source their compiler, which I think is a big mistake. — Bruce Perens, HP|
When Itanium and Hammer systems begin to ship, one thing is certain: people will need to recompile their applications if they want to take advantage of the chips’ 64-bit architectures. This may be one reason that the highly technical Linux community, where compiling applications is an everyday occurrence, is of particular interest to the chip vendors. But compiler technology is also one area where the different approaches behind X86-64 and IA-64 will be most visible.
Because X86-64 is simply an extension of Intel’s IA-32 instruction set, it does not present significant new challenges for compilers that work on current IA-32 systems. IA-64 machines, on the other hand, are based on the Very Long Instruction Word (VLIW) technology. Essentially, this means that Itanium chips can execute up to three instructions at once, provided the compilers know how to properly order them. The problem is that Linux’s most popular compiler, GCC, does not optimize code for VLIW, and furthermore, it will require a fair bit of work before it will be able to. GCC developer Mark Mitchell says that Intel’s current Itanium compilers are six to ten times faster than GCC and that there’s, “a long way to go before GCC generates good code for Itanium.”
According to HP Linux evangelist Bruce Perens, this compiler problem is serious, but it is also something that can be fixed. Intel has already sponsored some development work on GCC for Itanium, but, according to Perens, “part of the problem is that Intel is not releasing as much information as they should.” He adds, “Intel refuses to open source their compiler, which I think is a big mistake. They sell CPUs, not compilers.” Perens says that although his company plans to make its proprietary compilers part of HP’s value-add, “If we have to open source pieces of [the HP compilers], we will.”
If Intel is not a developer tools company, it has yet to get the message. According to a company spokesperson, the chipmaker is developing a C++ and Fortran compiler for Linux on IA-32 and Itanium.
The New Age
So what’s a Linux user to do? First of all, not every application will benefit by being extended to 64-bits. GNOME and KDE users may not notice a big difference between Pentium and Itanium systems, but applications that routinely manipulate large numbers will see the biggest performance increase. “If the number you’re talking about is bigger than 4 billion, it doesn’t fit into 32 bits,” says GCC developer Mitchell. “With a 64-bit chip, the number you can go up to is astronomically huge, so you can manipulate those numbers with just one instruction.” Because of this ability to handle large numbers, 64-bit systems can more easily handle memory addresses that are larger than 4 GB, and they can keep track of more processes running on the same system.
Analysts say that the first wave of Itanium processors will probably be of interest to developers and the curious. They will not support a large number of commercial applications and, because of the GCC compiler problems, they probably will not deliver the best performance for open source apps. The good news is that, because Linux and many of its tools and applications have already been ported to 64-bit systems like UltraSPARC and Alpha, most Itanium ports seem to be happening without major rewrites. And once the GCC team completes the non-trivial task of optimizing its free compiler for Itanium, the open source world should do very well on Intel’s new hardware.
Of course, by next year, AMD will begin shipping the first in its Hammer line of processors. Nathan Brookwood, a principal analyst with Insight 64, says that because AMD’s systems are expected to cost and perform as well as high-end IA-32 systems, they have a good chance of becoming popular. He adds that open source apps, with their history of cross-platform porting, will probably play an important role in Hammer’s adoption. “Even if the established software players are not particularly interested in supporting another instruction set,” he says, “there will be enough people on the sidelines with the ability to adapt Linux’s source code, that it’ll happen anyway.”
So the days of Linux the underdog may finally be over. As Linux developers port their OS and applications to these new 64-bit platforms, they are enjoying an unprecedented degree of openness and support from the chip vendors. In addition, they may also be feeling some degree of satisfaction from the fact that Microsoft’s Windows development team finally has to learn how to support more than one microprocessor — something that Linux has done for a very long time.
These 64-bit chips may soon appear in a candy store near you:
Intel’s Itanium Line
With clock speeds of 733 MHz and 800 MHz and Xeon-compatible pricing, Merced systems are expected to appeal to the curious — developers and IT professionals getting their first look at Itanium systems; however, they are not expected to be used in many wide-spread deployments.
Intel demonstrated its first McKinley box at its worldwide developer conference this past February. McKinley systems will have clock speeds over 1 GHz, and pilot systems will start trickling out of Intel by year’s end. The McKinley processor will be widely available sometime in 2002.
Madison will be Intel’s first chip based on .13-micron technology. Intel is not yet releasing details on its availability.
Deerfield is expected to be the high-volume, lower-end, 64-bit offering. Think of it as the 64-bit equivalent of Celeron. It is slated to be released in conjunction with its higher-end cousin, Madison.
AMD’s Hammer Line
The first chip based on the Hammer architecture is expected to ship in the second half of 2002. Based on .13-micron technology, it will have clock speeds above 2 GHz and will be targeted at 1- and 2-way machines.
Sledgehammer will be a server-specific Hammer chip. It will power 4- and 8-way systems and feature a larger-on-die cache.
Robert McMillan is editor at large with Linux Magazine. He can be reached at firstname.lastname@example.org.
Fatal error: Call to undefined function aa_author_bios() in /opt/apache/dms/b2b/linux-mag.com/site/www/htdocs/wp-content/themes/linuxmag/single.php on line 62