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. "
I know this is slashdot, but maybe I wanted to RTFA?
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.
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?
Apples compared to Oranges: Our findings on the page after the banner adds!
.. nothing to see here, move along...
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.
/me hugs his ultrasparc system
Couldnt agree more. Oh wait, something's sending an Int. Req. , cant type have; to see what it wants.....
80x86 may be ugly, but it's cheap for the processing power and has an entrenched economy of scale. It sucks. Even Apple switched from PowerPC and is now making glorified Wintel clone boxes (though with a pretty nifty feature set).
-b.
Are you seriously claiming "spoiler" on a tech article? That's a new level of silliness.
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.
I love the thinking in this report, look at total energy consumption for a given render... Brilliant... TCO FTW!
Gamingmuseum.com: Give your 3D accelerator a rest.
Its not just risc vs cisc ... the whole x86 system is based around resource-fumbling bus sybsystems. When you get down to it, the whole motto of x86 really could be "get in line, and wait" .. its 1970s era crap.
The fact that the CPU now runs at 324236GHz and can chew the math nice and fast doesnt alter the fact that the -rest- of the system (A20 gateway stuck on the KB controller and such.. ahem..) deserves to go the way of Wang...
I've always been a fan of systems like MIPS and Ultrasparc: Engineered right the first time... We'll see if cell makes it into a non-wintel-clone-type subsystem
I've heard this repeatedly on Slashdot, and it never makes sense. The idea of RISC is that the responsibility for interpretation and optimization falls on the compiler. Sure, adding an extra interpretation layer on the processor will simplify the internals, but that layer is still necessary. If that interpretation was done at compile time instead of runtime, the situation would be much simpler for the processor. And *that* is RISC.
RISC worked well when speed of memory and CPU's were at parity. The simplified instructions let the CPU be clocked a lot faster, not to mention their shallow pipelines made it less costly when branch prediction failed. The tradeoff was that it usually took more instructions to accomplish a given task.
But as CPU's have spent more and more time waiting for memory, CISC has really come into its own. Think of CISC as a compression algrorithm: An x86 instruction which fits in 16-32 bits might take 4 or 5 instructions on a RISC processor, weighing in at 96-128 bits. It's no surprise why CISC processors have destroyed RISC in the past decade.
one friend who works for oracle, in their datacenter, told me that they are swaping the dell intel xeon server with Sun AMD Opteron servers. the main reason behind this server swap is power efficiency of the new sun servers. So that means big corps already had their eye on AMD cpus :)
You are correct.
It does:
push BP
mov BP,SP
sub SP, 10
and
mov SP,BP
pop BP
internally very quickly as RISC instructions. It's still 5 bus cycles.
No folly is more costly than the folly of intolerant idealism. - Winston Churchill
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.
"I got a 2KW Optitron running GoogOS, you?"
"3KW Sexium on Microsoft Linux."
"Shut up and roll."
It's very useful to have some normalized way of measuring watts/performance, as they try to do in this article. But at least they could have used a more general and useful benchmark, like those offered by www.spec.org.
Please don't get the idea that I'm defending the Intel x86 instruction set. When I first saw it in the early 1980s, I thought it was the most gawdawful mess I'd seen in 25 years in the business (I wrote my first assembler code in 1960). It hasn't improved any with time. I still detest it. Thankfully, I rarely have to use it.
[My candidate for the best microcomputer instruction set from the programmer's POV -- hands down, the MC6809]
But my understanding is that (almost?) all modern CPUs in fact have some different -- often vastly different -- architecture under the hood of their x86 chips and just use the x86 set as a sort of pidgin language that they translate into real instructions that typically run in a multiple register, multiple stack, highly parallel, etc environment of some sort. Do I have that wrong?
Is it time and past time to devise a new pidgin language? Probably. But let's don't let Intel have too much influence on the process. Intel doesn't seem to know the meaning of terms like simple or straightforward. I've never encountered anything they did that wasn't overly complex and often their design decisions seem to me to be utterly baffling.
In any case, it is still necessary, to emulate the x86 because there is all that legacy code out there. That doesn't mean that the hardware itself is constrained to actually implement all the x86 wierdness -- it just has be able to act like it does.
You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey
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
I'd like to see these efficiency curves plotted against 100%, the maximum theoretical efficiency of the transfer function through the semiconductors. Anyone know how to calculate the minimum W:b (watts per bit) necessary for these real-world tasks? Or is that just way too complex a stat to compute without melting the datacenter at which it's computed?
--
make install -not war
I know this is Slashdot, but what's stopping you from R'ingTFA? The suspense lost by the spoiler?
--
make install -not war
You've accepted a fallacy of false dichotomy. While the 90s posed a dilemma of RISC vs. CISC, modern hardware architectures are more akin to VLIW. The ISA may be a stack machine, much to the dismay of compiler writers everywhere, but that is flattened into a superscalar VLIW microcode stream.
-I like my women like I like my tea: green-
It looks to me that the Instruction Set War (CISC vs RISC) is pretty much lost. Nobody cares about the instruction set. Microsoft is not the culprit. CISC processors just got fast, much faster than many RISC processors. These days what makes a CPU fast is what there's inside, not the instruction set.
Actually, don't rule out "something completely different" from Intel now that Apple is a partner. Intel has been trying for more than a decade to break out of the boring beige box business that Microsoft drug them into. Sure, it's been VERY profitable up to this point, but there's a curve in the road and something must be done. I strongly believe that Intel and Apple will come up with a hardware solution that will clearly differentiate the Mac from other Intel-based products. Don't know when this might happen, but I'm buying more stock in both companies ASAP. Don't get me wrong, IBM's Power and Cell architecture are going to take some quantum leaps in the next 18 months too. The next two to five years may be very interesting for the computing world.
[My candidate for the best microcomputer instruction set from the programmer's POV -- hands down, the MC6809]
Amen, brother! While I haven't been coding for quite as long as you (for me, it was 1976 when I started), I've used a hefty number of instruction sets and designed a handful myself. The 6809 was always my favorite. I still have a well-worn copy of the 6800 instruction set manual in my library; so clear, so beautiful. This was back when instruction set design was based purely on merit (what is the best way to compute?) rather than market forces (what is the best way to run MS applications?).
Put my fist through my alarm clock with its ding-dong death inside my ear. - The Blackjacks.
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.
You could compare the size of object code spat out by gcc for different architectures, though of course gcc may not be the most efficient writer of assembly language.
-- Ed Avis ed@membled.com
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.
"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.
How exactly is it VLIW? We're still only issuing one instruction per clock per core. The fact that it breaks down into micro-ops, some of which may be executed in parallel, still doesn't make it VLIW.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
>I know this is slashdot, but maybe I wanted to RTFA?
You must be new here...
With the intel chip set there is only 2 x8 pci-e lanes coming out of the north bridge and sas / sata-2 , pci-x, networking, as well as the pci-e slots on the board have to share them.
So with a lot of network use and disk use you can choke up that bus.
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.
So uh, this memory-mapped IO that I'm using instead of emulated PIO, and these programmable DMA controllers, and the cascading interrupt muliplexer, and this hybercube bus with cache coherency... that all is just a figment of my imagination.
Meanwhile my Sun has OH LOOK, a crossbar, and MY GOD! this newfangled PCI bus. WHAT HATH SCIENCE DONE?
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Here is one test that needs to be done take a duel amd opteron workstation with 2 Quadro cards in sli and also put in a raid 5 sas or sata setup also do some networking at the same time. There are duel and quad amd opteron boards with nForce Professional chip sets. some have 4 pci-e slots x16 x8 x8 x16 with each half coming from a HTT link.
Also take a duel intel workstation and try to do the same thing the best that you can find is x8 x8
Use hacked sli drivers is ok.
I think that the amd system will do better as it has much better io bandwidth.
And so far the conclusion is your server farm should run at 50% utilization average, make it virtual and run it on Xeons at almost 100% and keep the other 50% on iddling Opterons waiting for the peaks?
No, I take it.
Then why do you care?
And we "fixed" this with x86_64. The extended instruction set allows for more orthogonal expression of what you want to do with your ops w/r/t regs and memory (although not all of them are equivalent length, the more common ones are shorter, so what does it matter?)
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
http://techreport.com/reviews/2006q4/xeon-vs-opter on/index.x?pg=7
Very interesting. The benchmark uses a database and is the only one I've seen that seems to test the limits of the CPU cache with a database.. and low and behold, at 8 threads, performance degrades for the 5355 and it's actually slower than the opteron 2218.
Or it could just be that this benchmark isn't coded well - it might use a global lock frequently so as you add more threads there's more contention. In any case someone with more time than me should dig into this benchmark which might show a weakness in the core 2 architecture.
Finally, good benchmarks. Where were these guys a month ago before I ordered those 5320s and when will those 5355's be available for the rest of us.
2 years and no mod points. Join reddit. Because openness is good.
See http://electricrain.com/greg/opteron-powersave.txt .
All AMD K8 (Opteron and Athlon 64) CPUs have the ability to run the clock and an extra slow speed when in HLT (idle) mode saving a bunch more power. Many (most?) BIOSes are not smart enough to enable this. A simple setpci command will turn it on under linux.
find out if its on:
setpci -d 1022:1103 87.b
If that returns 00, its off. To turn on clock-divide-in-hlt to div by 512 mode use:
setpci -d 1022:1103 87.b=61
(see the above URL for links to the AMD documentation on the PMM7 register; other values can work).
Complex instructions reduce the overall code size), reducing the need for code cache and RAM. Especially with 64 bit architectures this makes a big difference. Instead of 8 byte RISC instructions, the average instruction size is probably closer to 3 or 4 bytes (not including immediate values, which of course in 80x86 can be smaller than the machine word size). Obviously RISC chips can be designed with small instruction word sizes, and for instance a pretty good RISC instruction set could live in 32 bit words, but then there are extra alignment issues to deal with. Overall, I think the idea of having a compact instruction set wins out over the simplicity of a full RISC design. Not that there aren't things I'd change with 80x86, for instance it would be nice if the next generation of x86-64 chips would support a more RISCy 64-bit mode of execution for pure 64-bit code, allowing developers (or compilers) to make the tradeoff between code size and RISC speed advantages. x86-64 already includes 8 extra registers, so perhaps having another 16 (or 48) available only from a 64-bit RISC mode could help hasten the transition to a saner instruction set.
How can you subtract a unit of time (seconds) from a unit of power (watt) ?
Assuming multiplication was intended instead of subtraction, why use Watt.seconds instead of Joule ? Still, kudos for using SI units and not something like boe.
Flourescent (adj): smelling like ground wheat.
CISC has dominated RISC so much that 4 out of the top 5 computers in the top500.org list are RISC? (the one that isn't RISC is a Opteron Dual Core cluster) http://www.top500.org/list/2006/11/100 I had no idea that CISC was beating RISC so badly. As a side note, the 4 RISC systems in the top 5 were made by IBM. -Aaron
The post made with 100% recycled electrons
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
Personally, I don't like x86 either. Luckily, I've never had to write x86 assembly even though I've worked on millions of lines of source (C, C++, etc.) So, aesthetics of the ISA are (no matter what I think) irrelevant because most of us will never see the ISA. I grew up learning the 6502, 6800, 68000, SPARC, and other ISAs. Those were nice to use and made x86 look like a Gorgon. I haven't written any assembly at all in over 20 years. My lowest level language has been C so that's my "ISA".
Second, the CISC/RISC debate died a long time ago. It's mostly RISC basically fell away to mean Load/Store architecture while CISC was Memory+Op.
Third, something much more interesting to think about in the world where everyone is so concerned about memory bandwidth is that x86 instructions are very much like compressed binaries. One read can get an instruction that translates into a number of instructions that are more Load/Store-like (RISC-like). On a "RISC" type machine, that equivalent instruction stream could have taken a number of reads (read: bus cycles) and multiple I-cache lines to hold (read: more memory). So, not only do you save memory size, you can save many clockcycles by reading a "compressed instruction" and translating it into the several equivalent load/store (RISC) instructions.
At least... #1 helps me forget about the ugliness that is the x86 ISA and #3 actually makes me like it a little.
Do you have any reference for your statement of only one instruction (as defined in the ISA) per clock per core? The microops are what's actually scheduled, and if we don't have any dependencies they will certainly be run in parallel. The instruction decoder on Intel core is rather wide, as well.
Up here in The Great White North, there is a second important feature (mostly for desktop and deskside systems) -- and that's efficiency as a space heater. When these boxes are running at full bore, how many BTUs do they generate, and how many BTUs/watt do they generate. How many Zeons or K7s would it take to heat the average house?
More importantly, how does that compare to a dedicated space-heater?
Sometimes boldness is in fashion. Sometimes only the brave will be bold.
Cyrix man just flat out is uh.ja98u&^Y)#CN(&n q dang over heating problem againa
The only ones affected are the tape monkeys, and their jobs were replaced by robotics years ago.
Twenty years ago satellite ground stations were dropped off up north with nothing more than a big tank of diesel, a power generator, and a fault-resilient or fault-tolerant server, left alone for months at a time.
With modern high speed networks and VPN access, it's often hard to tell the difference between being at work and remote access, other than the environment. Don't forget how much sysadmin work has been offshored to India and other regions, or how many global operations have geographically distributed locations, with staff at each covering the entire globe's sysadmin functions from different time zones.
Your theoretical idea has been possible for over 10 years.
I do not fail; I succeed at finding out what does not work.
The old Western Electric (A.T. & T.) CPUs (WE31000/WE32000, as in the 3B-series computers) Huffman-coded the instruction set. More-frequently used opcodes were smaller than less-frequently used opcodes, so "instructions/memory word" was denser than typical RISC. Lots of registers, very powerful instructions. The processors did not fetch "instructions", they read cache lines from memory at the next uncached address of instructions.
That's funny because in the real world where things like cache hit ratio matter it's been shown that a CISC front end with a rather inexpensive decode stage and a RISC multicore execution stage is the way to go. In that way modern AMD/Intel x86 CPU's are closer to the PPC970 then the PPC970 is to a classical RISC chip. Both CISC and RISC won, the two were married and each is used where most appropriate =)
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
Do you have evidence to back that up?
I don't have anything to back up the grandparent post, but RISC does make the code bloated.
x86 (in 32-bit protected mode, of course) uses a 5-byte instruction to load a 32-bit immediate value into one of the general-purpose registers. Pure-RISC devices like ARM and MIPS need 8 bytes to do this: a 32-bit instruction to load the upper 16 bits and a second 32-bit instruction to load the lower 16 bits. (RISC instruction sets are designed to make all instructions the same length.)
You can see the increased size of the object code if you use GCC to cross-compile the same piece of code for x86 and for ARM [*]. This bloat makes the cache memory ineffective. It's why RISC lost the war to CISC.
[*] Yes, I know about Thumb. It helps.
I guess you didn't get the memo. Turns out RISC wasn't the good idea everyone thought it would be in the 1990's.
Indeed. Even Linus thinks the x86 is an ugly duckling.
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.
Unless your chip is very recent, the timestamp counter speeds will vary.
Unless your Linux kernel is very recent, this condition will not be detected automatically. Linux will assume that the discrepency means you are losing clock ticks.
You can try kernel parameters like clocksource=pmtmr to fix it. Good luck, you may need it...
The BIOS vendors disable this power-saving feature because there are Windows games that, like Linux, assume the timestamp counters don't vary in speed.
How did you come to the conclusion that AMD has better chipsets? I can get an nforce/crossfire/via motherboard for either AMD or Intel with pretty much identical specs. Intel has the advantage of making their own chipset, so Intel is the one that has the chipset advantage IMO.
REP MOVSD
REP STOSD
or yeah and a whole group of divide instructions, do that shit in a single cycle on an ARM RISC chip why don't you.
That said the Acorn RISC Machine is certainly the best of the lot.
It is the microcode architecture which is VLIW. In no wise is the x86_64 ISA a VLIW ISA. But the chips damn well are.
-I like my women like I like my tea: green-