Hacker News new | past | comments | ask | show | jobs | submit login

Those figures are pretty close to being lies. A quad-core 3.3GHz Xeon that's only serving 6950 requests per second isn't going to be at anywhere near 100% utilisation, which means there's no way it's running at anywhere near its TDP. Same for the RAM. The x86 isn't going to be anywhere near 5W, but it's going to be significantly lower than 102W. They're also ignoring the fixed disk and PSU overheads, shifting the power side of the ratio in favour of the Calxeda, and using a benchmark that's going to end up network limited is a solid way of reducing the performance advantage of the Xeon.

I don't doubt that ARM does have a better power/performance ratio, but it's nowhere near 15x. Using such obviously misleading statistics leaves me suspecting it's way closer than that.




While what you say is true, it's also true that a lot of x86 servers sit idle precisely because they're network-limited. Wasting power that way is no different than wasting power any other way. That effect far outweighs any quibbling about whether the x86 really uses its full TDP (it won't) or needs more support chips that more than make up for it (it will), or what kinds of memory are involved, etc.

Just so happens that I have both an x86 box and an ARM box in my office. Maybe on my next day off (that I'm not stuffing my face with turkey) I'll run some benchmarks myself.


Well sure, but you could replace those servers with a low-power x86 and get most of the same benefit that Calxeda are touting. Massively overprovisioning is going to waste power. An 8051 is probably going to give a better power/performance ratio than a quad-core ARM for an embedded controller, which tells me nothing about which I should choose to run my database.


Where is that low-power x86 and its fleet of low-power support chips to do what something like an Armada or EnergyCore can do on its own? They have yet to come up with one.

As for your 8051 example, it's bogus because that chip simply can't do the work. It can't run a real OS, and even if it could do that it couldn't keep even a single Ethernet or SATA port busy. Therefore you'd need a lot more nodes, each with their own network/storage/memory that don't come for free, rapidly wiping out any savings on the CPU alone before you even get to the high-node-count coordination problems that would make the whole thing fall flat on its face.

The whole issue here is not just absolute minimum power but balance. In a server environment, where the processor's job is about keeping ports full more than about pure number-crunching, you have to start with what kinds of ports you have. What processor and memory most exactly matches a commodity I/O profile, neither running over nor falling short, while consuming the fewest watts? Modern ARM chips are often a better answer to that question than anything Intel makes. It's a shame that some people who've invested many years in x86-specific expertise might find the market for those skills eroding as a result, but that's the harsh reality.


A quad-core Xeon is overkill for a static content webserver. An ARM is overkill for an embedded controller. If you specify inappropriate hardware then you'll end up with an inappropriate power/performance ratio.

As for low-power x86 - HP's Moonshot is in the ballpark of ARM blade devices, and Baytrail pushes Intel even closer. ARM probably still wins, but the figures are nothing like 15x. And once you take fixed costs like disk and RAM into account, the difference ends up being even smaller.

ARM have done a great job of improving the performance of their cores. Intel have done a great job of cutting the x86 power budget. Given that nobody's really shipping ARM servers yet, it's still not clear who's going to come up with the better product. The problem that ARM face is that they not only have to be better, they have to be sufficiently better that it's worth the cost of porting in-house applications to a new architecture.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: