Combjelly, Re: "But much of the actual cost is tied up in things like the memory subsystems, switching fabrics for NUMA systems and the low volume engineering to create those things. Look at Sun's Starfire, for example. The high speed crossbar switches used to create the NUMA topology are very expensive. SledgeHammer with a HT switch can do the same thing for a fraction of the cost, and have lower latencies to boot."
Here's a few things for you to ponder.
First, creating a NUMA based system is not trivial, and AMD has barely gained much experience in working with multi-processor systems, let alone NUMA. It took them countless delays to get a 2-way system shipping, and that was as simple as getting to EV6 connections off of a single Northbridge. They are going to have a much harder time with Sledgehammer. I wouldn't be surprised to see a lot more delays, or possibly a cancellation of Sledgehammer completely once reality sets in, and they realize that they could miss their time to market. Sun, IBM (Sequent), and others have been doing NUMA for more than 20 years. What makes you think AMD can suddenly get it on their first try?
Second, although NUMA is difficult to implement, AMD is using a very cheap, very easy implementation. However, the performance on such an implementation scales horribly poor. Their 4-way example that they showed slides of at Microprocessor Forum showed a 7 or 8 step process just for initiating a simple memory transaction on a remote node. While local accesses are greatly improved with the integrated memory controller, remote accesses will be excessively slow. This will be very important, since going to 8-way and above will only make the problem worse. AMD could have solved this by adding a fourth Hypertransport link and criss-cross opposite nodes in their topology, but in saving costs, they added a large amount of extra latency. Despite the bandwidth that they claim to have, this will hurt them a lot in throughput with 4-way and greater systems.
Thirdly, OS support for Hammer from Microsoft has yet to be announced. Not only does this impact x86-64, but it also means something more. AMD's NUMA configuration needs OS support to function efficiently. Like I said, remote memory accesses add a lot of latency, and take up bandwidth. Having a NUMA based OS would limit the number of remote memory accesses, and increase performance - but that would require a complete redesign of the Windows OS, and it's doubtful that Microsoft would ever invest that much for AMD. Most Linux systems don't support this either, so those BSD systems that are being ported to x86-64 still won't offer AMD much more performance over the 32-bit variety. The only OSs that do support NUMA are very high end, and much more likely to support Itanium.
Fourth, your claims of cost savings on the platform level may be relevant for much larger systems, but they aren't likely to reduce the cost that much for higher volume 4-way market (where cost is more of a factor). Sledgehammer won't be a "fraction" of the cost of, say, an Itanium based server. I don't doubt that AMD will drive down the costs, but it's not likely they will be able to drive it down to a "fraction".
These are just things you should think about, because it takes more to penetrate this market than simply boasting a few Powerpoint slides.
wbmw |
