On 13/01/14 21:14, Faidon Liambotis wrote:
We've thought a bit about it in the past, but couldn't come up with a use case that made technical or financial sense. We have dozens of x86 servers e.g. just for MediaWiki; having thousands of ARM servers for the same purpose instead doesn't sound very appealing. It'll increase our problems (e.g. scalability), it will slow down individual requests and it's unlikely to provide a technical or financial benefit.
In fact, it would slow down individual requests by a factor of 7, judging by the benchmarks of Calxeda and Xeon CPUs at
http://www.eembc.org/coremark/index.php
So instead of a 10s parse time, you would have 70s. Obviously that's not tolerable.
According to Intel's benchmarks, some Xeons have better performance per watt than ARM, so there's a question of whether ARM is an appropriate choice for a fully utilised CPU cluster, even if the load is parallelizable.
Other uses cases are similar: even our storage servers are too busy CPU-wise for ARM to make sense.
It may make sense for memcached, maybe some misc servers. But I think it would make more sense to have a bare metal provisioning process for misc servers which allowed smaller numbers of Intel cores per server, where that fits the application. That would improve energy efficiency without the need to deploy a new architecture.
-- Tim Starling