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. "
AMD needs to deliver some real quad core chips (or 8 core chips) that will beat Intel's performance. If they don't soon, AMD will quickly get kicked back to the 2nd rate Intel cloner that everyone knew them prior to their groundbreaking AMD 64s and dual core chips briefly took the performance lead from Intel. I'm keeping my fingers crossed that AMD will deliver, I've always liked (and bought) their chips as long as the performance is similar to Intel.
Crack - Free with every butt and set of boobs
AMD needs to do what they have been doing - thinking independently and coming up with original solutions.
Apples compared to Oranges: Our findings on the page after the banner adds!
.. nothing to see here, move along...
Although some people will pipe in with their number crunching sever stories, are there any normal usage servers that really come in at 100% CPU usage? For the 20 odd servers I run few ever run at that rate for more than 30 minutes a day or so - and usually doing backups for that matter. Other system components often keep you from reaching that target, and most 24-7 servers I've seen do most of their work during a certain period then spend the rest of their time twiddling their thumbs.
It has always been my understanding that best practices dictate a server running at a constant 100% CPU utilization is underpowered and needs upgraded. Normal, every day, steady CPU utilization should hover no higher than around 50% (closer to 75%, if you like living on the edge) leaving enough CPU to handle peak loads. Very few functions require a system that maintains a constant CPU utilization and never peaks over it.
What I'm really referring to here is the extreme non-orthogonality of the ISA and the register set. I'm certainly not a purist when it comes to what individual instructions are allowed to do, but there's a lot to be said for having instructions all be the same width.
No folly is more costly than the folly of intolerant idealism. - Winston Churchill
Any server running at that rate for more than a few short peaks a day is under capacity. Ideally, you'd like to keep them at 100% but you don't control scheduling of server demand. It's too ad-hoc. You trend then build enough excess capacity to handle projected peak loads. Of course, this depends on the level of service you want to deliver. Most server "customers" expect the server to be always as responsive as it can be, regardless of load. (expectation of IT is always 100% all the time). So server farms or clusters are built to handle the peak, which typically happens only for short durations. Being able to use machines at full capacity and still maintain enough service overhead would require excess machines that can be brought up quickly.
What if you had a mixed processors with clustering software savy enough to push jobs onto idling machines. You keep the Xeons humming along at nearly 100% and you push peak loads onto a bunch of idling Opterons? Could Xen be made to do that? Have the cluster optimize for best power efficiency at whatever load. On the scale of an enterprise, the cost savings in power over time would be significant.
I know of and have worked with too many organizations that figure it's just a matter of slapping all the computers in an air-conditioned room. Every watt of waste heat adds to the A/C bill.
Old fashioned water-cooled mainframes and big iron (for it's time) often recirculated the wasted heat into the heating systems of the surrounding buildings. We've known all along how to be more energy efficient, if companies and management would only place the emphasis on the environment in their budgets.
I do not fail; I succeed at finding out what does not work.
"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."
More importantly, I think, is that power consumption translates to heat output. If you have mostly idle servers with occasional spikes, you can either cool them for less or put more in the same space depending on what you need. And don't forget that you actually save money twice with the AMD since you have to pay to power and cool the Xeons.
Virtualization, if done correctly, should save you more money on hardware than anything else. You load up a Xeon machine with 6 virtual servers and keep it humming at 70% load. Then you're probably putting out less heat than 5 lightly loaded AMD processors. You've saved the money on the extra hardware, and gained a lot of good things about machine portability in the future.
Well... If you have a couple servers that idle most of the time, I suggest that, instead of AMD, you buy VMWare.
Or go Xen, OpenVz or whatever does the trick.
But, most important, get rid of the idling boxes.
http://www.dieblinkenlights.com
This is foolish. Variable-width instructions provide higher instruction throughput by having lower memory bandwidth requirements and consuming less cache space. You want to code your instructions so that the most-frequently used instructions are as small as possible. This has been an active area of research for tailoring ISAs to workloads, but even an ad-hoc scheme that improves those two areas in the general case is better than none at all.
This coding is more complicated than fixed-width instructions, but this complexity is less expensive than cache in power, latency, and die space. This isn't to say that x86 ISA is optimal, but it isn't bad-enough to warrant the incessant whining that people bring up every time they discuss ISAs.
Intel is not going to run custom processors for a single company that sells less computers in a year than Dell sells in a quarter. Apple does not want to pay the higher marginal costs that would be associated with such a proprietary run of processors nor the cost of moving their software and ISVs to yet another architecture. When Intel tries to "move outside" of the "boring beige box" (immediate tell-tale that your brain is made of cottage cheese, btw) it means convincing set-top and tablet manufacturers to include their desktop processors in their devices. It doesn't mean producing lots of custom chips for lower margins.
It's no surprise why CISC processors have destroyed RISC in the past decade.
Sorry but CISC, specifically x86 and children, has won simply by being the architecture for which most software was written. The dominance of CISC is similar to (but not the same, trying to stave off an off-topic rant) story as the dominance of Windows -- backward compatability is King.
The RISC makers knew this too. Back when RISC was the hot new thing in the early 90s, they were touting that RISC would be so much faster than CISC that you could emulate/translate x86 code and run it faster than a native x86 machine. If this had come to pass, then the reason to have, and thus the dominance of, x86 would have ended.
But it never did come to pass. CISC machines, starting with the Pentium Pro, started to translate CISC instructions into RISC micro-instructions internally, and then used all the benefits that RISC machines got with the main penalty being the complicated decoders on the front-end. Intel could push the performance of their chips, in large part by leveraging the enourmous profits of the lucrative desktop PC business, and thus kept rough parity with RISC machines, often being faster. Since the fundamental performance problem with CISC had been solved, and it still ran all the software, CISC won and RISC lost in the mainstream processor market.
Now of course there are performance pros and cons to both. While potentially reduced code size is the main advantage of CISC, I don't think it adds up to much. Especially since things like SSE2 instructions have gotten large anyway. The main advantage of RISC is the simpler decoders, and more registers. x86-64 gives more registers, plus with a fast l1 cache stack accesses aren't expensive, and the x86 makers learned a long time ago how to make good super-scalar x86 decoders. In the end the pluses and minuses don't add up to much, and it's more about the specific architectures of each chip. In this sense x86 has done a fine job of keeping performance high.
It's unfortunate from an aesthetic point of view, because x86 is an ugly beast, but in the end practicality won, and generally there's no practical reason to care any more.
The enemies of Democracy are
Computers are almost 100% efficient as space heaters. Almost every watt consumed gets converted to heat.
The energy in the light radiated from the monitor or from the LEDs in the computer case is very small compared to the energy consumed by the computer. Computers do no useful physical work. The result is that almost all energy consumed by a computer is converted to heat.