With IT bellwethers like IBM, Microsoft, Advanced Micro Devices, AT&T and Apple reporting earnings results for the worst quarter for IT since the dot-com bust, and Oracle announcing it will buy Sun Microsystems, this has been one of the most significant weeks of the decade for IT investors.
Advanced Micro Devices is designing a server chip with up to 16 cores, quadrupling the count of its current quad-core server chips, the company said Wednesday.
AMD can't say it, but Istanbul, its six-core, 45-nanometer processor, is ready. (Officially, it's set to be launched in the second half of this year).
Advanced Micro Devices shareholders on Wednesday voted in favour of spinning off the company's chip manufacturing operations into a separate company.
Chip maker Advanced Micro Devices will shed 1,100 more jobs and cut salaries as it tries to reduce costs in a tough economic environment, the company said Friday.
AMD expects revenue for its fourth quarter to be 25% lower than its third-quarter revenue.
AMD is jumping into the mini-notebook space, announcing that it will deliver processors next year for small laptops that can run basic applications such as web surfing and email.
There's a good deal that's special about AMD's new Shanghai server CPU. It's fabulous science, and fun for those of us who get dewy-eyed over the prospect of a 25% faster world switch time and immersion lithography. It makes the x86 battle interesting again because it carries AMD into territory that it must fight hard to win — the two-socket (2P) server space — and where innovation is sorely needed. AMD beat Intel's next-generation Nehalem server architecture to market while closing performance, price and power-efficiency gaps between Core 2 and Shanghai. Just as it did in the old days, AMD now claims that its best outruns Intel's best despite having a lower clock speed.
An ex-Intel employee accused of stealing US$1 billion (NZ$1.7 billion) worth of trade secrets and using them to help rival AMD was indicted in Massachusetts on Wednesday.
Advanced Micro Devices (AMD) plans to lay off 500 staff, the second round of job cuts to come from the company this year.
At its recent Developer Forum, Intel laid out the last remaining secrets of Nehalem, a remade x86 platform built around a highly integrated Core 2 microprocessor with on-board memory and point-to-point bus controllers. I fairly raved about it, a fact that caught some who view me as an AMD die-hard by surprise.
Being a chiphead, but well shy of a chipmaker, I needed an independent perspective on Intel's first substantial effort to carry the x86 platform beyond the standards and boundaries set by IBM's PC-AT. Intel finally dumped the shared bus. That doesn't set a new high for the industry, but it certainly redefines Intel and lays down a new road for Intel-based servers and workstations.
While I had a head full of Nehalem facts, what I lacked was balance. Intel's IDF sessions on Nehalem compared the platform and CPU architecture only to Intel's work to date which, while I wouldn't call it sub-par, had been out-engineered by AMD.
For a valid contrast, I need to weigh Nehalem against AMD's own 45nm quad-core technology, dubbed Shanghai. That's a platform/architecture shoot-out for the ages, and I'm all over it. But since neither technology is shipping yet, all I can compare is detailed specs and higher-altitude rhetoric. The specs will take some digging. Today I'll tackle the rhetoric, the rationale behind Intel's design decisions, and the packaging of those decisions as competitive advantages. How much of what Intel's done with Nehalem is actually unique, and will IT feel the difference?
I brought a slate of questions to AMD and invited an expert in AMD server architecture and platforms, to address them. We covered an enormous amount of ground. The upshot is this: AMD celebrates Intel's validation of innovations that AMD designed into Opteron closer to the turn of the century. The x86-64 instruction set, non-uniform memory access (NUMA, which gives each processor socket its own RAM), Direct Connect (Intel calls its incarnation QuickPath) socket-to-socket bus, on-chip independent memory and bus controllers, independent power control for each core, internal power and thermal management, multiple processors on a single contiguous mask, dedicated Level 2 cache for each core, and shorter pipelines are features that AMD claims as firsts in the x86 domain. Intel once blew off each of these features as irrelevant. Now Nehalem and related platforms adopt all of them.
This is a good thing. When Nehalem goes up against Shanghai, it's apples-to-apples on platforms, or at least it will be treated as such. Even though the savviest server buyers could grasp the scalability advantages of AMD's NUMA and Direct Connect over Intel's shared bus, AMD won't be able to put across subtler differences between AMD's and Intel's implementation of the same ideas. When platform differences get small enough to require debate among gearheads, there is little chance of translating platform engineering variations into criteria relevant to mainstream IT.
Intel hopes to get some traction with a feature that AMD lacks, an integrated power microcontroller. AMD had no specific observations to offer on a feature that Intel kept secret until a couple of weeks ago. On servers, AMD believes that power conservation is done most effectively at the wall: If a server isn't working hard enough, turn it off. That's my line, but it's a long slog to get IT to take up this idea. In the meantime, servers should be at least as clever as desktops at using less energy when they have less work to do.
I understand that AMD is frustrated by the very roadblock I've called out: No matter how ingenious chip engineers are, if Microsoft doesn't pick a feature up, it's as good as wasted effort. This is especially true of power management. If server BIOSes and Windows Server OSes don't leverage Intel's power management microcontroller any better than they do quad-core Opteron's designed-in efficiencies, then Intel's bragging point will be lost on all but notebook users. If Intel has enough sway to make Microsoft twiddle Nehalem's power knobs and dials, or better still, let the microcontroller manage them itself, then Microsoft will have to answer for failing to invest as much care in exploiting architectural and platform features unique to quad-core Opteron.
Intel did more than catch up in cache design for the Nehalem architecture. The huge, shared Level 2 cache has given way to a much smaller Level 2 cache dedicated to each core. Like AMD (and like some previous Intel Xeon designs), Nehalem adopts a three-level cache. Intel uses the Level 3 cache to implement cache probe filtering, a technique that cuts down on core-to-core bus traffic. The handling of cache is a major and palpable differentiator between CPU architectures, especially as other engineering gaps tighten. There is a lot of room for innovation here.
Intel makes marketing hay with the sort of esoteric innovations that grab my attention, but which AMD asserts won't be felt on the server side. One such feature is HyperThreading (HT). This Netburst feature got the axe when Intel went to Core. I always considered HT one of Intel's bolder engineering moves, and now we'll see how it fares in a modern setting.
AMD is betting that instead of pulling up to a 30% increase in performance with ideally-tuned workloads, HT will bring single-digit boosts. In AMD's view, HT came about as a means of giving the chip something to do while it was waiting for memory. Now that on-chip controllers and faster RAM knock memory latency down to a fraction of what it was in Pentium 4 heyday, there isn't that much waiting time to fill. I have higher expectations in the long run. I think that multithreading will become the smartest way to squeeze more performance out of a socket, especially as programmers and compilers get smarter about parallelisation of code.
AMD considers it unlikely that server applications will feel other Nehalem platform and architecture enhancements, such as Version 4.2 of the Streaming SIMD Extensions (SSE) and Intel's Application-Targeted Accelerators. Both require recoding, perhaps hand-coding to put to use. I see tremendous potential benefit, but it's only reachable where developers are willing to risk incompatibility with other types of systems.
There's the rub. At the platform level, Nehalem's advances will be felt by IT without requiring any change in software. To feel Nehalem's power management and architectural (CPU) performance tweaks requires new code. That's effort that high-performance computing and specialised verticals like medical imaging will shoulder, but as a rule, major ISVs shy away from forking code to bring advantages to a small fraction of the x86 server installed base. And as much as I enjoy handwritten in-line assembly code, it's not your average in-house coder's cup of tea.
AMD hopes to call attention to the fact that Nehalem requires new servers. AMD's message is one of platform longevity. Between serious platform revisions, AMD lets customers and OEMs do system upgrades with CPU swaps and BIOS updates. AMD's OEMs aren't consistent in enabling this — I don't know how many IBM server customers were able to get dual-core to quad-core Opteron chip upgrades. Longevity should matter a great deal as budgets tighten. If Intel feels it finally has a platform with some headroom to it, it might relax the projected expectation of full system replacement every two years.
Since AMD had the floor to itself, it couldn't resist taking one last shot. Now that Intel has shed much of its legacy system platform, it faces a legacy core architecture. Nehalem is still a modified Pentium III core. During the time that Intel has spent cleaning up its platform, AMD, whose server platform has neither had nor needed overhauling since gen-one Opteron, has been working on CPU architectures. Its most anticipated project is Fusion, a CPU that brings AMD's microprocessor, embedded, chipset and GPU chops, along with some time-proven big iron ideals, to bear on a single socket. Until AMD can blow Intel away again, it's comfortable with a share of the x86 server market.
The fact that Intel's platform has caught up to AMD's doesn't automatically put AMD at a disadvantage. What it does is level the field, which breeds aggressive innovation and pricing as close competitors fight to differentiate their products. Apples to apples in x86 servers is good for IT.
A former Intel design engineer has been charged with theft of trade secrets from the chip maker while secretly working for rival Advanced Micro Devices.
AMD has unveiled three triple-core processors, adding to several released earlier this year.
A Wall Street analyst is predicting that Advanced Micro Devices is preparing to spin off its manufacturing operations into a separate company and may announce the plan as soon as September 15.
While using an AMD Barcelona (quad-core Opteron) server to create a portable benchmarking kit for InfoWorld's Test Center, I discovered something unexpected: I could incur variances in some benchmark tests ranging from 10% to 60% through combined manipulation of the server's BIOS settings, BIOS version, compiler flags and OS release.
I attempted to document the impact that each individual change had on performance, but flipping one switch often changed the effect of all the others. This frustrating yet fascinating effort ran aground when I had fiddled with settings and flags so much that my testbed stabilised; I could no longer budge the results no matter what I did. Normally stability is a good thing, but in this case, I was more interested in investigating the variance than in eliminating it. If I tried to bring this case to an actual engineer, he or she would likely tell me it had all been a mirage.
Recently, I had an opportunity to put this matter to a whole panel of engineers, the brain trust that manages performance and power testing for AMD's server CPUs. I was told that I was seeing an effect that's widely known among CPU engineers, but seldom communicated to IT. The performance envelope of a CPU and chipset is cast in silicon, but sculpted in software. Long before you lay hands on a server, BIOS and OS engineers have reshaped its finely tuned logic in code, sometimes with the real intent of making it faster or more efficient in some way that AMD hadn't considered, sometimes to compensate for overall server design flaws, and sometimes to homogenise the server to flatten its performance relative to Intel's.
Perhaps there have been cases where AMD servers were made more powerful or efficient through software tuning that deviates from AMD's advice. I sincerely doubt it. Most times, trying to out-think AMD's engineers is a fruitless exercise, but system and OS makers do it all the time. When they get it wrong — and this is far easier to do than getting it right — it costs you. You end up with systems that aren't performing to their potential, are letting power efficiency features go unexploited, or both.
AMD has performance engineering teams devoted to the science of optimisation. Before a single system is built using any new family or major revision of AMD64 microprocessor, AMD issues detailed documentation listing each CPU's capabilities and tunable parameters. New CPUs and AMD-built chipsets go out with reference BIOS code that puts the processor in an optimal state before booting the OS. I met the engineers that develop the guidance for system makers, BIOS vendors and the OS development teams at Microsoft, Red Hat, Suse, and Sun. They're no amateurs; I'd trust their advice. But once they do their jobs, the tuning of each system sold with AMD CPUs is out of their hands. The tiller is turned over to software.
The BIOS gets in there first. Machine code in the BIOS walks through the CPU's parameters and initialises them based on some combination of AMD's advice, the system administrator's preferences as expressed through configuration settings, and the whims of the system maker. Manufacturers contract for the development of the BIOS firmware in their servers. They determine what an admin can adjust, as well as the settings of all the things you can neither see nor change.
You'll never find a server shipped from the vendor with overly aggressive settings. Systems may be tuned downward to operate at the widest possible range of temperatures, to accommodate cheaper components, or to throttle performance in order to compensate for inadequate cooling design. Tuning can also undercut system performance in misguided attempts to meet energy efficiency targets, when that objective could be just as well served without sacrificing performance. For example, slowing memory access can cool the system considerably and lower its power draw, but the cap on performance means that tasks take longer to complete, increasing the time that the system spends drawing maximum power.
The OS also presents an interesting issue, especially with Windows. I was surprised to learn that starting with Vista, processor drivers, critical to controlling power states, are being written exclusively by Microsoft. AMD knows a thing or two that Microsoft doesn't about tweaking an AMD64 CPU for speed and efficiency. Microsoft wants to handle this on its own, and tuning within Windows Vista and Server 2008 does not take the unique characteristics and advantages of AMD's architecture into account.
The big problem is that there's no way for IT and end-users to find out what they're missing. It is possible to dump the myriad registers affecting performance, but they're meaningless to mortals and many can't be changed without disrupting operation. Short of writing your own BIOS, there isn't much you can do. Maybe that will change. The secretive relationship between chipmakers and OEMs doesn't always serve customers well. The configuration advice that AMD issues to its OEMs, BIOS vendors, and OS vendors could form a sort of fingerprint. Even without an understanding of the meaning of individual registers and flags, patterns of variance can point to a vendor's agenda for diverging from best practices. If nothing else, IT could ask why AMD's advice wasn't followed. There may be perfectly good reasons, reasons that differentiate one server brand from another and show who's been doing their homework.
No chipmaker would ever single out an OEM for praise or scorn. AMD's no exception. While AMD's testing engineers express frustration that their recommendations are a take-it-or-leave-it affair, and that when their advice is set aside it affects the public's perception of their CPUs, they don't take it out on OEMs either on or off the record. AMD figures that this is the way the system works when you're on the 20 side of a market that's split 80/20.
The system needs to change. AMD is building new classes of high-powered client platforms that are wide open to end-user parametric tweaking. Enthusiasts and gamers do pay attention to AMD's advice with regard to performance, and they're driven to pull the maximum possible performance out of AMD's silicon. This serves AMD well, because when third parties do this and write about it, AMD doesn't have to out OEMs for taking a lazy approach to configuration. Enthusiast-tweaked machines create a best case, and makers of desktops sold into the high end will have to explain why they don't live up to best case numbers. That's not being done for servers, in large part because server enthusiasts willing to do exploratory tweaking of their machines are rare. I only know one such person.
As mainstream server CPUs grow from four to six to eight cores, four socket servers become the norm and deeply multi-threaded applications come to predominate, tuning the CPU, chipset, bus and memory becomes crucial, with a direct impact measured in dollars, hours, and watts. This is tuning that administrators shouldn't be required to do by hand. They should be able to trust that when a system hits their floor, it performs as well as its technology permits. This requires that vendors put some effort behind understanding and leveraging the differences between AMD and Intel architectures — effort that isn't a priority at present. This mystifies me, since AMD does all of the legwork, freely handing vendors BIOS and kernel guidance that started taking shape when the CPU was still in simulation. It takes a lot of work to ignore the chipmaker's advice, and so far, I've seen no evidence that it does customers any good.