Slashdot Mirror
AMD Takes 25 Percent of Server Market
An anonymous reader writes "AMD has taken 25 percent of the server market for itself, according to a News.com article. This gives them some 21 percent of the entire x86 market, and is an increase from only 16 percent in the second quarter of 2005." From the article: "AMD has been picking away at Intel's server market share for several years based on the superior performance and power consumption of its Opteron processor. But Intel fired back last month with a new Xeon processor based on its Core microarchitecture that appears to be outperforming current Opteron processors on several tasks. Intel is pinning its hopes of resurrecting its market share--and its stock price--on the new Core generation of processors."
Strong Dual-Core AMD processor sales--particularly Opteron--demonstrates the acceptance of the AMD64 platform by enterprise customers. Likewise, the AMD Turion 64 processor has won more than 60 design awards and been a top seller in the thin mobile PC category. AMD is simply taking advantage of an Intel vulnerability in being late to market with a true high-performance 64-bit product.
Sigs cause cancer.
AMD is not an upstart...
Hi everyone.
6 ,00.asp
I just read a review on Inetl new C2 chips and from the specs, it apparently is faster by almost an order of magnitude than anything AMD has (im not a intel fan boy as everthing i have right now runs AMD)
Anyway, the most interesting thing about these C2 chisp is how much cooler they are at the same time. I've read on article that said they were able to run them fanless.
anyway, heres another articles http://www.extremetech.com/article2/0,1697,198903
I think i might be upgrading to these when they come out in numbers
Sigs are dangerous coy things
Yeah AMD is after all much much younger then Intel... lets see by around one whole year. In other words neither of them are an "upstart" when in comparison to each other today.
Which I believe are the Woodcrests.
Woodcrests - Server.
Conroe - Desktop.
Merom - Portables.
Based on the opinion of most IT analysts, the 4P servers is actually the "sweet spot" of the market. So I expect Opteron to continue it's lead there. The HyperTransport from AMD is superior to the FSB when you start getting into multiprocessor servers. And I expect AMD will extend HT to be up to 8 chips (currently 4) in the next generation chips sometime in 2007.
For more information on AMD, see: wikipedia on AMD
They've turned away from it since the Prescott deep-frier fiasco, it's "just" that they didn't have any chip available and had to get back to the drawing board to build new chips (the Core2) from the Pentium-M and P-III architectures.
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
Well Opterons badly lose against equivalently-priced Woodcrests (from the benches we've seen up until now), but the impressive HyperTransport links and the way they open it (custom 'drop in' chips for HT motherboard) will keep it extremely interresting. Plus the aforementioned HTT links make Opterons architectures much easier to scale up.
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
Perhaps the submitter would like ignore the fact that AMD's stock price has also taken a beating.
Except that there is no Conroe-based chip (Woodcrest or other) for >2 socket systems until next year. Woodcrest is 1-2P (2-4 core) only.
Yeah Cray can't seem to get them to scale at all.
Seriously though, Newisys and IBM have chipsets to do 32 Opterons, but why? That market doen't need it for the trouble it would be. Right now, you can do four way glue-less and eight way with little trouble. The next revision, in Decemeber - March-ish timeframe, K8L adds more interconnects, the ability to split HT connections to 8 bits to double connections, and 4 cores per die. This all adds up to 32 way glue-less for a total of 128 cores. The real reason why you don't see large scale single bus style Opterons, is that the combination of the current HyperTransport (ver. 1) and NUMA make for a very chatty bus, which causes performance issues related to scale. The point of HT is that it is routable and switchable by HT chips on the bus-lines, a la Cray. It's just hardly anybody does it.
They scale fine.
[RIAA] says its concern is artists. That's true, in just the sense that a cattle rancher is concerned about its cattle.
Core = Core Solo and Core Duo (aka Yonah, a laptop chip)
Core 2 = the foundation of Intel's next generation CPU which are as follows...
Merom - laptop chip - T55xx, T56xx and T7xxx
Conroe - desktop chip - E6xxx, X6800, X6900, etc. - (Core 2 Duo, Core 2 Extreme, etc.)
Woodcrest - server chip - Xeon 51xx
TFA only talks about marketshare not sales. AMD may very well be outselling (or close to outselling) Intel, but many old servers out there are still running Pentium chips. Considering the number of servers out there, 25% marketshare is huge - and it indicates that purchasers are being knowledgable and rational.
(BTW, EM64T = shameless clone/re-branding of x86-64, which is an open standard created by AMD. A rare case of Intel not succumbing to Not Invented Here syndrome. From here on, I'll lump them both under the name "AMD64".)
FWIW, I have very little hands-on experience (not being a frequent programmer of x86 assembly), but there are two big features of AMD64 that stand out: more registers (which helps compilers especially), and addressing relative to %rip (the 64-bit Instruction Pointer). The former lets you compute more things on-the-fly without reserving stack space for temporary variables, which can cut down on round trips to L2 or main memory -- thus making AMD64 a bit more like a RISC system, while leaving behind the ivory tower "orthogonal" (read: code-bloating) instruction sets that RISC forces on you. The latter lets your code reference constant things like strings (which are generally compiled into the .text section, right alongside the code that uses them) without [PIC] reserving a register for it, or [non-PIC] hardcoding the address. This simplifies the build process for a LOT for programmers.
Quick tutorial on PIC:
Let's say I have a function, void hello() { printf("Hello, World!\n"); }. If I compile and link this code normally, I get something that looks like push $0x80484b8; call printf, where 0x80484b8 is a hard-coded address located in the .text section (or else a section for data constants that can be found relative to .text). If you're building an executable, that's fine, since the location of .text will be known at link-time.
However, if you want to bundle your code into a shared library, that won't do at all. Each program that loads your library will load it at a different address, so .text could be anywhere in memory. On a modern system, you can add a fixup so that the dynamic linker patches your code on the fly, but now your "shared" library has one copy in memory per instance, even if it's all instances of the same program. That's worse than a static library! The solution is called PIC, Position Independent Code, and is invoked with -fPIC when using GCC. On x86, it usually looks something like this: call .Lfixup; .Lfixup: pop %ebx. Since x86 provides relative jump/call instructions, you can call to .Lfixup without knowing the absolute address, which pushes %eip on the stack as the return address. After the pop, %ebx now contains the absolute address of the .Lfixup label at runtime, and you can safely access your constants relative to that. (All that fuss just because you can't use %eip directly.)
On the downside, you've now eaten a register (on the already register-starved x86 architecture) and you've blown away most branch predictors, forcing a pipeline stall. Not a biggie if you just do it once in main() or similar, but since this might be a library function, you have to do it each time the function is called, in each function that needs it. Ew. It works, but it's not elegant, and it eats performance very badly if you call a PIC function from within an inner loop, so a lot of programmers just tell their tools to compile the entire program twice: once with PIC, and again without. (That's what all those *.lo files are from GNU libtool.)
AMD64 allows compilers (and assembly writers) to unify PIC and non-PIC code into a single, efficient path. Instead of jumping through hoops to copy %rip to %rbx and locate your constants relative to %rbx, you can just address your constants relative to %rip directly. There's no longer any penalty for using PIC, so compilers can just turn it on by default, saving the world from millions of tiny hassles that add up to one big Ick. It's probably the single most real-world useful thing they could have possibly added to the x86 instruction set.
Range Voting: preference intensity matters
Those are minor factors affecting market share, yes, but the real issue is AMD's production capacity. AMD just doesn't have the fabs at present to supply 90% of the market. Large vendors know this, and they also bitterly remember having made large orders with AMD in the past that they weren't able to deliver. And even if AMD was able to ramp up production, vendors' existing contracts with Intel can't be broken overnight.