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