The funny thing about Intel's hyperthreading is, with all the other stuff they did to the NetBurst architecture, they ended up negating most of the advantages of hyperthreading. It would be far more powerful if it had been designed to work out the potential chip-level bottlenecks. But no, Intel's long pipelines, combined with branch mispredictions, and instruction-prefetch mechanisms that produced code errors at the hardware level forced them to add a "replay" mechanism whose sole job is to correct the code in execution to make it work correctly.
It seems to me that Intel's philosophy with Netburst was to scale to as high of clock speeds as possible, and use hyperthreading, branch prediction, instruction prefetch and such to improve the efficiency of their processor; that is, make them do more stuff while under "full" load. Problem is, their plans completely backfired and that is what forced Intel to include correcting mechanisms for branch misprediction and erronious instruction prefetch; correcting mechanisms that increase die size, heat and slow their processor down. As far as I can tell, there's nothing that can fix a slow hyperthread or speed it up, except for an architecture redesign. But that's not all; not only do the Intel processors deal with these issues, but the disadvantages of the correcting mechanisms for branches and prefetching stack to make hyperthreading even less efficient than it would be otherwise.
So, it's no wonder that Intel's abandoning Netburst. The way I see it, Intel had a very good idea with Netburst, but it didn't match with reality. Their simulations were likely faulty if they "verified" that Netburst would improve the Pentium line. The ironic thing is, they would likely be much more competitive if they just stayed with whatever architecture they used in the Pentium 3; remember the early benchies where the slower P3 beat the then-new, faster P4.
Then there's Intel's Itanium, where Intel cleverly thought to market a very expensive chip that would cost their clients millions in code re-writing and ended up giving marginal improvements. All that these moves of Intel did was give AMD the chance they needed to expand into the market, and AMD utilized every bit of that chance that they could. Case in point: simultaneous 32-64-bit Opterons for servers, with lower cooling costs and not costing millions in re-writing code. Then the Linux community seemed to develop a fondness for AMD when they developed their 64-bit OS's last year. But we should be reminded that AMD moved to 64-bit computing in 2003 specifically to get marketshare in the lucrative server market, what's happening now in the personal computer realm is the result of that push. Now AMD also had the foresight to develop multi-core processors in mind for some time now, which likely wouldn't be here now if Intel was our only player. They are also
This brings me to the reason why Intel is losing ground, technologically and in the market, while AMD is gaining ground in both. Intel has lost sight of what made them succesful: giving the software community what they wanted. Instead of serving the market's desires, Intel's trying to control the market's desires by pushing all this stuff that won't really add massive benefit while at the same time making it more inconvenient to adopt. Case in point: Itanium, new motherboard for Intel's dual-core, constantly changing RAM memory support, etc. AMD is becoming more succesful because they adopted this very approach to the market, by offering more of what people want while making upgrading relatively painless. It is true that AMD used to be the x86 clone, but they've finally broken ground to become truly innovative in their technology and perceptive to market needs and desires. In the meantime, Intel's chasing perfectionist pipedreams that turn out not to be. Unless Intel gets their act together, AMD technology is going to be superior for some time to come, and that technology is also going to be spot-on with what people want. This is true for 32 to 64-bit computing, true for moving to multi-core processors, true for support of memory standards, true for not forcing developers to waste millions in writing code that can work only on your own proprietary processor with only marginal improvements.
This probably deserves its own thread, but I thought I'd place it here. In fact, I'm going to place it in its own thread so it's easy to find; I find Anandtech's thread-scrolling to be rather dodgy.
Facebook
Twitter