Intel Launches Power-Efficient Penryn Processors

Bergkamp10 writes "Over the weekend Intel launched its long-awaited new 'Penryn' line of power-efficient microprocessors, designed to deliver better graphics and application performance as well as virtualization capabilities. The processors are the first to use high-k metal-gate transistors, which makes them faster and less leaky compared with earlier processors that have silicon gates. The processor is lead free and by next year Intel is planning to produce chips that are halogen free, making them more environmentally friendly. Penryn processors jump to higher clock rates and feature cache and design improvements that boost the processors' performance compared with earlier 65-nm processors, which should attract the interest of business workstation users and gamers looking for improved system and media performance."

Comments

revolutionary? no, but still noteworthy

[Anonymous Coward]

While Penryn is a small increase in performance, it is not a big change in the architecture. Instead of upgrading to Penryn, customers can expect Nehalem, the next major revision in the Intel architecture, was responsible for the release in 2008.

At the Intel Developer Forum in San Francisco in September Intel showed, and said it would be a better yield per watt and better system performance through its Quick Path Interconnect system architecture. Nehalem chips will also provide a memory controller integrated and improved communication between system components.

Re:revolutionary? no, but still noteworthy

[Azuma Hazuki]

I am a dedicated AMD fangirl...every computer I've ever built had an AMD chip in it. But Intel really hit it on the head with the Core 2 arch and I see no sign of them slackening. I am actually looking forward to Nehalem and its shrink (which is probably the next time I'll have the money to spend on anything not college or food/supply-related).

If this is how it ends for AMD, this is how it goes. I'll be sad, and may buy AMD anyway for some other reason (even if it's just stubborn fangirlism) but I respect Intel's design team. Their ethics, no, but their design is top notch this time around.

Re:revolutionary? no, but still noteworthy

[AvitarX]

One reason to buy AMD is that if they go out of business Intel may stop innovating.

Even if you are getting a worse deal in the short run, an upgrade cycle or two in the future may be much worse (comparatively) if everyone goes Intel.

Re:revolutionary? no, but still noteworthy

[Pojut]

Another good reason is that it is far cheaper (at least last time I checked prices) to go with AMD...especially if you aren't doing any gaming or audio/video work. While Core 2 blasts AMD out of the water, the price difference makes AMD a very smart buy for every-day use. For gaming, AMD's offerings still work great, and the money you save on the processor can instead be used towards a more powerful video card.

Re:revolutionary? no, but still noteworthy

[dreamchaser]

You should probably check the prices again with an eye towards price/performance ratios. AMD hasn't been cheaper for a long time. You can save a few bucks by settling for lower performance, but not enough to upgrade that video card or any other significant components.

Re:revolutionary? no, but still noteworthy

[necro81]

The biggest thing about Penryn is the move to 45-nm fabrication, and the technological advances that were required to pull it off. IEEE Spectrum has a nice, in-depth (but accessible) article on those advances. High-k dielectrics and new metal gate configurations will be how advanced ICs are produced from now on. It is as large a shift for the fabs as a new chip architecture is for designers.

Re:revolutionary? no, but still noteworthy

[ircmaxell]

Ummmm.... Check this out... http://www23.tomshardware.com/cpu_2007.html

This chart shows that in terms of Price/Performance for the average user, Intel has only two CPU's that can compete with AMD's leading X2 (non-FX) processor (the 6000+, which is the highest AMD they have benchmarked). The first is the E2160, and the second is the P4E 613.

The field is LARGELY domainated (at the best scores that is) by AMD... Intel has 5 in the top 20, 1 in the top 10, and 0 in the top 5. AMD, conversely, has 2 x2's in the top 5...

Halogen free

[jbeaupre]

I'm sure they mean eliminating halogenated organic compound or something similar Otherwise I think eliminating halogens from chips themselves is just a drop in the ocean. A deep, halogen salt enriched ocean.

Can somebody explain

[sayfawa]

Why is there so much emphasis on size (as in 45nm) for these things? Does making it smaller make it inherently faster or more efficient? Why? I've looked around (well, I looked at wikipedia anyway) and it's still not clear what advantage the smaller size has.

Re:Can somebody explain

[Chabil Ha']

Think of it in these terms. Electricity is being used to transmit 1 and 0s inside a circuit. We can only do so much to make the conductivity less resistant, so we need to shorten the distance between gates. The less distance an electrical signal has to travel, you can increase the number of operations that are performed in the same amount of time.

Re:Can somebody explain

[compumike]

The energy required to switch a capacitor from zero to Vdd volts is 1/2*C*Vdd^2.

Smaller logic sizes can operate faster because the physical gate area of the transistor is that much smaller, so there's less capacitance loading down the piece of logic before it (proportional to the square of the scaling, of course). However, it also tends to be the case that the operating voltages scale down too (because they adjust the semiconductor doping and the gate oxide thickness to match), so you get an even better effect on energy required. Thus, scaling helps both with speed and operating power.

The problem they're running into now is that at these smaller sizes, the off-state leakage currents are getting to be of the same magnitude as the actual switching (operating logic) currents! This happens because of the reduced threshold voltage when they scale down, so the transistor isn't as "off" as it used to be.

That's why Intel has to work extra hard to get the power consumption down as the sizes scale down.

--
NerdKits: electronics kits for the digital generation.

Re:Can somebody explain

[Rhys]

Smaller size means signals can propagate around the chip faster. It also means you need less signal-fixing/synchronization hardware, since it is simpler to get a signal synced up at a given clock rate. Smaller size generally means less power dissipated. Smaller feature sizes means the CPU is physically smaller (generally), so more CPUs fit on a silicon wafer. For each wafer they produce (a high but relatively fixed cost vs the number of CPUs on the wafer) they get more CPUs out (= cheaper). If a CPU is bad, that is a smaller percent of the wafer that was "wasted" on that CPU.

Re:Can somebody explain

[enc0der]

Smaller size means faster but at the expense of more power. As a chip designer I can tell you that the smaller you go, the more leakage you have to deal with in the gates, and it goes up FAST. Now, with the new Intel chips, they are employing some new techniques to limit the leakiness of the gates, these techniques are not standard across the industry so it will be interesting to see how they hold up. I do not understand what you mean by signal-fixing/synchronization hardware. Design specific signal synchronization doesn't change over the different gate sizes. What changes is the techniques that are used as people find better ways to do these things. However, these are not technology specific and tend to find their way back into older technologies to improve performance their as well. In addition, cost is NOT always cheaper because die yield is generally MUCH LESS at newer technologies. For those on the bleeding edge. In addition, development costs go up because design specific limitations, process variance, and physical limitations cause designs to be MUCH HARDER to physically implement than at larger sizes. Things like electromigration, leakage power, ESD, OPC, DRC, and foundry design rules are MUCH worse. What is true is that these people want faster chips, and you can get that, as I said. Although the speed differences are not that amazing. Personally, I don't think the cost justifies the improvement in what I have worked on. Especially on power. Now, going out a few years from now, as they solve these problems at these specific gate geometries, THEN we will start to see the benefits of the size overall.

Re:Still sticking

[Waffle Iron]

It should've been replaced a long time ago with a pure RISC instruction set

It was, when the Pentium Pro was introduced circa 1997. The instruction set the programmer "sees" is not the instruction set that the chip actually runs.

x86 already has elements of RISC & PowerPC is

[Blahbooboo3]

I believe that x86 already has many of the benefits of RISC chips incorporated into them. Way back in 1995 http://en.wikipedia.org/wiki/X86#Chronology.Intel added to the Pentium Pro a RISC core. From the Wiki article, "During execution, current x86 processors employ a few extra decoding steps to split most instructions into smaller pieces, micro-ops, which are readily executed by a micro-architecture that could be (simplistically) described as a RISC-machine without the usual load/store limitations."

As for PowerPC Macs, I doubt it. The switch to Intel is what made most new Mac users switch because there was no longer a risk of not being able to run the one Windoze program they might need. If Mac ever went to a non-mainstream CPU again it would be a big big mistake.

Re:Still sticking

[jonesy16]

Actually, one of the reasons that Apple jumped off of the PowerPC platform was BECAUSE of their power inefficiency. The G5 processors were incredibly power hungry, enough so that they could never get one cool enough to run in a laptop and actually offered the Mac Pro line with liquid cooling. Compare that to the new quad-core and eight-core mac pro's and dual core laptops that run very effectively with very minimal air cooling.

RISC vs. CISC

[vlad_petric]

That's a debate that happened more than 20 years ago, at a time when all processors were in-order and could barely fit their L1 on chip, and there were a lot of platforms.

These days:

• The transistors budgets are so high that the space taken by instruction decoders aren't an issue anymore (L1, L2 and sometimes even an L3 is on chip).
• Execution is out-of-order, and the pipeline stalls are greatly reduced. The out-of-order execution engine runs a RISC-like instruction set to begin with (micro-ops or r-ops).
• There is one dominant platform (Wintel) and software costs dominate (compatibility is essential).

One of the real problems with x86-32 was the low number of registers, which resulted in many stack spills. x86-64 added 8 more general purpose registers, and the situation is much better (that's why most people see a 10-20% speedup when migrating to x86-64 - more registers). Sure, it'd be better if we had 32 registers ... but again, with 16 registers life is decent.

Re:RISC vs. CISC

[TheRaven64]

The transistors budgets are so high that the space taken by instruction decoders aren't an issue anymore (L1, L2 and sometimes even an L3 is on chip). Transistor space, no. Debugging time? Hell yes. Whenever I talk to people who design x86 chips their main complaint is that the complex side effects that an x86 chip must implement (or people complain that their legacy code breaks) make debugging a nightmare.

Execution is out-of-order, and the pipeline stalls are greatly reduced. The out-of-order execution engine runs a RISC-like instruction set to begin with (micro-ops or r-ops). Most non-x86 architectures are moving back to in-order execution. Compilers are good enough that they put instructions far enough away to avoid dependencies (something much easier to do when you have lots of registers) and the die space savings from using an in-order core allows them to put more cores on each chip.

There is one dominant platform (Wintel) and software costs dominate (compatibility is essential). Emulation has come a long way in the last few years. With dynamic recompilation you can get code running very fast (see Rosetta, the emulator Apple licensed from a startup in Manchester). More importantly, a lot of CPU-limited software is now open source and can be recompiled for a new architecture.

x86-64 added 8 more general purpose registers, and the situation is much better (that's why most people see a 10-20% speedup when migrating to x86-64 - more registers) Unfortunately, you can only use 16 GPRs (and, finally, they are more or less real GPRs) when you are in 64-bit mode. That means every pointer has to be 64-bit, which causes a performance hit. Most 64-bit workstation spend a lot of their time in 32-bit mode, because the lower memory (capacity and bandwidth) usage and cache churn give a performance boost. They only run programs that need more than 4GB of address space in 64-bit mode. Embedded chips like ARM often do the same thing with 32/16-bit modes. If x86-64 let you have the extra registers with the smaller pointers you would probably see another performance gain.

Re:RISC vs. CISC

[vlad_petric]

High-performance computing isn't moving away from out-of-order execution any time soon. Itanic was a failure. The current generation of consoles are in-order, indeed, but keep in mind that they serve a workload niche (rather large niche in terms of deployment, sure, but still a workload niche).

The argument that the compiler can do a reasonable job at scheduling instructions ... well, is simply false. Reason #1: The problem is that most applications have rather small basic blocks (spec 2000 integer, for instance, has basic blocks in the 6-10 instruction range). You can do slightly better with hyperblocks, but for that you need rather heavy profiling to figure out which paths are frequently taken. Reason #2: compiler operates on static instructions, the dynamic scheduler - on the dynamic stream. The compiler can't differentiate between instances of the instructions that hit in the cache (with a latency of 3-4 cycles) and those that miss all the way to memory (200+ cycles). The dynamic scheduler can. Why do you think that Itanium has such large caches? Because it doesn't have out-of-order execution, it is slowed down by cache misses to a much larger extent than the out-of-order processors.

I agree that there are always ways to statically improve the code to behave better on in-order machines (hoist loads and make them speculative, add prefetches, etc), but for the vast majority of applications none are as robust as out-of-order execution.

Re:Still sticking

[pla]

It's sad that the industry is still sticking to the x86 instruction set.

Why? Once upon a time, the x86 ISA had too few registers. Today, that problem has vanished (simply by throwing more GP registers at the problem) - And even then, so few people actually see the problem (and I say that as one of the increasingly rare guys who still codes in ASM on occasion) as to make it a non-issue, more a matter of trivia than actual import.



The Power/PowerPC architecture was good

I know I risk a holy-war here, but: No, not really. PPC didn't suck, and held its own for its era. But it didn't scale well, it always cost significantly more for a given level of performance, and even its biggest advantage, "Vector" processing (aka SIMD), vanished with the introduction of the original MMX into the x86 line. After that point, only clock speed and number of execution units mattered (and of course price, never forget price), and the PPC simply fell further and further behind. Apple "switched" for a damned good reason, and "Intel Inside" doesn't describe it.



It should've been replaced a long time ago with a pure RISC instruction set especially now with the quest for less power-hungry chips

First of all, all modern chips have a native RISC-like core with an x86 frontend implemented entirely in microcode - So if the world still wanted PPC, Intel could release a C2D tomorrow that exported that as the visible interface. Arguing CISC vs RISC in today's world has as much meaning as arguing over case colors.

Second, the CPU's ISA has no (direct) effect on power consumption. RISC processors traditionally drew less power because they simply had fewer transistors (and a painfully small instruction set to show for it). A "modern" RISC processor, with multiple cores, multiple deep pipelined execution units, a variety of FP and SIMD units, and multiple levels of fairly large cache, would draw power comparably to anything currently available from AMD or Intel.

Finally, this battle died with DEC and SGI and MIPS. Let it rest in peace.

Re:i pooped my pants

[tttonyyy]

it smells awful. Clearly you're like earlier 65-nm processors - slow and leaky.

It's not really true

[Moraelin]

Well, bear some things in mind:

1. At one point in time there was a substantial difference between RISC and CISC architectures. CPUs had tiny budgets of transistors (almost homeopathic, by today's standards), and there was a real design decision where you put those transistors. You could have more registers (RISC) or a more complex decoder (CISC), but not both. (And that already gives you an idea about the kinds of transistor budgets I'm talking about, if having 16 or 32 registers instead of 1 to 8 actually made a difference.)

Both sides had their advantages, btw. If it were that bleeding obvious that RISC = teh winner and CISC = teh loser, a lot of history would be different.

The difference narrowed a lot over time, though, so neither is purely CISC or RISC any more (except marketting bullshit or fanboy wars.) Neither the original RISC idea nor the CISC one scaled past a point, so now we have largely the same weird hybrid in both camps.

E.g., the Altivec instruction set on PowerPC is the exact opposite of what the original RISC idea was. The very idea of RISC was never to implement in hardware what a compiler would do for you in software. So the very idea of having whole procedures and loops coded in the CPU instead of in software would have seemed the bloody opposite of all that RISC is about, back in the day.

At any rate, what both are today is what previously used to be called a microcoded architecture. It's sorta like having a CPU inside a CPU. The smaller one inside works on much simpler operations, but an instruction of the "outer" CPU translates into several of those micro-operations. Which in turn are pipelined, reordered in flight, etc, to have them execute faster.

What both sides are doing nowadays for marketting reasons is basically calling the inner architecture "RISC", because marketing really likes that term, and the lemmings have been already conditioned to get excited when they hear "RISC". Really, PowerPC's architecture is only "RISC" on account of basically "yeah, but deep down inside it's still sorta RISC like"... and ironically the x86's can make the exact same claim too.

At any rate, whether you want to call that RISC or not, once you look inside it, both the PowerPC and the Pentiums/Athlons have nearly identical architectures and modules. Sure, the implementation details differ, and some have advantages over other implementations (the Netburst ones had too long pipes, while a G4 had a tiny pipe, so the G4 did have better IPC), but essentially they both are based on the exact same architecture. Neither is more RISC than the other. We can lay that RISC-vs-CISC war to rest.

2. That said, the x86 still was somewhat hampered by the lack of more general purpose registers. Although the compilers and the CPU itself did optimize heavily around the problem, they didn't always do the optimal job.

That has changed in the 64 bit version, though. AMD went and doubled the number of registers for programs running in 64 bit mode, and Intel had to use the same set of instructions so they have that too nowadays.

The performance penalty of that architecture basically became a lot lower than it was in the days of G4 vs Pentium 4 flame wars.

CISC to RISC runtime translation

[Z-MaxX]

An often overlooked benefit of the way that modern IA32 processors achieve high performance through translating the CISC x86 instructions into microcode instructions is that the chip designers are free to change the internal microcode architecture for every CPU in order to implement new optimizations or to tune the microcode language for the particular chip's strengths. If we were all coding (or if our compilers were coding for us) in this RISCy microcode, then we, or the compiler, would have to do the optimizations that the CPU can do in its translation to microcode. I agree that the Power architecture is pretty cool, but I'm tired of hearing people bash the Intel x86 architecture for its "obsolete" nature. As long as it is the fastest and best thing I can buy for a reasonable amount of money, it's my top choice.

it's not the halogen atoms themselves

[Quadraginta]

The problem is not the halogen atoms themselves, but the chemical reactivity a carbon atom gets when it's bonded to a halogen atom. That is, an organic compound that contains carbon-chlorine bonds is obnoxious not because of the chlorine atoms, but because the chlorine atoms "activate" the carbon atoms to which they're bonded (more precisely they make it far easier for nucleophilic and radical reactions to happen at the carbon atom) so that the carbon atom can do chemistry inside you (or inside some other animal) that you really don't want to happen, e.g. mutating your DNA. This is why chlorinated organic compounds (e.g. PCBs, perc, carbon tet) tend to be tightly regulated.

The halogens themselves (Cl_2 et cetera) and the halogen-oxygen compounds you find in swimming pools (e.g. hypochlorite anions) are merely noxiously caustic, like acid. At high enough concentrations they might scar your lungs and skin, or kill you, but they won't seep into your tissues and do insidious chemistry that gives you cancer or lupus, and they're quite harmless at low concentrations (e.g. what you find in your pool, or in seawater).

AMD Cannot Compete Unless...

[MOBE2001]

If this is how it ends for AMD, this is how it goes.

AMD is fighting a losing battle. Intel defined the current market and AMD cannot beat them at their own game. They are condemned to always play second fiddle unless they can find a way to redefine the market. They can only do so by reassessing the current state of the art in multicore CPU architecture and computer programming and correct what is wrong with it. And there is a lot that is wrong with it. I call it The Age of Crappy Concurrency. Check it out.

Now that the industry is transitioning to massive parallelism, AMD has the chance of a lifetime to change the computing landscape in its favor and leave Intel and everybody else in the dust.

Re:Power efficient???

[pla]

No way your computer draws only 65W, unless you have a VERY old computer or a shuttle that can barely do anything.

Provide an email address and I'll send you a picture of a Kill-A-Watt reading in the high-50W range with the CPU pegged (and in the low 40s idle). I respect your pessimism, but really do run two such systems; One even has something vaguely resembling a decent GPU, though no doubt the hardcore gamers would sneer heartily at it (not that I care, as I said, as I mostly prefer RPG and RTS over FPS).

As for "older", AMD has two entire lines of modern, dual-core chips running between 31W (Turion) and 45W ("BE" parts). While true that dual 2.3Ghz cores don't rock the world anymore, as I said, they perform so much more than "okay" that I don't see myself upgrading for at least another two years (barring any revolutionary advances in CPU technology before then, which looks exceedingly unlikely IMO).



Not to mention your power supply is at max 85% efficient.

I've had enough crappy low-end PSUs take out systems in the past that I buy only the best now - And as a side effect of "quality", you tend to get "efficiency". I personally favor SeaSonic's hardware, of which the newer ones push 88% efficient; Though yes, the ones I have now only claim 85%.

Regardless, keep in mind that that number applies multiplicatively to whatever your CPU and GPU (and the negligible rest) draw... 0.85*(35+16) wastes only 9W, while 0.85*(120+107) wastes over 40W. Just think about that for a sec - A carelessly designed midrange PC can easily waste, just in PSU losses, my total light-use draw.



or a shuttle that can barely do anything.

I run one of those (well, a home-built EPIA system) as my home file server. 22W at-the-wall (not counting the bank of HDDs except the boot drive), and it can perform its one and only real "task" (saturating a gigabit network connection) juuuuuust fine.

Come Full Circle

[IorDMUX]

Once upon a time (1970's), everybody used metal for their FET gates. Those aluminum gates are where we got the names MOSFET (Metal-Oxide-Silicon Field Effect Transistor) and CMOS (Complementary MOSFET). In the 1980's, pretty much every fab gave up metal gates for the polysilicon that has been used since, amidst various enhancements in polysilicon deposition technology, self aligned gates, etc.

Now, the trend seems to be to return to the metal gates of yesteryear and ditch the oxide (the 'O' in MOSFET) for high-k dielectrics (not high-k metals, as the summary seems to say)...

That's all well and good, but I have one question... when will we get around to updating the term "CMOS"?

Names of Rivers?

[spineboy]

I'm just wondering which will end first - Moores law, or the number of river names left in Washington. For those of you who don't know, all of Intels chip names are named after rivers in Washington state.

Re:Names of Rivers?

[ikeleib]

The names are mostly after Oregon rivers: http://en.wikipedia.org/wiki/List_of_Intel_codenames

Re:Still sticking

[OwnedByTwoCats]

Rather than old-fashioned reciprocating engines, how about outside-of-the-box thinking? A small gas-turbine, powering a generator, battery packs, and then electric motors driving all 4 wheels and offering regenerative braking as well?

Hydrogen power is best when it doesn't suffer the 40% losses of combustion, i.e. when it goes through a fuel cell and is converted to electricity with 85% efficiency.

Re:x86 already has elements of RISC & PowerPC

[homer_ca]

You're correct that the x86 instruction set is still cruft, and a pure RISC CPU is theoretically more efficient. However, the real world disadvantage of x86 support is minimal. With each die shrink, the x86 to micro-op translator occupies less die space proportionally, and the advantages of the installed hardware and software base gives x86 CPUs a huge lead in economies of scale.

I know we're both just putting different spins on the same facts, but in the end, practical considerations outweigh engineering purity. x86 is even competing against ARM in the embedded space now, not just in higher powered UMPCs, but also routers too like this one with a 486 class CPU.

Re:Still sticking

[fitten]

As much as it sucks to admit it ;), CISC is even interesting in that it is sort of a 'code compression' built-in sometimes. Sometimes, you can load one CISC instruction that does the work of several RISC instructions. The CISC instruction will take up less memory. This means that not only does it take less memory, it takes less cache space, leaving more for other things (more code, more data) and cache space (particularly L1) is still at a premium. Not only that, a fetch of such a CISC instruction is like several fetches that make up the same sequence of RISC instructions.

There's a big gap between the CPU and main memory... taking up less memory for instructions and, in effect, fetching more instructions per fetch cycle can have some benefits.

That being said, there's nothing to prevent you from programming a modern x86 processor in a RISC-like way. It even sometimes has performance benefits. (Some compilers do this already.)

THAT being said... I haven't programmed in assembly in years... I let compilers do that work for me.

POWER6 is now In-Order

[emil]

• While POWER5 was out-of-order, POWER6 is now in-order. That's how they plan to hit 5ghz.
• While you've added 8 more registers, you've also doubled the size of pointers (and thus doubled the memory bandwidth required for them). We've seen several cases where Sparc-32 compiled applications are faster than Sparc-64 on the same platform - therefore I'd benchmark an application in 32-bit mode before I'd take the 64-bit version.

Re:Power efficient???

[pla]

Can you share details?

Sure. Start with a VIA Epia LN10000EG (I personally use LogicSupply for my mini-ITX shopping, they haven't screwed me yet). Toss in a gig of DDR2 533 RAM. Get the lowest wattage SeaSonic PSU you can find (or other known quality unit - You will regret saving $30 here).

Get any ol' $20 ATX case with four (or more) external 5.25 bays. You obviously don't need one with a PSU, but you'll find that it costs less to get one with power and toss the stock unit.

Get a ThermalTake A2309 iCage (NewEgg carries these), the best $17 you'll ever spend on computer parts. I put one of these (or something comparable) into every machine I build, and it holds up to three HDDs (perfect with a fourth bay holding your optical drive).

You may want to get a gigabit NIC card rather than using the onboard 10/100. You could also get the... Hmmm... I think Epia EK12000EG, a similar board that has an onboard gigabit NIC, but it costs almost twice the price for basically just that one feature. You also will probably want to get a loose 12cm fan to blow in the general direction of the CPU - Officially the LN10000EG works fanless, but in practice it can get pretty warm.

And there you go... Everything you need except the actual drives, for under $250. Toss in a DVD burner and a 500GB drive (currently the "sweet" price point) or three, install your favorite Linux distro, and you have an instant home file/media server drawing only 30-50W (depending mostly on what and how many HDDs you put in it; you can also force-throttle the CPU in the BIOS to squeeze out a few more watts) at the wall.



One warning about drives, though... I've had horrible luck with VIA's SATA drivers for Linux. I'd recommend sticking with the PATA for now, or even going so far as to run Windows if you must use the SATA port(s). And for the record, I do not recommend the marginally-cheaper Epia clones such as JetWay. I've only dealt with a few of them, but they without exception have sucked, and hard.

Re:Price/Performance? Who shops that way?

[JAlexoi]

But you are paying for performance ONLY when you buy anything from Intel that is faster than anything AMD has to offer.
That is, if the X2 6000+ performs like E6700, then buying anything that is faster than E6700 means paying for performance otherwise money down the drain.