Slashdot Mirror
Xeons, Opterons Compared in Power Efficiency
Bender writes "The Tech Report has put Intel's 'Woodcrest' and quad-core 'Clovertown' Xeons up against AMD's Socket F Opterons in a range of applications, including widely multithreaded tests from academic fields like computational fluid dynamics and proteomics. They've also attempted to quantify power efficiency in terms of energy use over over time and energy use per task, with some surprising results." From the article: "On the power efficiency front, we found both Xeons and Opterons to be very good in specific ways. The Opteron 2218 is excellent overall in power efficiency, and I can see why AMD issued its challenge. Yes, we were testing the top speed grade of the Xeon 5100 and 5300 series against the Opteron 2218, but the Opteron ended up drawing much less power at idle than the Xeons ... We've learned that multithreaded execution is another recipe for power-efficient performance, and on that front, the Xeons excel. The eight-core Xeon 5355 system managed to render our multithreaded POV-Ray test scene using the least total energy, even though its peak power consumption was rather high, because it finished the job in about half the time that the four-way systems did. Similarly, the Xeon 5160 used the least energy in completing our multithreaded MyriMatch search, in part because it completed the task so quickly. "
the Opteron ended up drawing much less power at idle than the Xeons
...
the Xeon 5160 used the least energy in completing our multithreaded MyriMatch search, in part because it completed the task so quickly.
So what does this mean for people shopping for servers?
If your servers constantly tick along at nearly 100% CPU use, you might do better going with the Xeon system. If your machines basically sit idle most of the time with an occasional spike for a few seconds when it actually does something, the AMD would save you more on electricity.
Of course, this raises a third possibility - Would running a number of virtual servers on one large Xeon machine waste more energy than it saves, or give a net gain?
Presumably, the article tests power consumption because businesses are concerned with how much running each of these systems will cost them. If the Xeons managed to win in power consumption because they completed the task in half the time, that has other cost-saving benefits even beyond power consumption. They can use fewer systems to complete tasks within the deadline, complete tasks ahead of schedule (making their business slightly more agile), and/or spend less money on animators waiting for their animations to render.
Aren't newer x86 processors essentially CISC that convert the instructions down to RISC? And RISC processors, like G4/G5, that use instruction sets such as Altivec are actually using some aspects of CISC?
That was my understanding, after reading articles like this one on Ars Technica. If true, it would make fighting over CISC vs. RISC not make a lot of sense.
It's not going anywhere. Intel actually wanted to replace it though it's arguable if their replacement was better or worse but AMD won out the 64-bit round with x86-64. That's what Linux uses, that's what Windows uses, it's a done deal.
Now personally to me you sound like someone who's spent a little too much time in a computer science architecture class soaking up theories about ISAs and too little time actually looking at how chips are made these days and what works. When you get right down to it, x86 works just fine. The chips built on it are very fast, the compilers are able to generate efficient code for it, it plain works in the real world. You may not like it, but it does work well in the real world.
Will something like the Cell kill it? Maybe, but forgive me if I'm more than a little skeptical. There's been things that are going to kill x86 for a long time and none of it has panned out. You can try and make your ISA as brilliant as you like, what it really seems to get down to is good chip design for the money, and Intel and AMD are hard to beat at that.
What I don't get is why are people constantly comparing Intel's quad-core with AMD's revision F hardware? Is this a marketing ploy from Intel to try and make it seem like AMD isn't in the game anymore? Revision F hardware from AMD means that the hardware is *capapble* of taking the future quad core chips, but AMD has not released them yet. In all fairness, what has Intel done for the public without AMD (or Sun for that matter) coming out with their own multi-core competitive product that saved us so much power? Let's be real here - if AMD and Sun didn't come out with multi-core, would we really be where we are today, or would we be cooking our pizzas over the already-overclocked and overheated intel chips that they were trying to squeeze so much out of? Why did it take competitive vendors to make Intel really re-think their methodology? Because they wanted to make more $$ off an old technology. I am in the least bit impressed with Intel. Of course they released a quad-core to market faster than AMD - they've been doing it for years. But again, all they did was take an idea which was not their own and go to market faster. What they don't get is AMD is working up another idea that will blow away the quad-cores. But of course, once Intel sees what they're doing and figures it out, they'll just be faster to market again... Let's give it some time and give AMD and Sun the credit they deserve for changing the future of the processor market today.
You're forgetting the basic formula from Hennessy and Patterson:
Yes, CISC has better work per instruction, except for one glaring issue I'll get to in a moment, but - for various reasons explained throughout H&P - it loses on the other two and thus overall. That's why nobody's making new processors that are CISC internally any more; they just couldn't hit the issue widths and clock speeds are achievable with a RISC core (even if that core has a CISC ISA bolted on the front). What's missing here is that not all work is useful work. As anyone who has accidentally coded an infinite loop knows, executing lots of instructions is not necessarily a good thing. The glaring issue I mentioned earlier is that a lot of the instructions executed on a register-poor architecture like x86 are not doing useful work. Register thrashing means i-cache bandwidth is wasted fetching instructions which are then used to waste d-cache bandwidth, which more than outweighs any advantage from variable-length instructions.
So, you say, wouldn't variable-length instructions on a register-rich processor be the best of both worlds? Not so fast. A regular instruction set makes superscalar execution easier because it means that multiple instructions can be fetched literally at the same time without having to examine the first one to figure out where the second one begins and so on. It also makes deeper pipelines easier because it allows many internal activities (e.g. register allocation, hazard detection) to start after a simple pre-decode stage, in parallel with the remainder of decode. Either way, regular instruction sets allow for more parallelism - and parallelism in some form is the generally the key to CPU performance. If you're willing to give up performance by eschewing most modern processor-design techniques, which might be the case for a deeply embedded system with extreme size and/or power requirements, then variable-width instructions might still be a reasonable choice. In that case you might as well use an older architecture; there are plenty to choose from. For new processor designs, though, variable-width instructions are almost invariably a way to lose.
Slashdot - News for Herds. Stuff that Splatters.