Taking notes from AWS, Google prepares custom Arm server chips of its own

Google is understood to be developing its own custom Arm server processors, following in the footsteps of cloud rival AWS. The search giant already supports virtual machines powered by Ampere Computing's Arm-based Altra processors, but in the wake of Amazon's in-house designed Graviton silicon, Google is said to be working on …

[elsergiovolador]

BYO

Why Google won't build their own fab?

It seems like these big corporations are clogging TSMC and other fabs used by smaller businesses, because there is no regulation.

Corporations beyond certain size should be forced to build their own manufacturing rather than using up capacity that businesses that can't do it yet use.

Regulators should really slap Google hard for that.

[katrinab]

Re: BYO

Because with the possible exception of Samsung, nobody else, not even Intel, has the ability to do it?

[elsergiovolador]

Re: BYO

Nonsense, it's all politics and laziness.

[DS999]

Re: BYO

You're exposing your cluelessness. A 5nm fab costs over $10 billion to build, and produces far more chips than Google's datacenters could ever use.

No company on Earth has an internal demand for enough chips to justify operating their own fab anymore, not Apple, not Intel, not Samsung. The foundry model is the only model going forward.

[JohnSheeran]

Is nobody worried about the lock-in this stuff creates? What is keeping these cloud providers from implementing proprietary code to keep you locked into their service?

I honestly don't get it. While we can all complain about the Intel cost model, the truth is that cloud providers charge significantly more than any server vendor charges for Intel-based (AMD too of course) solutions. Even when you wrap all of the "capability" of automation and APIs around their services it's still really difficult to justify the expense.

I personally find ARM very interesting but there seems to be very little Of the Shelf software that is common in the marketplace so it means that a lot of people are going to do a lot of custom development to work in those environments to support it. (I'm sure I'll get downvoted by everyone that loves ARM and believes that the software is everywhere)

Anyway, this is definitely interesting but it feels like it's a big risk for large companies to take.

[Anonymous Coward]

re: mplementing proprietary code to keep you locked into their service?

Don't the likes of AWS already do this with their vastly inflated charges to download YOUR data from their cloud?

Cloud Computing.... Trusting someone else with your company crown jewels. Ok until something goes wrong as it invariable does.

[JohnSheeran]

Re: re: mplementing proprietary code to keep you locked into their service?

Well, that's really my point. You're already at risk because of what you state but if you lock in to what could end up being a proprietary processor that is literally not going to be available anywhere else then it's even worse.

Yes, AWS is doing this with Graviton already. Of course I know that there will be those that say that it's ARM so it's available in the market outside of these providers but do we have assurance that they aren't building to a spec that no one else can use?

How long between when the lock in occurs and when something goes wrong so that you can't just move away without costs that go well beyond just egress charges?

[_andrew]

Re: re: mplementing proprietary code to keep you locked into their service?

The cloud lock in is already far stronger through software than through processor architecture. All of the clouds provide different APIs for databases and search and other "helpful" facilities, and those are the things that software has to accommodate to. What instruction set the compilers spit out, in order to run, almost doesn't matter. Heck, lots of the cloudy software is JavaScript or Java (or perl or python) anyway, and that already shields you from the processor architecture. Most of the rest is open-source C or C++, and that, for the most part, also doesn't care what processor it's running on (yes, existing processor-specific optimizations bite you here).

So of course there's lock in: friction equates to margin. It's not so much in the processor architectures though. It likely could be in the attached accelerator architectures (that the applications come to depend on). FPGA vs TPU vs GPU etc...

[Bitsminer]

Google and AWS can where Sun couldn't?

Supposedly, back in the day, Sun couldn't compete with the Intel x86 juggernaut to design Sparc CPUs to compete with x86. It was just too expensive to design more transistors into a chip to make it measurably faster. And too expensive to sell hundreds of thousands of CPUs against Intel selling 10s of millions.

So I wonder why now AWS and Google (and various lesser capitalized companies) can now offer ARM-based designs or greenfield designs that do now compete with the x86 camp on both performance and cost. What changed?

[_andrew]

Re: Google and AWS can where Sun couldn't?

The end of Denard scaling, and Intel fumbling the 10nm transition. Intel used to wield an unbreakable year-or-two process technology lead over all of the other fabs, and did not fabricate for other designers: they had to use the merchant fabricators (IBM/AMD which became Global Foundaries which gave up at 14nm, Samsung, TSMC, UMC, and others). Only TSMC and Samsung are still on the bleeding edge, and they will fab parts for anyone who pays.

The other factor is that previously only Intel, MIPS, DEC (Alpha) and IBM were designing big, wide, out-of-order speculative architectures. Speculation wastes work effort, and so run hotter than you want for battery powered devices. Well, that was the case until the speculation became really good, and the battery-powered devices needed to run desktop-style workloads. Now there are big, wide speculative out-of-order designs for all of them.

[katrinab]

Re: Google and AWS can where Sun couldn't?

Because they are not designing it from scratch. They are taking ARMs work, and making a few tweaks to it to suit their own specific requirements.