Environmental sustainability for computational research

Environmental impacts of computing

Graph showing an increase in global data centre energy usage from around 250 TWh in 2020 to around 400 TWh in 2024, and a steeper predicted increase up to almost 1000 TWh in 2030 Artwork by Dillon Marsh, showing a photo of a copper mine containing a realistic CGI ball of copper. Photograph of a river feeding into a reservoir, with a low water level that reveals an old stone bridge in addition to a modern bridge. Close-up photograph of electronic waste on the ground, including a computer mouse several and broken circuit boards.

Computing impacts the environment in multiple ways: * Data centres use large amounts of energy, and this is predicted to increase due to demand for things like AI * Data centres also require water for cooling, which can contribute to water stress and drought * Producing the hardware that fills these data centres requires mining for metals to make the hardware components * Finally, electronic waste has to be disposed of, and if not done properly this can also adversely affect the environment It might seem that our individual contributions are quite small, compared to those of tech giants like Amazon or Google However, I believe we can all contribute to reducing these environmental impacts In particular, researchers and open source developers can have more freedom to experiment with new ways of doing things, compared to industry Also, Bioconductor is really beginner-friendly, so it’s often a novice’s first exposure to programming and data analysis That means we have the opportunity to set people up with good habits from the start

What can we do?

Sufficiency: do the minimal amount of computing required

Developer workflow

Sufficiency
- Minimal examples
- Minimal CI workflows
- Efficient use of AI coding assistants

Carbon awareness
- Choose a resource or region with green electricity

To talk about how to apply these principles in practice, I’m going to separate them into those that are most relevant to the developer workflow, and those that are most relevant to the package code itself. Starting with the developer workflow, the principles that come into play here are sufficiency and carbon awareness. Sufficiency can mean ensuring that examples used in your tests and vignettes are as small as possible to be useful (which you’re probably already doing) It can also mean looking at other aspects of your developer workflow For example, if you run your own continuous integration workflows using something like Github Actions, in addition to the Bioconductor Build System, it’s really easy to run these on lots of different combinations of OS, R version, etc, on every push. But that’s probably overkill, and a smaller subset could be used. If you use AI coding assistants, these can be configured to be more efficient - using smaller models for simple tasks, asking before doing things that are computationally intensive, and so on. Carbon awareness isn’t something that comes up much, to be honest. Most of us don’t have much control over the electricity sources we’re using. However, if you’re using HPC or cloud computing, you may be able to choose to run your code at a time or place with greener electricity

User-facing code

Hardware efficiency
- Memory usage
- Appropriate HPC/cloud resource requests

Energy efficiency
- Code optimisation

Code profiling

Where are the bottlenecks?

library(profvis)
profvis({
  x <- integer()
  for (i in 1:10000){
    x <- c(x, i)
  }
})

Code profiling

Code optimisation

Non-exhaustive list of ideas:

Vectorisation
Avoid copies
Find a faster existing function (e.g. that uses RCpp)
Do less - use a more specialised function

Once you’ve identified the bottlenecks in your code, what can you do to make your code more efficient? The best ways to do this will depend a lot on what exactly your code is doing, so this is just a few ideas. Vectorisation, and avoiding making copies of data, are always good to do, and again many packages will already be doing this. If there’s a particular function that’s slow, you could look for a faster function that does the same thing - for example, fread from the data.table package is much faster than read.csv on large files. You can also chose a function that does less - something that’s more specialised. For example, if you have a matrix but you’re passing it to a function that coerces it to a data frame, you might be better off looking for a function that works on matrices directly.

Caveats

Can make code harder to understand
Can increase maintenance burden
Avoid premature optimisation
Focus on biggest impact areas

How to start?

Review your development workflow
Document how to use your package efficiently
Profile your package code
Try one optimisation

Want to collaborate? Get in touch!

liz.ing-simmons@kcl.ac.uk

Resources

Environmental Sustainability for Computational Science forum
Adopting a more rational use of Continuous Integration
Low-energy AI guidance
Profiling tutorial
Advanced R - Measuring performance and Improving performance chapters
Efficient R

Image credits

Energy: Nature
Water: ITV/PA
Resources: Dillon Marsh, “For what it’s worth”
E-waste: Muntaka Chasant, CC BY-SA 4.0
Green Software Principles: Green Software Foundation