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."
It seems that as soon as Intel turned away from its old "our chips have a higher clock speed" marketing tactic, they lost market share. Now people are comparing chips based on speed, heat, cost, etc. instead of the number on the box. With the current battle between AMD and Intel at fever pitch, I expect to see even more innovation that usual from their incredible R&D departments.
Information wants a fueled airplane waiting at the hangar and no one gets hurt.
It's not a monopoly when their chief competitor has over a fifth of the market (and gaining)
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.
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.
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.
AMD scales very well up to 4 sockets, but not so well after that. When you start getting up to 8-way and above, there is a lot more competition. The likes of IBM, Sun and Fujitsu own that market. If you need 32 or more CPUs, then x86 is very likely not to be the way to go.
I am TheRaven on Soylent News
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.
When it comes to server applications, does AMD's technology (HyperTransport etc) make it that much more desirable? Or will/should Conroe gain more market share back to Intel?
First, HyperTransport is an open standard, not an AMD technology, and from what I know, it kicks ass.
AMD has gained recently, especially in the server/HPC market because of a few things. Price, performance, power consumption, backwards compatibility, and 64bit offerings. These are the key variables for server/HPC computing. Power consumption and to some degree 64bit-ness are newer and these variables have increasing weights in today's markets.
Personally, I'm not a fan of the EM64T or other hacks for providing 64bit capabilities over a native 64bit architecture, but then again I've never dealt with these x86 extensions first hand, so I could change my opinion with new information. From what I know the original Intel Core was only 32bit, but the core duo included 64bit abilities.
Perhaps the submitter would like ignore the fact that AMD's stock price has also taken a beating.
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.
But writing software that is portable between AMD and Intel "x86" is easy. Writing stuff that is portable between PPC and x86 is hard. That is why AMD/Intel x86 can be counted in the same market but PPC/x86 can't.
In the same way, writing code portable between Windows and Linux is hard, so Linux isn't in the same market as Windows (unless it is a java app, or web-based).
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.
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.
(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