News - Google considers ARM chips for server farms: ARM shares rise

Quote:

---

If Google gives the green light to ARM deal the new partnership would be bad news for Intel.

---

Read more.

So to sum that up: "Internet giant with whole business staked on technology leadership is doing research and trialling everything in the marketplace and exploring alternatives" - massive shock. Oh no wait, it's not a massive shock at all. Throwing together a team to test ARM chips in servers is nothing for Google, they must already have a technology team for testing the bleeding edge gear and a lot of their kit is custom or semi-custom now. Frankly I'd be surprised if they *weren't* testing ARM servers along with all other micro-servers, Atom based, SeaMicro etc. Big news would be one of the internet giants declaring their tests had led them to actually deploying a whole data floor powered by something else other than Xeon/Opteron.

Going to totally and utterly agree with kingpotnoodle's post above - and Google aren't the only folks considering a move to ARM...

According to the ZDNet article "HP boldly goes hyperscale with launch of new Moonshot range" there's already an ARM option been launched for HP's "Moonshot" servers. Actually kudos to the ZDNet article - it's quite good.

Given the focus on getting datacentre power costs down, the move to low power chips seems common sense, although - personally speaking - I'd go for the server consolidation via VM's route since that means you can accommodate a whole range of workloads.

VM may not make sense when you have such big requirements. What I mean is that if Google have say 1000 servers caching search results or gmail etc. only a small % of those will not be constantly busy. So the load-balancing might only come in for some, for example:

• 10,000 for search stuff
• 10,000 for gmail
• 10,000 for gdrive
• plus
• 10,000 multi-purpose machines for load balancing

So in that case only the multi-purpose ones would need to be VM capable; for those Google could use Xeons while for the main 24/7 load they could use their own custom ARM core.

This assumes there is an actual case for them developing their own cores (which might as well be MIPS since they could afford to buy the whole company then). Maybe they have some specific instructions or architectural modification which would suit their load very well.

Of course, Google are big enough to get Intel to incorporate any features they might require. But then again, any Intel solution means feeding Intel's margins. If in a few years process nodes stagnate (maybe 7nm or so), then eventually it will no longer make sense to go with Intel for their node advantage. Imagine if AMD Athlon64 vs Intel P4 had happened with them both on the same node...

I'm guessing another factor could be Google putting their core algorithms into hardware, which they can do with a custom ARM SoC design, but which isn't possible with an Intel SoC design.

For Google, the core consideration is presumably power consumption, as their data centres are so large. So ARM makes a lot of sense there already, but Intel do have low power server Atom offerings ... so it could be the ability to put core algorithms, or parts of algorithms, into hardware, as an ARM co-processor, that is the difference.

Makes sense, my guess is they move there web servers over first as this would be the logical workload, and then look at the rest.

Software is the problem here, Intel keeps making faster and faster chips and software does not keep up.

Not even us gamers benefit even more, I bet there is very little FPS difference in games between a Sandy bridge quad core and a Haswell quad core.

Intel needs to beat ARM at there own game if they are to keep market dominance.

As a Brit though I say, Go ARM!

I thought Google famously use commodity class components that offer the best performance per dollar then customise the platform for them in house?

Using this logic there is a lot of sense in utilizing arm.

Quote:

---

Originally Posted by kompukare

VM may not make sense when you have such big requirements. What I mean is that if Google have say 1000 servers caching search results or gmail etc. only a small % of those will not be constantly busy. ...

---

Sorry didn't explain myself properly - what I was meaning was that in general I'd prefer a proper virtualized solution to one that involves a lot of discrete machines. Mainly for the ability to share resources that would otherwise be duplicated in the discrete solution.

On the other hand, as you rightly say, for Google's peculiar set of needs then discrete probably does make a huge amount more sense. But their workflow isn't necessarily representative of other businesses - and it does slightly worry me that these "micro blades" are being touted as the answer to all IT ills.

Best designs I've seen so far have had these kind of uBlade's being used for app server clouds, talking to "big iron" database backends. Such designs are obviously trying to use each class of machine to it's best effect.

If I was Google I'd go ARM and bake in some nice hardware tricks...I'm sure a nice 64-bit processor with your own hardware would be a good fit for them...