AMD's chips are on a silicon-on-insulator (SOI) technology, which comes with less parasitic source/drain cap and no junction leakage. Switching less cap means you switch faster. No junction leakage means your part uses less power when it's idle. High-k will be coming soon enough for AMD, the 45nm tech is competing pretty well w/o it at the moment.

AMD uses an exclusive cache architecture, Intel's is inclusive. Exclusive means that a given line exists in only one cache at a given time. Inclusive means that if a line is in one cache, it's in all of them. For an AMD chip add up all the caches on the die to get total cache size. For 45nm quad-core products that's 8.25MB. For an Intel chip take the size of the last level cache, that's your effective total cache. For Nehalem that's 8MB.

You are correct about issuing and higher IPC coming with Bulldozer.

Sorry, but that's incorrect. Photons do not interact with fields inside atoms, they interact with electrons and protons. That is how lenses, photosynthesis, photodiodes, etc works. Photons are messenger particles of the electromagnetic force. Protons and electrons are the "receivers". Photons do not interact with each other except, as integer spin particles (bosons) they can occupy the same quantum state. This allows for the superposition of two photons to increase, decrease, or cancel out the amplitude of an electromagnetic field at a point in space.

Actually, I just gave an explanation of how phased array radar works. Read up on interference.

Electromagnetic fields are made of photons. An incoming photon will be superimposed (interfere) with the photons in an electromagnetic field as it passes through but it's path will remain unchanged. The only way to influence the path of a photon is to bend spacetime, which is the definition of what we call gravity.

It's actually more complicated than that. The six-core chips have the ability to configure up to a quarter of the 6MB L3 cache as a probe filter. This keeps most snoop traffic from reaching down into the L2 and L1 caches of the other cores on the same die and all cores on other die in a multi-socket system. The result is better memory latency and improved memory bandwidth. Here's a link: http://techreport.com/articles.x/16448

For a while it will be proportional to (V^2)*f. However, transistor leakage is exponential with respect to Vds due to DIBL (drain-induced barrier lowering) and the resulting decrease in threshold voltage. Raising the voltage too much is a double-whammy WRT power consumption.

Actually it does have to do with hard disks - you've got to swap to _something_ once those interpreters use all 4GB of physical RAM!

Not all of us like KDE and Gnome. Although they have innovated in some areas, they're otherwise both just attempts to make an MS clone. While this might be the right thing to make "Linux on the desktop" succeed, it's not what some of envision as the future of computing or even how we'd like the current state of computing.

I've been a Linux user since 1996 and I've watched the entire "Linux on the desktop" debacle unfold. It's sad to see that the /. crowd has changed from the attitude of "these MS clones are crap, desktop Linux should be something better" to "ho hum, this is how it should be, why innovate"? Back when this was just "Rob's page" you would've been flamed into oblivion for that public show of affection for KDE/Gnome.

Who are you to tell Google what they can and cannot build? It's about time someone put a face on the Linux desktop other than that of an MS clone. Hopefully it's not just a new window manager but a new window system. X, while great in its day, has run its course. I'd like to something fresh that builds on the concept of using modern graphics hardware to do all the heavy lifting for the GUI instead of clever CPU-intensive hacks on top of Xlib**.

You don't like Google's vision for Linux on netbooks. What's your alternative vision?

** I've written many apps with Xlib. The underlying ideas/primitives that X uses for graphics ops are obsolete so doing anything "cool" (and sometimes useful!) requires using crufty extensions rather than calling routines that are a "natural" part of the system.