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

Yeah, if you know where to look, they left clues about using MI25 hardware. (I haven't been an employee for years, this all unfolded afterwards and, ironically, it is just one search away.)

I'm sure they got bulk/promotional pricing from AMD, plus they're very good at both running hardware with low overhead and packing it efficiently.




> plus they're very good at both running hardware with low overhead and packing it efficiently.

You can't really pack the hardware here since it's latency sensitive. It's straight dedicated resources to an array of VMs. Dedicated CPU cache, even, hence the odd 9.5MB L2+L3 number.

Bulk pricing only gets you so far here. You're still talking gear that's categorically way more expensive than similar performance consumer parts. Not to mention all the other costs in play - data center, power, IT staff, etc...

Making this price-competitive is a big problem


You can't do time slicing, no, but you can definitely reduce time to first frame in many ways. If you don't do that, you need to provision even more hardware. Packing is also part of the capacity planning phases of a service.

The other costs (power, people, etc.) are amortized over Google's array of services.

Last but not least, it would be very dumb of them not to run batch workloads on these machines when the gaming service is idle. I bet $1000 these puppies run under Borg.


> The other costs (power, people, etc.) are amortized over Google's array of services.

Power doesn't really amortize, and neither does heat.

And capacity still had to increase for this. They didn't just find random GPUs under the table they forgot about, and now that they have a massive fleet of GPUs it's not suddenly going to start handling dremel queries.

This all still costs money. A shitload of it. Someone is going to pay that bill. More ads in YouTube won't really fund gaming sessions. So will this be ad breaks in the game? No way that's cost-effective for the resources used. Straight-subscription model? This seems most likely, but how much and how will you get people to pay for it?


Maybe it wasn't AMD, but they already had a massive fleet of GPUs. It wasn't running Dremel, either. Or maybe they found a way to do that, too, I don't know, but there are already enough workloads at Google to keep GPUs well fed.

I know from experience that Google is very cheap. You tell Urs you saved a million dollars and he'll ask you why you didn't save two. Or five.

If this takes off, the pricing of the service will pay for the hardware (assuming they did a reasonable job there of baking it in). Even if it doesn't, organic growth from other, much larger Google services can make use of the idle hardware.

For the record, I was involved in a couple of projects that required a lot of new hardware. One of them even ended up saving the company a lot of money in a very lucky, definitely unintended way.


>They didn't just find random GPUs under the table they forgot about, and now that they have a massive fleet of GPUs it's not suddenly going to start handling dremel queries.

This strikes me as rather amusing. Google was having such trouble getting their hands on enough GPUs that they decided to build custom hardware accelerators (TPUs) to fill the gaps.

I'm sure they'll find a use for these.




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

Search: