Compare this was something like oracle, which simply can't consume the unused resources in order to discount the hardware effectively. They can't beat GCE/AWS at the cloud game until this changes.
Actually not sure about Google either – their preemtible instances are sold at an 80% discount, so that puts an upper bound on the usefulness of these machines for them.
http://www.networkworld.com/article/2891297/cloud-computing/...
Here's how I think AWS and GCE work...
Imagine you buy some hardware. You have n=1 users, and so the variance on your compute needs is very high. You buy for peak use, so your median utilisation is low.
Now imagine you have n=10,000,000 users. Again, you stock for peak use...But the variance is now much much lower. Your median utilisation is now much better.
Let's quantify your workload as "resource-seconds", what many of Google's services (and some AWS services, like Lambda) allow you to do is maximize resources and minimize seconds (assuming efficient parallelization of workload, which is afforded by Google's super-awesome Networking). Cost is the same to you, but you get your results faster.
This is afforded by the scale and by the multi-tenant nature of underlying services. This model can only work when there's lots of folks using such a service.
(work on Google Cloud Big Data)
Curious because if I pay for using a P100 for 2 hours - it is 100% available to me and not virtualized of any sort right?
However, if I use it only for 2 hours that day, and no one else were ready and waiting to buy the time on those, then Google uses it internally until...
> GPUs are offered in passthrough mode to provide bare metal performance. Up to 8 GPU dies can be attached per VM instance including custom machine types.
When you're using it, it's 100% yours.
Disclosure: I work on Google Cloud (and pitched in on this!)
What "unused resources" are used for "their own compitation"?
How does this "pay for itself"?
I've never worked at google. Do they just let each team go with their own crazy hardware setup? Or maybe two separate systems, one internal and one external? That seems a little wasteful (they have the money, so whatever).
But wouldn't programming against a big unified api be a bit more, well, sane? I can see really sensitive stuff locked away on its own hardware, but the search front end? why not serve some JS or provide chrome downloads from a giant pool of common hardware?
Things grow organically, and they might be technically locked into a specific layout right now, that's totally understandable. But, unused capacity is just capital depreciating steadily away with no gain. Soaking up every spare cycle doing something useful should probably be somewhere in the company goals.
You can get an answer on your laptop in an hour. You'll probably get a better answer throwing 1000 hours at your algorithm though, and a better answer throwing 10000 hours.
You can do a lot of neat things if p=np. Since no one knows if that's true, we're stuck with bad big O. More computer time is the only way out right now.
The point is, I'd be disappointed in google researchers if they didn't have a huge amount of unscheduled workload.
"But Witold Jarnicki and David Konerding already did that: they wrote a C++ program that built a table of Cz(modp)Cz(modp) up to 5000500050005000 , and, in parallel across thousands of machines, searched for A,BA,B up to 200,000 and x,yx,y up to 5,000, but found no counterexamples. On a smaller scale, Edwin P. Berlin Jr. searched all CzCz up to 10171017 and also found nothing. So I don't think it is worthwhile to continue on that path."