Inelegant code is even more harmful to the world than previously thought

We’re seeing increasing attention to environmental concerns and CO2 emissions in the world of computing software. This is not without reason: according to the International Energy Agency (IEA), data centers are already responsible for approximately 1-1.5% of global electricity consumption. This will continue to rise rapidly due to AI and cloud computing.

Efforts are underway to create more energy-efficient hardware, for example, by applying neuromorphic computing as developed in the NL-ECO initiative of the Dutch National Science Agenda. But a much more direct approach is to ensure that the code uses less energy during programming.

Often, software is written with little regard for efficiency, but is then made available to many users, thus consuming many processor hours. In such cases, small changes can lead to a huge reduction in energy consumption. Bert Hubert recently gave an interesting talk at Joy of Coding with interesting (sometimes painful) examples, such as a 40-watt (!) saving by using Spotify on the phone instead of the web app.

As specialists in scientific software, this is familiar to us. The software we work on is often computationally intensive. Small optimizations in high-performance computing (HPC) can have a major impact. We also see plenty of low-hanging fruit in less intensive applications. Yet, energy savings are never the reason clients contact us. When we make code more efficient, it’s almost always used to perform more computations – larger models, higher resolution, more simulations.

This economic principle has held true since the beginning of the Industrial Revolution, when Jevons observed that more efficient use of coal led to a massive increase in its consumption. Jevons’ paradox certainly also applies to computer hardware, on which we’ve increasingly spent more as its cost has decreased. It seems no different for software.

Yet, we continue to strive for elegant software, which, in our view, requires a reasonably efficient design. Recently, a client asked if we could parallelize their calculation program. That would certainly have made it faster, but after a brief analysis, it became clear that it was better to optimize the code itself first, as there was still much to be gained. That advice was based on pragmatism, aesthetics, and a love of sound, clean software engineering. But perhaps we could now add CO2 savings as an argument.