|
|
|
|
|
by shadowgovt
2245 days ago
|
|
But again, that's the thing. There is only 1/Y work to do in the day; it's batch work. The work in this case is constrained on the input side, not the CPU resources side; building 1 or 2 or 1,000 nodes to do the work won't decrease how expensive it is to do the work (in fact, building more computers than you need will make it cost more!). ... so why does Google build more computers than they need? Keep in mind that at Google scale, they're always and forever building "As many computers as we can possibly afford to" under the assumption that there will always be work for those machines to do. You and I may need to consider cost of manufacturing; Google doesn't. They always have the "Build datacenter infrastructure" cranked to an 11 (more accurately, they are following an N-year plan of construction that is extremely expensive to modify). That's the breakdown between Google's way of thinking and the way of thinking that you've presented: Google's cost of manufacture is fixed. Those computers will be built, whether or not they're going to also then run green-streamlined batch jobs. The limiting factor on the batch work is only so much work is generated in a day, and the rate the work is completed is already good enough that completing it in half the time yields no marginal value. So may as well complete it using sun instead of coal. |
|
That may well be the way you (and most likely Google) currently look at it, but the argument presented seems to be that everything other than where you run some batch tasks is all fixed.
Assuming everything else is fixed does make the optimisation easier, though surely nearly everything is up for debate if we're actually talking about minimising the overall footprint of a compute task?
Using fossil fuels rather than allowing these fixed costs you mention to sit idle - there is a point where your carbon/CPU cycle would actually go up by not using fossil fuels some of the time (though I am assuming less carbon emitted for a unit of power than manufacture cost).
I appreciate they are ever-expanding and predicting where non-movable workloads are going to need to be run etc etc, and I'm not suggesting there are easy answers.