I've been an IT industry analyst for almost 10 years. I've seen many technologies come, go, or fail to even arrive in the first place. However, during that time, a few techs have emerged that play a big part in fundamentally defining how businesses do computing. Most first emerged prior to 2000, but it has been during the past decade that they've truly changed things.
1. x86 processors were already well entrenched in corporate computing by the end of the 1990s, especially in their role as the "(In)tel" part of "Wintel" servers running Windows NT. However, their dominant designer and manufacturer, Intel, was heading in a different direction to handle the inevitable transition to the 64-bit processors and operating systems needed to keep pace with growing memory requirements.
That new direction was Itanium, a clean sheet processor design by Intel and Hewlett-Packard intended to get away from all the legacy features of x86 and--not incidentally--cut the x86-compatible processor makers out of the picture. The Itanium family remains with us but primarily as a processor for high-end HP servers. It was AMD that first added 64-bit extensions to x86 but Intel felt compelled to follow. And it was this backwardly compatible version of x86 that is the mainstream 64-bit server processor, not Itanium.
2. The other big processor story of the decade is multicore. Near the end of 2000, Intel introduced the Pentium 4 processor based on the NetBurst microarchitecture. It was intended to eventually hit about 10GHz. In fact, it never got beyond 4GHz and came to be viewed as the last gasp of performance scaling through frequency.
AMD introduced its first multicore x86 Opteron processors for servers in 2005 which helped it gain market share for a time while Intel made major changes to its development plans and processes. IBM and Sun also aggressively pursued multi-core in their RISC lines. Specialty processors such as Azul's Vega and Tilera's TILE lines went even more radically multicore. In short, frequency is largely dead as a path to higher system performance, which will require a combination of more cores and specialty accelerators working in parallel.
3. When I first met Diane Greene, co-founder and then-CEO of VMware in the fall of 2000, VMware was already selling a product to developers that let them run multiple operating systems on a single workstation. But Diane was in town to pitch me on something new, a pair of new server virtualization products--GSX and ESX Server--that made it possible to consolidate multiple workloads on a single physical server and to provision them more quickly.
The basic concept goes all the way back to IBM's involvement with early developments in time-shared computing in Cambridge, Mass., during the early '60s. And all the RISC/Unix vendors of the time had their own approaches to slicing and dicing servers. However, it was VMware that brought server virtualization to the masses. Its product ran on standard x86 servers and it provided a way to consolidate workloads right at a time when IT purchases were dramatically slowing and anything that could save money was in vogue.
EMC bought VMware in 2003 for $635 million, a figure which it's hard to believe today was widely viewed as an overpayment. Today, server virtualization--an area where VMware remains the 800-lb. gorilla despite Microsoft's entry--continues to fundamentally change the way IT departments think about operating their data centers. Virtualization also underpins much of cloud computing, another major developing trend.
4. Linux and other open source were a big part of the dot-com and service provider build-out of the late 1990s.
But enterprises? Not so much. This 2001 research note had to argue that Linux was, in fact, ready for serious production use. And, whether "ready for the enterprise" is a meaningful question in the abstract, the fact remains that the Linux 2.4 kernel was widely regarded as the first version deserving of that description and it wasn't released until mid-2000. IBM began its big Linux push at about the same time.
Thus, I'd argue that it's been this past decade and not the prior one that has seen Linux and open source truly become a pervasive part of computing. That's not to say that open-source has replaced all other software. But it has heavily influenced how companies do development, engage with user and developer communities, and provide access to their products--even when the software in question is proprietary.
5. My last entry has the greatest overlap with the consumer space. That's not a coincidence, given that mobile devices are a very visible example of what Citrix CEO Mark Templeton calls the "comsumerization of IT."
Mobile devices encompass at least a couple of different things. The most obvious entrant is probably the smartphone--first in the guise of the BlackBerry and more recently the iPhone. We are now at the point where you can carry a bona-fide computer in your pocket, complete with GPS and other sensors, and can run applications that you install. As my colleague Jonathan Eunice has noted, it really is a transformational experience relative to, say, my older Treo. It also represents the reality of the modern smartphone that, for many, it's increasingly about mail, texting, and social media and not, you know, phoning.
However, the smartphone doesn't deserve all the limelight. The noughts have also seen the laptop computer transform. I'm not talking about the form factor so much--although Netbooks have gotten their share of attention. Rather I'm talking about the way that we can use them.
I've had laptops since the 1990s but it wasn't until about 2001 that conferences and other venues started to put up Wi-Fi networks. They worked fitfully (some things haven't changed as much as we might like), but this was the beginning of the connected laptop rather than the merely mobile laptop.
And that's why I see the smartphone and the laptop as part of the same mega-trend. It's not about a particular form factor or usage model. It's about (almost) always being connected to applications that increasingly live largely in the network.
The nice thing about standards is that there are so many of them.
This old saw is arguably less true than in years past. Today, for a lot of reasons, there's more pressure to reach agreement on one way to do a certain thing. (Think the HD DVD vs. Blu-ray debacle for an example of what happens when vendors can't agree on a single approach.)
Standards aren't a single thing. Some have been blessed with the appropriate incantations by some official or quasi-official body. Others come from an industry consortium. And still others are "de facto" (or at least began life that way)--the result of a dominant company or just a default way of doing things.
The purist will argue that just being widely used doesn't make something a standard. I agree up to a point and only use the "standard" term in this case for things for are truly ubiquitous. Contrariwise, a rigorous formal ratification process is no guarantee of success.
But some standards do win big and become part of just how IT gets done. Here are some of them.
Like many other successful standards, Ethernet has remained a fixture in local area networks for so many years in part by adapting to many successive waves of technology. First developed in the famous Xerox PARC labs in the mid-1970s, it initially ran over coaxial cable but soon moved to twisted pair cable with the 10 Mbit/second generation. 10 Gbit/second Ethernet is now starting to roll out along with a variety of additions to the specification that make it more suitable as a high-performance unified fabric.
Ethernet's initial success resulted in no small part from coordinated standardization efforts beginning in the IEEE. This helped it beat out alternatives, most notably IBM's Token Ring. Over time, Ethernet's ubiquity and the cost benefits provided by this volume helped it largely stave off server interconnect challengers. InfiniBand has had wins in high-performance computing and certain other clustering applications, but it didn't displace Ethernet as a "server area network" as early promoters had hoped.
PCI, Peripheral Component Interconnect, had its beginnings as an Intel-developed bus for connecting internal cards within systems. The version 1.0 spec came out in 1992. Given the ubiquity of PCI these days, it's easy to forget that it only replaced a plethora of other busses both standardized and proprietary in x86 and, later, large Unix servers based on other processors over the course of nearly a decade.
Nor was the process steady. Although PCI was initially introduced in part to replace the VESA Local Bus for graphics cards--which it eventually did--PCI was itself replaced by AGP (Accelerated Graphics Port) for a time prior to the PCI Express generation.
PCI Express makes for an interesting case study in the marketing of standards. With technology bumping up against the limits of parallel I/O busses like conventional PCI, the Arapahoe Working Group--spearheaded by Intel--started pushing a new serial interconnect standard in about 2001. Arapahoe's success was by no means pre-ordained. AMD's HyperTransport was one alternative among several.
Arapahoe required hardware that was largely different from PCI but it was compatible with PCI's software model in a number of respects. And this was enough to get Arapahoe adopted by the keeper of the PCI standard, the PCI-SIG, and get the SIG's imprimatur on what would now be called PCI Express. And that helped make it the obvious heir to PCI. Names matter. (Here's a more detailed accounting of PCI Express and its history.)
It's easy to forget just how painful it could be, in the years before USB (Universal Serial Bus), to connect external peripherals to a computer system. RS-232, a long-used and successful standard in its own right, was the most common way. It was also a way that could easily devolve into examinations of cable pin-outs, interrupt channels, and memory addresses.
USB was a cooperative effort by a group of large technology vendors who founded a non-profit corporation to manage the specification. Version 1.0 was introduced in 1996. Now up to version 3.0, USB has become the standard way to connect external peripherals to PCs; it's also commonly used on servers for devices such as printers.
There's a spec for wireless USB but, like other standards intended to connect peripherals to computers wirelessly, it's never taken off. The current such "personal area network" getting the most buzz is My WiFi from Intel.
USB's primary competition has been FireWire, Apple's name for IEEE 1394. Unlike USB, it does not need a host computer and is faster than the USB 2.0 generation. However, it didn't catch on widely in the computer industry outside of Apple (which is phasing it out in favor of USB) and video equipment.
TCP/IP refers to the combination of two protocols: Transmission Control Protocol and Internet Protocol. Together, they are among the most important pieces of software underpinning the Internet which transitioned to using TCP/IP in 1983. Work on TCP began under the auspices of the Defense Advanced Research Projects Agency (DARPA) a decade earlier but, along the way, the software stack was re-architected to add IP as the early Internet grew.
Like many of the Internet's building blocks, TCP/IP was firmly entrenched before commercial interests got involved to any significant degree and, indeed, before most of the world at large had any real notion of the Internet's existence. The general public came to know the Internet through the World Wide Web, an outgrowth of Tim Berners-Lee's development of HTML at CERN, in the 1990s. Thus HTML, as well, is a key standard.
At the time that TCP/IP was gaining momentum, the International Organization for Standardization (ISO) spearheaded a large project to standardize networking. The "OSI model" remains the standard way to think about layers of the networking stack. If you talk about a switch being "Layer 4," you're using OSI terminology. But the specific protocols developed to go with the model were never widely used. (TCP/IP largely maps to the layers defined in the OSI model.)
The x86 architecture is perhaps the canonical example of a de facto standard driven primarily by a single vendor: Intel. Microsoft Windows is also in the running, but it was very arguably x86's ubiquity in a segment of the market open to relatively low-cost packaged software that made the rise of Windows possible. Over the past decade, AMD has also driven x86 innovations--most notably 64-bit extensions. However, it was Intel that had the biggest hand in shifting the industry from a structure in which each company did everything from fabricating processors to writing operating systems to developing databases to one in which different companies tend to specialize in one part of the technology ecosystem.
x86 emerged as a dominant chip architecture for a variety of reasons. IBM designed Intel's 8088 into the first important business PC. It got this win and others at a time when the world was rapidly computerizing. And Intel optimized itself to ride key technology trends while divesting itself of businesses, such as memory, as they commoditized.
Finally, here are a few others that could make a list like this one:
Wi-Fi played a big role in making personal computers more mobile--which is why Intel pushed it so hard.
VGA is the computing video standard that finally helped merge a rather splintered landscape and had a good long reign. (The latest video interconnect trend is a shift to HDMI--representing a coming together of computing and consumer electronics standards.)
SCSI was the first storage interconnect to merge in a big way a disparate set of existing connection schemes, both proprietary and more or less standardized. However, storage has remained an area where different standards are used for different purposes. That's changing to a degree with SATA, however, which we now see in both PCs and data centers.
Multicore processors are here to stay and the number of cores that we'll see packed onto a single chip is only going to increase. That's because Moore's Law is only indirectly about performance; it's directly about increasing the number of transistors. And, for a variety of reasons, turning those transistors into performance today largely depends on cranking up the core count.
There's a downside to this approach though. Programs that consist of a single thread of instructions can only run on a single core. This in turn means that they're not going to get much faster no matter how many cores a chip adds. Running faster means going multi-threaded--splitting up the task and working on the different pieces in parallel. The problem is that programming multi-threaded applications introduces complications that don't exist with single-threading.
These complications and ways to overcome them was the topic of my conversation with James Reinders at the Intel Developers Forum in September. Reinders is the director of marketing and business for Intel's Software Development Products. He's an expert on parallelism and his most recent book covered the C++ extensions for parallelism provided by Intel Threaded Building Blocks.
In part 1 of this discussion we talked about how to think about performance in a parallel programming environment, why such environments give developers headaches, and what can be done about it.
Reinders began by noting that developers fall into roughly two groups when it comes to parallel programming: those who are still concerned about ultimate performance even in a parallel world and those who are just looking for a way to deal with it at all.
The challenge is understanding what we're trying to introduce, how to use parallelism, but with programmer efficiency. Because programmers don't need yet another thing to worry about. There's plenty of those out there.
And we need to be a little more relaxed about the performance. The people who start asking me about efficiency in every last cycle used and such--I characterize them as people we need to talk to more about our high-performance computing-oriented tools that give you full control. And other people are "I don't even know how to approach parallelism." I think there is a different set of ways to talk about the problem.
The problems with this second group comes down to the fact that most programmers are used to dealing with something called "sequential semantics." A detailed description of programming semantics is a complex computer science topic but, at a high level, sequential semantics means more or less what it sounds like it sounds; instructions follow one after another and execute in the order that they are written.
If you store the number "1" in variable A, then store the number "2" in variable B, and then add them together in a third instruction, you can be confident that the answer will be "3." It won't depend on timing vagaries that might have caused the addition to happen before the stores. Most people start out programming sequentially using languages designed for that purpose.
Parallel programming, on the other hand, introduces concepts like data races (the answer is dependent on the timing of other events) and deadlocks (in which two threads are each waiting for the other to complete so that neither ever does). Here's Reinders:
If you've ever managed and got a bunch of people working on a project together, one of the headaches you get is coordinating with each other. What did Fred say to Sally? They're doing things out of order or whatever. Parallel programming can give you that same sort of headache.
The programming terminology you'll hear the compiler people use is "sequential semantics." One of the interesting areas is what can we do if we ensure sequential semantics. We recently acquired a team in Massachusetts who were working for a company called Cilk Arts.
Our hope is that Cilk can do a subset of what Threaded Building Blocks [TBB] can but preserve sequential semantics. We think we can do sequential semantics, do a subset of what TBB does, since we're introducing keywords into the compiler--that has some disadvantages because it's not as portable--but we think we might be able to magically give you sequential semantics and not give up performance. That's a big if.
Now why would we invest in that?
Because there are a lot programmers who have been getting along just fine with sequential programming. But when you tell them to add this or that for parallelism, a big thing that trips them up is that you no longer obey sequential semantics; you have more than one thing running around and you get data races, deadlocks, and it doesn't feel comfortable.
Now some people will argue that you need to do these things to get good performance. We have the feeling that in some cases you don't need to take that big of a leap to get pretty good performance.
And no one's going to criticize your app on a quad core for being only 70 percent efficient.
From there we moved on to data parallelism which focuses on distributing data across processing elements. It contrasts with the task parallelism that we commonly associate with the term parallel programming. Pervasive DataRush is one commercial product based on a data parallelism model. APL, the language with the strange symbols (for those with long memories), is often considered the first data parallel language. There have been a variety of others, often extensions to more conventional languages like C and FORTRAN, but none were widely used.
The other thing we're looking at is data parallelism. And that's where we acquired the RapidMind team and combined them with our Ct [C for Throughput Computing] team.
Data parallelism just takes it one step further. Data parallelism is all about the parallelism in the data. So you're talking about the data when you program.
And once you start talking about the data, the tools underneath can move the data around. Leaving the data management up to the programmer [as with Cilk and TBB] turns out to be a terrific headache. This applies equally to a cluster where they don't share memory or a GPU and a CPU in the same system.
But a language like RapidMind or Ct can address that problem. And CUDA and OpenCL can too [frameworks primarily oriented towards heterogeneous processing that uses graphics cores for computing tasks] but RapidMind and Ct are at a much higher level of abstraction which means that we're betting on the idea that we can attract more developers and give up some efficiency.
Part 2 of our conversation will cover cloud computing, functional and dynamic languages, and what needs to happen with respect to programmer education.
SAN FRANCISCO--General manager of Intel Architecture Group Sean Maloney's announcement of a reference design for a "micro server" during his Tuesday afternoon keynote at the Intel Developer Forum brought me a sense of deja vu.
Intel's Sean Maloney holding microserver.
(Credit: Intel)He disclosed "a new ultra-low-voltage Intel Xeon 3000 series processor featuring a TDP (Thermal Design Power) of only 30 watts. To complement the broad range of dense and power-optimized platform offerings, Intel also demonstrated publicly for the first time a single-socket 'micro server' reference system which will help enable micro server innovation and future specification." Intel plans to ship the 30-watt dual-core chip in Q1 on 2010; a 45-watt quad-core version is set to ship immediately.
A reference system is primarily intended to demonstrate a concept. It provides a hands-on experience for partners and customers and therefore an opportunity to experiment with and fine-tune the basic approach. The microserver reference design will accommodate 16 server modules in a 5U-high (8.75-inch) chassis. The server boards are approximately 8-inches by 4.5-inches.
Jason Waxman, the general manager of high density computing at Intel, told me that they see the primary target for this class of system as "hosting companies that do a lot of white boxes." White boxes are systems that are often assembled in-house from component parts such as motherboards and cases. Waxman added that such companies nonetheless want many of the features associated with servers--such as memory with error correcting code (ECC).
In Intel's view of the world, microservers very much target service providers and companies that host busy Web sites and otherwise are associated with high-scale network computing. It sees this market as distinct from large high-performance computing (HPC) installations. Vendors such as HP tend to treat network computing and HPC as more of an overlapping customer group.
My deja vu when it comes to microservers relates to the fact that we've seen them before. They used to be called blades.
That's not to say that blade servers don't already exist today, but they've largely evolved into a much different concept from how they were initially conceived. The blades sold today by the likes of Cisco, Dell, HP, and IBM are about virtualization and integration. They pull together computing, networking, and storage and tightly integrate them both physically and through software. They are, in a sense, a form of scale-out consolidation.
Sun has largely eschewed this integration with their blade product line. However, Sun blades are heavily focused on high-performance computing--even to the point of integrating the HPC-centric InfiniBand interconnect on some of its products.
Rather, microservers hark back to the days of RLX Technologies, the company that did the most to promote blade servers during the Internet boom of circa 2000. Microservers are simply thin servers--compact, cheap, and simple. They provide cable simplification. They let hosting providers allocate low-cost physical servers to customers who don't want to share using virtualization.
Microservers bring blades back to their roots. Everything old is new again.
SAN FRANCISCO--The broad outline of Intel CEO Paul Otellini's keynote speech at the Intel Developer Forum on Tuesday was largely familiar. A single Intel Architecture (IA--which is to say x86) spanning servers in the data center to electronics embedded in a television.
This is a self-serving argument coming from Intel. After all, Intel already holds commanding share throughout much of the traditional PC and server space. Translating that success into newer and developing areas of the market where Intel has not historically played--or where, in many cases, the market has not even historically existed--would be a huge win.
But Intel argues that it's not purely a matter of its own interests. Rather, developers and, ultimately, end users benefit from an architecture spanning the small to the large because it lets them leverage common tools and other software.
In the past, one of Intel's proof points for this claim was to demonstrate issues associated with browsing Web sites on smartphones and other devices running non-IA processors. However, such an argument wouldn't be very convincing today in the light of the generally high-fidelity browsing experience offered by products like the iPhone despite the fact that they don't use IA-architecture processors.
Intel even undermines its own argument for commonality when it admits--as Otellini did in his keynote speech--that "handhelds have to rethink the user experience," a comment followed by a demo of a prototype interface running on Moblin. Moblin is an open-source project focused on building a Linux-based platform optimized for the next generation of mobile devices.
Commonality as a benefit and principle is hard to argue against in the abstract. But handhelds differ in many ways from PCs. User experience, given differences in screen size and the way users interact with devices that don't have a full-size keyboard, is one obvious area. However, optimizations around power usage, performance, and component integration are also much different.
In short, software that runs across a wide range of device form factors and types will hardly be common across that range even if the underlying processor architecture is. At the same time, many of the software technologies visible to both developers and users--including Flash, browsers, and Linux--increasingly span a range of processor architectures.
None of this should be taken to suggest that Intel's Atom--the processor family that's spearheading the company's push into Netbooks, handhelds, and consumer electronics--won't succeed. Perhaps as Otellini suggested, in five years, Intel may indeed sell more system-on-a-chip (SoC) processors based on its Atom processor than traditional microprocessors.
However, to the degree that Intel succeeds in this area of the market, it won't primarily be because Atom is x86. It will be because Atom beats out its competitors on metrics such as power efficiency, cost, size, and the ability of Intel partners to leverage it for their own custom designs.
A good software development framework on Atom matters too and building from an IA foundation will help there. But ultimately it's about the chip, not the architecture.
I've been getting a fair number of questions about multi-threading the past couple of weeks. The reason is that Intel has been previewing its "Nehalem EX" Xeon processor in advance of Advanced Micro Device's six-core "Istanbul" CPU launch. Intel's Nehalem generation has simultaneous multi-threading (SMT)--which Intel calls Hyper-Threading (HT)--while Istanbul does not.
I wrote about this topic in depth a couple of years back in "Gradations of Threading," but it's worth reviewing in the context of these new server processors.
First, a little terminology.
A thread is a sequence of instructions that can execute in parallel with other threads. The details of what exactly constitutes a thread and the relationship between threads and other structures such as processes vary by operating system. However, for our purposes here, think of a thread as an independent task.
Simultaneous multi-threading.
(Credit: Illuminata)A core is, in most respects, a complete processor that includes all the hardware such as execution units, registers, and so forth required to execute a sequence of instructions. Although multiple cores on a single die or in a single package (i.e. a chip or socket) may share certain resources such as cache memories, logically each core is a full central processing unit (CPU). That multiple cores are packaged together today is essentially an implementation detail that relates to getting the best performance out of the most economically sized silicon die.
Absent multithreading, each core can execute one thread at a time, running that thread until it has completed or until the operating system scheduler swaps it out for another thread.
SMT changes that 1:1 relationship. On a processor with SMT, more than one thread can execute on a single core at the same time--in the case of HT, it's two threads per core.
SMT potentially allows a processor to be more efficiently utilized. The reason is that modern microprocessors have multiple execution units within each core. For example, they have separate logic to handle integer operations and floating-point operations. Thus, in principle, if a thread with mostly integer operations runs concurrently with a thread that mostly crunches floating-point numbers, we could keep the processor busier by running both threads at the same time than we could running them sequentially.
The other main benefit is to hide memory latency. CPUs have to operate on data and that data has to ultimately come from memory or disk. Computer designs incorporate all sorts of techniques--such as caches and prefetching--to keep data close to processors in time and space. Nonetheless, processors still spend a lot of time waiting for data to arrive from relatively pokey memory. SMT lets a CPU quickly switch away from a thread that's sitting idle waiting for associated data to arrive.
SMT is therefore essentially a technique to use a processor more efficiently. It does not itself add execution resources to a core. And, in fact, the duplicated hardware and other logic that SMT requires to function (such as registers) takes space away from implementing other features (such as larger caches) that could themselves provide alternative ways to boost chip performance.
Intel's HT implementation--a fairly "lightweight" approach relative to IBM's on its Power processor--uses on the order of 5 percent of the total chip area to deliver typical performance gains of between 10 and 20 percent. (Optimized applications can see bigger gains. On the other hand, applications that are already efficiently using the CPU's execution units--or that are bottlenecked in ways that SMT can't assist with--may see no gain at all.)
Ultimately SMT is just one performance feature among many that may or may not be a match for a given processor's design. In Intel's case, it's been in some x86 designs but not others since it debuted on the Pentium 4; Itanium uses a simpler Temporal multi-threading approach.
SMT's in the plus column of the features checklist. But what really matters is overall processor performance on relevant workloads and platform capabilities. SMT is one tool to get there.
Intel has slipped out a revised schedule for its next-generation Itanium processor, code-named Tukwila. Again. This time it's into 2010.
Intel released a statement Thursday on the schedule changes. It reads in part:
During final system-level testing, we identified an opportunity to further enhance application scalability best optimized for high-end systems. This will result in a change to the Tukwila shipping schedule to Q1 2010.
In addition to better meeting the needs of our current Itanium customers, we believe this change will allow Tukwila systems a greater opportunity to gain share versus proprietary RISC solutions including Sparc and IBM Power. Tukwila is tracking to 2x performance vs its predecessor chip. This change is about delivering even further application scalability for mission critical workloads.
That may be true. However, the fact remains that this is yet another delay to the program. This will put Tukwila's introduction more than two years after the debut of the current "Montvale" generation--which itself was a delayed and modest speedbump to "Montecito"--and one that Intel barely announced publicly.
Tukwila has had an especially bumpy history. This generation of Itanium processor began life as a chip project code-named Tanglewood and was said to be envisioned as a radical multicore design by the ex-Digital Equipment Alpha engineers who worked on it.
First, Intel changed the code-name to Tukwila after the Tanglewood Music Festival complained. This was back in 2003--to give you an idea of how long this particular project has been weaving its way through development. At that time, it was slated for something in the neighborhood of a 2007 release.
Then the chip apparently went through a variety of significant design changes. It will still be the first Itanium to sport Intel's serial processor communications link (QuickPath Interconnect--QPI) and integrated memory controllers. Those are both major enhancements, but otherwise Tukwila is a more conventional quad-core evolution of current Itanium designs. It will also be manufactured with a 65-nanometer process instead of the denser 45-nanometer process already used by the newest Intel Xeon CPUs. Along the way, the chip's schedule has been publicly pushed back a number of times, now to early 2010.
As a practical matter, delays to Itanium matter less to Intel and the server makers that use it (meaning Hewlett-Packard first and foremost) than in the case of x86 Xeon, where a delay of a few months can have a major revenue impact--vis-a-vis Advanced Micro Device's Barcelona.
Buyers of high-end servers like HP's Superdome and NonStop value vendor relationships, reliability, and a wide range of enterprise-class capabilities far more than they do the last drop of performance. HP has done a good job of things like leveraging its c-Class BladeSystem infrastructure for its Itanium-based Integrity servers and putting together systematic go-to-market programs with partners such as SAP.
Nonetheless, at some point, ongoing delays have to hurt competitiveness--especially given how IBM's Power systems have been hitting on all cylinders the past few years.
This is a big week for Intel processor-based server announcements. Intel is rolling out its new "Nehalem" Xeon 5500 processor for dual-socket servers, far and away the biggest chunk of the server market by volume.
As Brooke Crothers notes on this CNET Blog Network post, "Nehalem offers some important firsts for Intel, including an integrated memory controller for better performance, hyper-threading for up to 16 virtual cores (which improves multitasking), and Turbo Boost Technology, which dynamically increases the processor's frequency (speed), as needed."
Just about any new Intel Xeon processor is paired with a spate of server announcements--after all, it's the servers that most end users buy not the chips. However, because Nehalem gives the heart of the server market such a nice performance boost, this launch is bigger than most. All the big system suppliers are making significant product introductions.
Take HP, for example. Paul Gottsegan, who leads marketing for HP's Industry Standard Servers (ISS) group, described the launch of their new ProLiant (x86) servers to me as "the biggest announcement in 20 years for ISS."
What really struck me about the HP launch though wasn't its scope--broad though it was.
Rather, it was that HP didn't take it as an opportunity to pile on an endless litany of speeds and feeds. Sure, it provided me with specifications but in the vein of supporting data rather than the core of the announcement. HP similarly focused primarily on higher-level operational and business value messages at its Technology Solutions Group (TSG) industry analyst event in Boston last week. (TSG is the business unit within HP that includes servers, software, and service.)
Unsurprisingly, in the current climate, a lot of that value message is around doing more without spending more.
The HP ProLiant G6 line's advances in energy efficiency, virtualization and automation, make it ideal for all customers. These innovations are combined with comprehensive financing programs and service offerings to redefine server economics. The new HP ProLiant G6 servers are available in 11 standards-based tower, rack and blade platforms. This represents the largest HP ProLiant rollout in company history.
"Now more than ever, customers want the best possible return on their server investments," said Christine Reischl, senior vice president and general manager, Industry Standard Servers, HP. "Building on HP's long history of hardware and software development, G6 brings together the best HP innovations in energy efficiency, virtualization and services to enable our customers to do more with less."
Now, if you haven't been a longtime HP follower as I have, the fact that technology isn't front and center may seem unremarkable. Sure, IT vendors have a proclivity to getting lost down in the weeds. But the largest and most sophisticated of those vendors--of which HP is certainly one--do understand that customers buy outcomes rather than individual products.
However, HP as a whole has perhaps struggled more than most to build on, rather than lead with, a technology message. The company is, after all, in no small part an amalgam of very engineering-centric cultures--the old HP and Digital Equipment perhaps most of all. But also Compaq and Tandem in their own ways.
This is a solid server rollout. But it's also a clear indication of HP's evolution.
Intel perhaps most of all, but a lot of technology vendors are pushing the idea of MIDs (Mobile Internet Devices) and Netbooks (essentially scale-down, low-cost notebooks). Intel's interest here is pretty straightforward: the more a mobile device resembles a traditional PC, the more Intel's x86 franchise gives it a leg-up. By contrast, smartphones are based on any number of low-power processors, typically something other than x86 architecture.
I'm skeptical that these categories between the smartphone and the notebook will amount to a whole lot.
The issue I see with MIDs and Netbooks in the general case, however, is essentially a matter of form factor.
One the one hand, smartphones fit easily in most pockets. The downside is a small screen and text input that is largely by thumb, rather than by finger. Furthermore, because smartphones have historically been built using such a hodgepodge of hardware and software--including browsers--Website compatibility has been spotty at best, even leaving aside the (significant) issues that a smaller screen area introduces.
At the other end of the scale are familiar notebooks. Even the more portable varieties have more-or-less full-size keyboards and screen. Besides relatively high cost and the need to maintain and update a full-fledged operating system on a PC, notebooks weigh a few pounds and pit in a backpack or briefcase form factor--not a pocket, however oversized.
Against this backdrop, one can imagine Netbooks that sit in a kitchen to look up recipes or a MID that functions as a mobile browser and entertainment gadget somewhat in the vein of an iPod Touch. However, these scenarios feel like stretching to me. The cellphone is ubiquitous and highly portable (and smartphone browsers will get better). The notebook is well-suited to keyboard input and rich Website display (and will inevitably get ever smaller and lighter).
What do the alternatives offer?
A MID is a form factor that is neither as portable as a smartphone nor as full-functioned as a notebook. A Netbook is a notebook that is underpowered and otherwise compromised. At a low enough price point, perhaps. But the One Laptop Per Child experience suggests that the most aggressive price points may well be too aggressive to be practical.
In short, at least in a market where almost everyone has a cellphone and notebooks are the full-function PC of choice, it's hard to see the compromises of the MID and the Netbook as anything but too much pain for too little gain.
All that said, I'm now going to do something that used to intensely annoy a former editor of mine who never let the facts interfere with a good argument. I'm going to qualify my skepticism. By analogy, people ride and pedal all manner of vehicles. Some, such as bicycles and cars, are clearly mainstream. A few are true oddballs (unicycles). Some have very specific use cases (two-seater cars). Others are generally uncommon in the US but are relatively common in other locations (scooters).
Perhaps MIDs or Netbooks will emerge as the two-seaters or even the scooters of the computer world. Truly mainstream device? Probably not. But the uber-portable and inexpensive notebook, in particular, could find takers in the developing world or as a third- or fourth household PC in more developed nations. Especially as Moore's Law and other technical advances bring faster processors and bigger storage to even the most entry of price points.
There was a time when Advanced Micro Devices was on a roll, and really seemed to have Intel's number--especially in the server space.
AMD's Opteron processor represented a significant advance in x86 processor design, causing Intel no end of headaches. More than any other single reason, Opteron is what forced Intel to largely rototill its product roadmap a couple of years back in order to switch its focus from frequency to multicore designs sooner than it had intended. For that matter, Intel may well have never added 64-bit extensions to its x86 processors had AMD not done so first. (Intel's plan and preference was for customers requiring the larger memory capacities allowed by 64-bit addressing to adopt Itanium processors instead.)
But then throughout 2007, Intel was seemingly hitting on all cylinders. It came into the year propelled by its"Woodcrest" Xeon processor, based on the new Core microarchitecture, and "Clovertown", the first x86 quad-core design. In September, it rolled out "Tigerton" (Xeon 7300) for four-socket servers and capped the year with the introduction of "Penryn," a new design that's the first to use Intel's 45-nanometer manufacturing process.
For its part, AMD turned in mostly poor financial results and had problems rolling out its new "Barcelona" quad-core processor. Its recent financial analysts day could not have been much fun for company execs. At the last minute, the company canceled an event for industry analysts a few weeks prior. Based on AMD's discussions and disclosures at its financial analysts day--as well as other discussions and happenings over the past year--here are some of my thoughts on where AMD stands today.
Barcelona was not just late, but disappointing. The two things go somewhat hand-in-hand of course. In the Moore's Law-driven processor business, even the most extraordinary or cleverly designed products aren't nearly as interesting six months or a year later. Even before the latest round of Barcelona delays, the announced product was clearly not the game-changer that AMD had suggested it would be. That's not to say that it doesn't perform reasonably and even have areas of particular performance strength (especially floating point and virtualization), but when you set the expectation of a home run and end up poking a single, people are bound to be disappointed.
Intel is doing things right. x86 processor sales are perhaps not quite a zero-sum game. Innovation and advances encourage sales and upgrades that wouldn't happen were they not present. However, there are still plenty of cases in which someone has decided to purchase an x86 server; they'll evaluate the options and make their selection. In this case, what matters isn't so much how absolutely good the Intel or AMD product is, but how they stack up relative to each other. Thus, when Intel was faltering, AMD's advantage derived both from its own good execution and Intel's bad execution. AMD hasn't done everything right over the past year, but a big part of their problem is that Intel hasn't done much wrong.
AMD's routes to market are stronger than they used to be. This is one area where AMD has continued to improve its position, even as its product advantages have shrunk. In 2000, AMD processors were designed into a single HP notebook. Around that same time I conducted a series of interviews with ISVs, OEMs, and end users to look into how they viewed the AMD brand relative to Intel. Bottom line? No one preferred AMD, and the vast majority strongly preferred Intel. Even in 2003, when AMD announced the much-anticipated Opteron at the Hudson Theater in New York, IBM was the only Tier 1 OEM on stage. The Barcelona launch included representatives of all the Tier 1 companies. And AMD has been gaining design wins in the client space as well. In short, to the degree that AMD can deliver competitive products, it has far more and far better avenues to actually sell them than it once had.
AMD is shifting its emphasis from server CPU performance to a view that's more about "platform" performance and functionality, on clients as well as servers. Specifically, Opteron performance has clearly been the tip of AMD's arrow. With Intel ramping up its 45-nm process, my take is that AMD recognizes that it will (at best) be just able to play second fiddle if it runs basically the same plays as Intel does. Some of this is about leveraging its ATI assets and integrating graphics processing units for "stream computing" as well as for virtualization. It's also about trying to find and exploit market segments where Intel may not be as focused. None of this is unreasonable, although the full realization of "Fusion" (the integration of GPUs on the processor) is near the end of the decade and Intel is also going after new market areas such as ultramobile PCs.
AMD had a good run when Intel was more or less sleeping. AMD took that opportunity to, among other things, establish itself as a mainstream supplier for enterprises and others. That's the good news. The bad news is that its current products don't offer an especially compelling reason for people to buy them.
