Hacker News new | ask | show | jobs
by asragab 3212 days ago
This article is ostensibly about how the current implementation of namedtuples has had serious consequences for the startup time of Python, because namedtuples are used in the compilation of classes (roughly). However, somehow this buries the lede...the most "interesting" discussion is kicked off by the first comment:

  Issues around the performance of Python and programs 
  written in it have far wider consequences than startup 
  time. During all the time any Python program is running, 
  its host machine is consuming power that typically depends
  on pumping CO2 into the atmosphere. If most of that power is 
  wasted, the effects go far beyond extra money to buy 
  it, or to operate extra servers, or users who wait a 
  little longer. The carbon footprint of a Python program 
  that runs throughout a data center, or many data centers, 
  adds up.
There was an article earlier on HN about the energy consumption pattern of Bitcoin/Ethereum and presumably any blockchain that implements a proof-of-work protocol/scheme, and between that article and this comment - I've started to notice a growing unease (I am probably waaay behind on the uptake) about the "world-eating" capacity of software.

I wonder how quantifiable implementation decisions like the ones exhibited by namedtuples in Python, which one might argue is an unfortunate/accidental side-effect vis-a-vis energy consumption, versus ones like proof-of-work, which I would argue are explicitly designed to be expensive.

And if anything should come of that quantification, namely, does optimizing code really become a moral imperative, and if so are there some usability and refactorability metrics that are often held in high regard that we ought to consider abandoning in the name of "energy efficient" software.

Obviously, this isn't a simple tradeoff, software that is difficult to write because it is highly optimized is difficult to maintain, and it might be the case that performance derived energy savings are outweighed by the energy cost of maintenance (literally, the energy cost of debugging and testing).

6 comments

I do believe that we should consider a moral obligation to optimize the sh$$ out of widely used software. Inefficient algorithms running in millions of billions of instances (cloud data centers, smartphones, home routers, smart TVs...) create a considerable environmental footprint fast. This is especially true as long as we are powering them using non-renewable energy sources.

The amount of effort that can be spent on optimizations on this kind of widely used software is enormous before the balance becomes negative. If an optimization that shaves off 1 second of CPU time used per year on each of a million devices will result in a net reduction in energy usage within the first year even if it takes 30 eight hour work days to develop.

This train of thought becomes particularly nasty when you realize that all the computational overhead introduced by the widespread usage of encryption (https etc.) must necessarily lead to environmental damage. To put it in the most provocative way I can think of right now: which is more important: the security of your personal data now or the safety and wellbeing of future generations of humankind?

Systems of elements that can trust each other are more efficient than systems of elements that must expend energy to check each other.
There is a drive to improve performances of dynamic languages. Probably not a moral imperative but business imperatives. Everybody remembers what happened to JavaScript, from slow to fast in a few years. The same forces are at work on Python (or Ruby, which gets faster at every iteration.)

But those tradeoffs are difficult to assess. Example: which is greener, unoptimized code that took 1 hour to develop or optimized code that took 1 day? I guess it depends on how long that code has to run. And what if the company spending 10x to optimize all code is forced out of business by another company that got all the customers while they were optimizing code? Then all that optimized code is wasted.

Concentrating optimizations in the compiler or interpreter scales better IMHO.

> The same forces are at work on Python (or Ruby, which gets faster at every iteration.)

Python performance has been one step forward two steps back. For example, dict() has significantly evolved over time and some other things became faster as well, but most stuff just becomes slower as more stuff is added or previously native code is replaced by pure Python (see io in 3.0, which was reverted, or import).

Ditto for Python application performance. Python has exactly no zero-cost abstractions, so when something is refactored to use classes or big methods are split up, the result is almost always slower than before.

As long as ridiculous concepts like fossil-fuel burning cars are legal and in wide use, I think it is premature to optimize for program power consumption.

There are far bigger issues.

If the cost of energy accurately reflected its effect on the environment, a lot of these sorts of questions would be easier to answer.
It's interesting to run some numbers here. Say you're a software company that's totally dedicated to removing CO2 from the atmosphere: you run a business, but that's just to fund your CO2 reduction efforts. Should you rewrite your python code in C? Sure, it'll reduce your carbon footprint, but it'll deduct from your profits, which directly reduce atmospheric CO2.

I'm trying to compute the best case scenario for a rewrite here, and I've tried to err in that direction whenever possible. US power consumption in 2015 was 4,144.3 TWh, and CO2 production in 2016 (presumably higher than 2015) was 1821 Tg. Electricity costs in Oaklahoma (cheapest state in the US according to [0]) are 6.8c/kWh

I'm assuming that you're reducing CO2 by buying carbon offsets: if you have a better way, that makes the case for a rewrite weaker. Poking around a bit leads me to [1], and taking one of the higher values on that page gives me $15/ton (assuming imperial to favor a rewrite). Multiplying all that out give me that for every $100 spent on electricity, you need to spend an additional $10 to cancel it out.

That's... something. But of course, datacenters don't spend all their money on electricity: one of the higher figures I could find [2] gives me 20%. On the other hand, the rest of the datacenter generates CO2 as well. I found tracking down datacenter-specific data really hard here. The CO2 impact of computers is mostly in manufacturing, for example [3]. On the other hand, servers see much more use than a typical consumer box, which complicates things. Ideally we'd break down the CO2 emissions for each component of the datacenter. But that seems hard, so let's instead assume the rest of the datacenter produces as much CO2/dollar as the electricity does. This seems really high: utilities as a whole make up 1.6% of the US GDP[4] but account for 29% of the US's CO2 output[5]. Still, even with that assumption, your datacenter externalities are 10%.

If you're right on the borderline here, then maybe that's enough to push you to do the rewrite. But the mantra that "computers are cheap, developers are expensive" still holds when you take externalities into account.

Now of course, most companies don't exist to reduce atmospheric CO2. But if you're going to exhort a company to reduce CO2, it's almost certainly cheaper for them (or more effective for you, depending on how you look at it) to just buy carbon offsets then rewrite all their python in <faster language here>.

[0] https://www.electricchoice.com/electricity-prices-by-state/

[1] https://www.carbonfootprint.com/offset.aspx?o=1

[2] http://www.linuxlabs.com/PDF/Data%20Center%20Cost%20of%20Own...

[3] http://www.sciencedirect.com/science/article/pii/S0959652611...

[4] https://www.bea.gov/iTable/iTable.cfm?ReqID=51&step=1#reqid=...

[5] https://www.epa.gov/ghgemissions/sources-greenhouse-gas-emis...

My PC is powered, I think, entirely by hydroelectric power stations. Almost all of New Zealand's power is.
24% hydro, 28% gas, 29% geothermal, 8% wind, 8% coal.

https://en.wikipedia.org/wiki/Electricity_sector_in_New_Zeal...

This is entirely off-topic; But you've misread that table. those are the stats for the north island, The total split is actually:

57% hydro, 16% gas, 16% geothermal, 5% wind, 4% coal. As an aside, the South Island generates 98% of it's electricity via hydro, so if he's in the south island it would be fair to say his PC is powered entirely by hydro.

I have indeed completely misread that table! Thanks for the correction.