• On mySimon: Top Gifts For Him, Her, Mom, Dad & More!

The Pervasive Data Center

Read all 'Intel' posts in The Pervasive Data Center
November 5, 2009 6:00 AM PST

Intel's James Reinders on parallelism: Part 1

by Gordon Haff
  • 1 comment

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.

September 23, 2009 11:44 AM PDT

Microservers: Blades rebooted

by Gordon Haff
  • 5 comments

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.

September 22, 2009 11:32 AM PDT

Does Intel Architecture matter?

by Gordon Haff
  • 8 comments

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.

June 1, 2009 8:05 AM PDT

Multi-threading reviewed

by Gordon Haff
  • 3 comments

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.

May 21, 2009 3:34 AM PDT

Intel's Tukwila slips yet again

by Gordon Haff
  • 11 comments

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.

March 30, 2009 9:36 AM PDT

HP takes its Nehalem server message up a level

by Gordon Haff
  • 2 comments

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.

August 5, 2008 10:38 AM PDT

Why I'm skeptical about MIDs and Netbooks

by Gordon Haff
  • Post a comment

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.

December 17, 2007 6:50 AM PST

AMD's tough times

by Gordon Haff
  • Post a comment

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.

November 1, 2007 10:35 AM PDT

Itanium goes bump in the night

by Gordon Haff
  • Post a comment

Perhaps it was in observance of Halloween, but whatever the reason there was something a bit ghostly about Intel's October 31 announcement of its latest Itanium processor.

You had to peer hard to catch even a glimpse of the Intel Itanium Processor 9100 announcement--formerly known under the "Montvale" code name. Neither Intel nor HP (which sells something like 90 percent of the Itaniums that go out Intel's doors) held briefings on the new processor iteration, and even simple press releases dribbled out belatedly. It's the sort of treatment usually reserved for announcements of new sales offices or CEO speeches at obscure conferences. I suppose that they could have made the announcement on a Saturday if they wanted to be even more wraithlike--but this was pretty close.

To be sure, this was a fairly modest bump. Montvale barely edges its "Montecito" predecessor in frequency (1.66GHz vs. 1.6GHz, or about 4 percent). More important is the 667MHz front-side bus (FSB), which gives about 25 percent faster memory access. Reliability ("core-level lock-step") and power efficiency ("demand-based switching") tweaks round out the new features. Bigger changes await the future quad-core "Tukwila," due late 2008 or so; it will also sport an integrated memory controller and new serial interconnect.

One almost gets the sense that Intel and HP hoped that if they soft-pedaled this announcement, no one would notice and therefore, the usual suspects wouldn't revel in the opportunity to engage in Itanium-mocking. Well, that didn't work.

  • prev
  • 1
  • next
advertisement

About The Pervasive Data Center

This blog takes a deep (and often skeptical) look at trends big and small in the world of enterprise servers, data centers, and "Yotta-scale" computing. This means also taking into account the myriad of software, networks, and devices that are driving change in (or being driven by) these back-end systems. Stories posted to this blog may also appear on Illuminata's site.

Gordon Haff is a principal IT adviser for Illuminata of Nashua, N.H. Before becoming an IT industry analyst, Gordon held a variety of product-marketing positions at Data General, spanning more than a decade. He's programmed for DOS, Windows, and Linux; builds his own PCs; and holds engineering degrees from MIT and Dartmouth, with an MBA from Cornell. He is a member of the CNET Blog Network and is not an employee of CNET. Disclosure.

Add this feed to your online news reader

The Pervasive Data Center topics

Most Discussed