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."
More importantly, it's not a monopoly when another company (AMD, Intel, etc) can build a compatible processor that can do essentially the same tasks. Everyone agrees that AMD and Intel chips can both run workstations and desktops.
This is why I see Windows as a monopoly -- in order to be certain of being able to run all of the Windows applications out there, you need to have Windows, not Wine or MacOS etc.
Competition is a good thing. I've traditionally run AMD chips in my machines, since I've had good results and gotten good value, but I wish Intel well, too -- if only to keep AMD honest.
Paleotechnologist and connoisseur of pretty shiny things.
Posting anonymously because I have a feeling this would get me modded down... So the 'perfect storm' article for Apple cites a 4% gain of the total LAPTOP market share as a reason for apple's soon to come victory, but a 5% increase in the ENTIRE x86 market by AMD is heralded with doubt, etc. etc. and with thoughts that Intel is going to come back? Slightly one sided?
I do not think that means what you seem to think it means.
Expect Intel to take share back in the 2P and below market (largest market) while AMD will hold onto their lead in the 4P market until at least early next year, and possibly a while longer due to the technical superiority of their HT-based interconnect. Conroe and Woodcrest are undeniably the better uarch's, but when you start scaling to more CPUs the interconnect becomes more and more important.
It's impressive, to say the least, than Intel has managed to make Conroe perform so well without an integrated memory controller. A lot of uninformed fanboys will claim they "cheated" by using so much cache, but there's no cheating in the microprocessor field and even the 2M Allendale units with less cache have stellar performance. I can't wait for them to come out with their next gen chips with CSI and an integrated memory controller, those will be stunning perforers in all sectors.
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
Though Intel currently has the single chip speed title, where they lag is in interconnectivity between processors. I believe that if AMD continues down their current path, they will dominiate the server market.
There is no doubt that AMD's solution for connecting multiple cores and processors is superior to Intel's. And when we start to see coprocessors being popped into one CPU socket providing super-accelerated services such as encryption... the shift to AMD will accelerate. I imagine a secure webserver that is able to handle twice the number of concurrent connections is quadrupled because all of the encryption is handled in hardware by a $600 coprocessor. Sure Intel's system will be faster for general purpose activites, but when your talking paying $600 for a coprocessor, or several thousand for additional servers... well you get the idea.
I think that though Intel currently has a leg up, it's only a matter of time before AMD knocks their other leg out from under them.
Now I'm no fanboy, I'm anxiously waiting for the Core 2 Duo to become widely available before I build my next workstation. But I still believe that AMD is eventually going to become the king of server processors, if not the desktop.
Sometimes the best solution is to stop wasting time looking for an easy solution.
Until Intel competes on price, AMD will continue to take market share. Servers are considered business machines. Businesses are looking at "Bang for the buck" and Intel keeps their prices too high to win this one. Performance does not have to be identical, just similar (these are servers, not gamer machines), then any business will choose the less expensive one every time. There have not been any real reliability issues between the two for years so it just comes down to price/performance. When I see a 20% or more price difference for similar products I wonder if ego gets in the way of common sense.
Professional Politicians are not the solution, they ARE the problem.
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.
One, they are not an order of magnitude faster. I have seen some benchmarks on the Core 2 Duo CPUs versus Athlon X2 CPUs, and in a clock for clock comparison they Core 2 Duo were up to 20% faster in some integer operations. Floating point performance was almost equal, as was memory access. 20% is not an order of magnitude.
Two, we are talking about server CPUs, not desktop CPUs. That means that we need to be comparing Xeon CPUs with Opteron CPUs, not Core 2 and Athlon.
Three, the new Core 2 and Xeon CPUs may be faster one on one, clock for clock, than an Athlon X2 or Opteron, but they still have the same old problem that has haunted Intel CPUs since the birth of the Athlon 64: the FSB. Putting 4+ MB of cache onto the Xeon and Core 2 CPUs helps alleviate some of the FSB bottlenecks (for memory access), but they still can't touch the Hypertransport interconnect for performance. And where this really comes into play is in scalability. If you put two or four Intel CPUs into the same server, they share the FSB. If you put two or four Opteron CPUs into the same server, they each have a dedicated connection to the memory, etc. Opteron-based servers scale much much better than Xeon-based servers. This is especially important now that people are pushing virtualization more and more. Instead of buying 10 small servers to handle 10 different tasks, they're buying a single 4-way server and running 10 virtual servers on it to save money and make better use of the CPU and memory resources that they have.
Could they please give it back? I'm trying to browse the Internet here.
AMD has taken 25 percent of the server market for itself,
During the time period that this data refers to, AMD's products had a clear lead in price/performance. But they only got a quarter of the market, instead of >90%, which they would have got if purchasers had been knowledgeable and rational.
I was at the National Youth Leadership Forum for Technology about 3 years ago, a 2 week seminar in San Jose. 2000 other kids just as geeky as me, what a blast! Anyways, there were a lot of speakers who came there, one of whom was the CEO of Intel. After he'd given his presentation, he opened up to questions. One kid asked something to extent of, "What are you going to do now that AMD has a 64-bit processor?" The crowd 'ooo'ed at his guts for asking the question we were all dying to ask. The CEO laughed. "I wouldn't want to switch places with them," he answered complacently. I wonder what he'd say now, three years later.
(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