Jevons Paradox doesn’t always apply to software
When it comes to fighting climate change, I strongly believe that getting involved in politics is one of the most useful things you can do. But given how energy-intensive software is these days, writing more efficient software also seems worth doing, especially if your software is used at scale.
However, whenever efficiency is brought up, Jevons Paradox rears its head. Writing in the 19th century, Jevons pointed out that increased efficiency in the use of coal didn’t decrease the amount of coal used, it actually increased it. As it became more cost-effective and more useful, coal ended up being used in far more places.
So what about software: will faster software result in more usage, completely undoing the energy-consumption benefits of efficiency?
Rebound effects, Jevons Paradox, and baseline growth
Let’s make the reasonable assumption that the direct impact of faster software is reduced CPU usage, which therefore reduces CO2 emissions. Indirect impacts might undo this benefit by increasing usage.
Before looking at software, however, it’s worth clarifying some terms and when they apply:
- Rebound effect: Increased efficiency can increase usage of a resource beyond its otherwise normal growth. This doesn’t mean that efficiency is useless: if the rebound is smaller than the efficiency improvement, you still come out ahead. Rebound effects may still mean that efficiency on its own may not be sufficient to cause a large decrease in resource usage.
- Jevons Paradox: This is a situation where the rebound is so large it actually makes usage higher than it would have been before the efficiency improvements were introduced.
Note that just because usage of a resource has grown doesn’t mean we’re seeing a rebound effect or Jevons Paradox. For example, all things being equal one would expect residential electricity usage in rich countries to match population growth.
Examples of software applications where Jevons Paradox may not apply
Software is a very varied tool, so it’s worth examining a number of cases. When considering the outcomes of increased power efficiency, we can look at likely outcomes from multiple perspectives.
To begin with, an organization may choose to prioritize efficiency, or not; a choice to ignore efficiency isn’t a rebound effect. There is a secondary effect where an organization decides to undo efficiency improvements with new features, but again this is an choice. If efficiency is a priority, this won’t happen.
Software being inefficient because its creators chose to make it inefficient is a problem worth considering, but that’s not the problem Jevons was getting at. Our focus in this case is on secondary effects that aren’t under organizational control:
- User outcomes: How will increased efficiency impact existing users?
- Systemic outcomes: How will increased efficiency impact adoption outside the current user base?
Example: A desktop word processor
Let’s say the desktop version of Microsoft Word, or LibreOffice Writer, decided to cut their CPU usage in half.
User outcomes: It’s quite unlikely that existing users will use the word processor significantly more. People use word processors when they need word processors, and don’t when they don’t. As long as the software is usable, CPU usage doesn’t come in to it.
Systemic outcomes: In theory a word processor that is more efficient might be snappier, and therefore users are more likely to use it, switching from less snappy word processors. This is unlikely to result in significantly increased electricity usage. It’s also possible people with slow computers that couldn’t use the word processor before would start using it more, but this also seems unlikely to be that significant. Certainly the doubling necessary to hit Jevons Paradox is extremely unlikely.
In short, rebound effects seem likely to be small, and it seems implausible that the rebound effect would be large enough to trigger Jevons Paradox.
Example: WiFi router
This is more or less the same outcome as desktop word processors: cutting the energy usage of WiFi routers in half won’t increase usage among current users, and seems unlikely to significantly increase their user base.
Example: Online store
If you have a large-scale e-commerce website and cut its CPU usage by half, you might get a few more customers and a few more sales if the website is a little more responsive, but that’s about it. There will be no significant rebound effect.
Less straightforward examples
Unlike the cases above, in some situations rebound effects are much more uncertain, and could be much higher.
Example: Gene sequencing pipeline running in the cloud
I once worked at a startup working on a spatial gene sequencing service. Once the product was generally available, customers would be able to submit a tissue sample or cell culture, it would be run through a sequencer, the data from the sequencer would run through a computational pipeline in the cloud. This was a new kind product, which was not previously possible; compare this to word processors, a mature product category that hasn’t changed much in decades.
What would be the effect of cutting computational costs in half? Increased usage by existing users would happen the company decided to cut prices based on lower compute costs. And it’s possible that a sufficiently low cost could make new use cases viable, such that the potential market would increase significantly.
More broadly, novel compute-intensive applications might have significant rebound effects and possibly hit Jevons Paradox if lower costs triggered increased usage.
Example: The Faster CPython project
The goal of the Faster CPython project is to make the default Python interpreter run 5× faster. Given the goal is speed, we can assume CPython developers will not immediately undo this effort. But it’s at least possible this might result in a large rebound effect due to user and systemic effects.
Imagine a world where there are only two programming languages, Slowthon and YOLO++. YOLO++ runs ten times as fast as Slowthon, but costs ten times as much to write, and programmer time is expensive. As you speed up Slowthon, many businesses may decide to switch from writing YOLO++ to Slowthon because of the lower development costs. Since YOLO++ is still more efficient than Slowthon, you may end up with a meaningful rebound effect in power usage.
The real world is of course much more complex, but there’s at least the possibility of a significant rebound effect.
Example: Speeding up the Python scientific ecosystem
The Python scientific computing libraries aren’t written in Python, but rather in C, C++, Fortran, Cython, and increasingly Rust. As such, the Faster CPython project is mostly irrelevant to these libraries. However, I personally believe that in many cases there are still significant performance speedups possible. What would happen if you could cut CPU usage of these libraries in half?
- User outcomes: If users can get results faster, many users will either run more experiments, or run more compute-intensive experiments.
- Systemic outcomes: These effects are likely to be much less pronounced, but it’s possible faster libraries will result in people switching to these libraries from alternatives that are still faster but harder to use, less popular, etc..
In this example rebound effects are likely to be high. However, hitting Jevons Paradox is still unlikely: if current run times are a bottleneck on the number or complexity of experiments, the worst you’d expect is a 100% rebound, rather than actual worsening of power usage.
Efficiency is worthwhile, but not sufficient
What can we learn from the above?
- In many cases the rebound effects will be weak to non-existent. In these cases, faster software will almost certainly reduce energy usage, and for that matter save money.
- In other cases the rebound effect may be stronger, potentially undoing some or all of the environmental benefits of faster software. Even here not all projects are likely to have a rebound significant enough to hit Jevons Paradox.
Even in the worst case where you do hit Jevons Paradox, making useful software faster is still worthwhile:
- Faster scientific computing libraries, for example, would allow better modeling or more experiments with the same amount of compute resources. As Nelson Elhage explains, performance is a feature.
- The ability to do more with existing resources will become important if electricity costs start rising to reflect the real environmental costs of power production.
There are a variety of bottlenecks on making software more efficient, from economic incentives to managerial priorities to the limits of open source development. And even if these bottlenecks went away, efficiency on its own will be at least partially undone by rebound effects. Which leads back to the need for political engagement in order to fight climate change, since governments can take measures both to reduce bottlenecks and to ensure efficiency isn’t canceled-out by rebound effects.
