Well, I guess we're going to find out. Earlier this week I met with Andrew Feldman, one of the founders and CEO of SeaMicro — and he's betting that his Atom-based server can beat traditional Xeon-based systems. According to Andrew, the Atom processor is way more efficient on a per-watt basis than CPUs like the Xeon. Sure, it's not as fast, but it makes up for it by being cheap and power efficient, which lets you put a lot of them to work on tasks like web applications. Basically, SeaMicro puts 512 Atom-based servers into a 10U chassis, which provides virtualized network and storage resources as well as management over all these systems. This is not a big SMP box — it's literally 512 servers that share common infrastructure.

According to SeaMicro, you would need 1,000 dual-socket quad-core Xeon systems to achieve the same SPECint_rate benchmark as 40 of their systems. If my math is right, that would be 40 * 512 Atom servers=20,480 Atom CPUs, compared with 1,000 Xeons * 2 sockets * 4 cores = 8,000 Xeon cores. 

One of the most interesting technical hurdles SeaMicro had to address in building this server is the interconnect for all these processors. Rather than going with PCI-e or another off-the-shelf interconnect, SeaMicro's architecture has more in common with IBM's Blue Gene.

I admit, when I first heard the concept, I thought that SeaMicro might be full of crackpots (sorry, Andrew). At least it would have been an entertaining conversation. But since the Atoms cost less to buy and use 3-4 times less power and space, this is actually sounding pretty attractive. At least for workloads that can be massively scaled out. The main drawback seems to be that if you paid for your software on a per-CPU basis, your licensing costs would be extreme to say the least. Therefore, it seems better suited to open source software or applications that are licensed by capacity. 

The other interesting implication of this architecture is that it shuns server virtualization — because the CPUs are small and inexpensive, there's no point in subdividing them across multiple virtual machines. I'm still a little mixed on this aspect, as server virtualization also provides simplified configuration management, portability, and high availability. It could be argued that these things don't matter as much for web-based workloads that rely on an army of servers all doing the same thing. Certainly this will appeal to firms with large and power-hungry web environments; you've probably already heard about the custom servers and data centers Google and Microsoft use to lower their costs.

I'm certainly interested to see where this development leads. What about your firm — would you consider something like this or not?