On IT and... CO<sub>2</sub> Footprints

On IT and... CO<sub>2</sub> Footprints

By Sergey Ignatchenko

Overload, 27(151):8-9, June 2019

Recent headlines declare a climate emergency. Sergey Ignatchenko considers how we can make an impact on IT’s carbon footprint.

Disclaimer: as usual, the opinions within this article are those of ‘No Bugs’ Hare, and do not necessarily coincide with the opinions of the translators and Overload editors; also, please keep in mind that translation difficulties from Lapine (like those described in [ Loganberry04 ]) might have prevented an exact translation. In addition, the translator and Overload expressly disclaim all responsibility from any action or inaction resulting from reading this article.

Disclaimer #2: all the numbers within this article are calculated ‘on the back-of-an-envelope’ (see, for example, [ NoBugs17 ] for discussion), and are at best accurate within an order of magnitude; still, even being accurate within an order of magnitude is good enough for our current purposes.

These days, I happen to know quite a few fellow programmers who are bicycling to work; what’s interesting, however, is that most of them are not doing it for fun, but instead are arguing that it is a Good Thing™ to save on their CO 2 footprint. I’ve heard this line of argument soooo many times (if you’re not familiar with it, take a look, say, at [ Handy18 ]), that I decided to make some back-of-an-envelope calculations to see whether we as software developers can save a bit more than that. BTW, even if you happen to believe that global warming has nothing to do with CO 2 , only a few will disagree (I hope) that burning non-renewable resources for nothing is a Bad Thing™.

In [ Handy18 ], it is mentioned that over 16 years the author saved 3 metric tons of CO 2 by bicycling to the office instead of driving; that’s saving about 190 kilos of CO 2 per year. Now, let’s see what IT-related changes can do in terms of saving the world (from global warming, that is).

Let’s consider a few real-world examples.

Example 1: Game with 100K simultaneous players

For the purposes of our first example, let’s assume that you happen to work on a PC-based game with 100,000K simultaneous players, which uses about 100W when it is running. Now, if you can come up with a trick which saves mere 1% of this power, it means that you’ll be saving 1W × 100,000 = 100 kW of power at each and every moment, which translates into 2,400 kWh per day, or 876,000 kWh per year. Now, we can use [ CarbonFootprint ] to translate this into CO 2 and discover that one such optimization will save a whopping 270 tons of CO 2 per year(!) – that will cover 1,400 people (such as those in [ Handy18 ]) bicycling to the office and back.

How we can save that 1% of power is a different story. Just as one example, often much more than that can be saved in practice by switching to V-sync by default (that is, in the absence of G-sync/Freesync). I certainly don’t want to start a war on which is better for the end-user – screen tearing without V-sync or lag without it (especially because the answer is very game-specific) – but whenever you’re in doubt, V-sync can be preferred by default as being more environmentally friendly.

Example 2: Multithreaded video codec with 1M active install base

Now, let’s assume you’re writing a video codec, and you’re really good at it, so you have 1 million people actively using your codec, with each of these people using it 10% of the time, and while they’re using it, it eats 100W of power.

Also, let’s assume that your codec uses fine-grained multithreading, and that when it uses 4 CPU cores – it gets a 2× wall-clock speed-up compared to running on a single core. But this means that in multithreaded mode (which you enabled by default, of course), it takes 4× the power of a single core, multiplied by 0.5× of the time needed to perform the task. This means that overall power consumption will increase by about 4 × 0.5 = 2× (in fact, usually a bit less due to interplay with other components, but not by much). In other words, in multithreaded mode only the power of 2 CPU cores is actually used to produce something useful, and anything the other 2 CPUs do goes towards paying for synchronization overheads. This means that you’re wasting about 50 % of that 100 W of power per box – that’s about 50 W wasted per box!

Now, if you rewrite your codec so that it separates jobs between threads on a per-keyframe basis (which means that there is no interaction between the data in different threads, hence there is almost zero thread sync and almost zero overhead), you can get most of that 50 W back; let’s assume you’ve got 40W back. With your user base, this translates into 100,000 simultaneous users × 40 W = 4 MW. That’s 40× more than that of our 1st example – and translates into savings equivalent to those of 56,000 people bicycling per year(!!).

Example 3: Single R-R op within Linux scheduler

In our 3rd example, let’s assume that you’ve noticed how to save one single R-R operation within Linux scheduler. Now, let’s assume that Linux is running on a billion devices (which is a rather conservative estimate, if we take into account all Androids and all IoT stuff), and that the appropriate part of the scheduler is run every 10 ms. This means that you’ll be saving one R-R operation on 1× 10 9 devices × (1sec/10ms) = 1× 10 11 times every second. Assuming that an R-R operation takes one CPU cycle, this will very roughly correspond to running a hundred 1GHz CPU cores all the time – and assuming that each of these cores will eat 30W (that’s accounting for associated power consumption in memory etc.), this means that you’ve got savings of 3kW (or 42 people bicycling instead of driving each and every day). That’s just for saving one single R-R operation(!!).

Example 4: Better screen blanking defaults

Now, let’s move from considering pure programming into other computer-related things. For the purposes of our 4th example, let’s assume that you have the ability to change the default screen blanking time on a desktop system from 30 minutes down to 10 minutes, with a billion such systems working all over the world. Let’s further assume that 80% of the users don’t change defaults, that the chances that after 10 minutes a user is still staring at the monitor are 10%, that screen blanking fires three times a day, and that the monitor uses 20W when it is not blanked.

Then, this simple change in defaults will result in savings of (30-10 minutes) × 0.8 × 0.9 × 10 9 users × 20W × 5times/day = ⅓ × 3 hour/day × 14W × 10 9 = 0.014kWh/day × 10 9 ~= 5× 10 9 kWh/year, or 1,500,000 tons of CO 2 per year, which is equivalent to eight million people changing from a car to a bicycle for getting to/from the office.

NB: BTW, if you change just your own 100% screen saver into screen blanking, you’d save about 60 kilos of CO 2 per year – which is ⅓ of the savings from bicycling [ Handy18 ]; not a bad gain from such a non-effort.

Example 5: Giving up on cryptocurrency speculations

Each time you’re making your Bitcoin ‘investment’ (actually, most of the time it is pure speculation – see [ WallStreetMojo ] for the difference between the two) transaction – think how much CO 2 waste it creates.

The whole Bitcoin industry is estimated to use a whopping 22 terawatt-hours per year [ Economist ] – that’s 2.2× 10 10 kWh per year, equivalent to 35 million people bicycling to their offices – which is about the population of the whole of California (and about ⅓ of the workforce in the whole US).

In other words,

if we all simply give up on Bitcoins (which have a mostly speculative and dark-market value – their use for other purposes such as processing real-world non-dark transactions still hasn’t really started) – this would result in CO 2 savings comparable to the whole of California bicycling instead of driving(!!).

By trying to speculate on Bitcoin (Ethereal, whatever else), we’re not only gambling our hard-earned savings, but are also drastically increasing our CO 2 footprint. Moreover, this seems to be the very nature of cryptocurrencies because all of them rely on so-called Proof of Work (even the cryptocurrencies billed as ‘without Proof of Work’ still need it at least for ‘initial distribution’ [ Bentov ]).

As there are about 300,000 confirmed Bitcoin transactions per day, we can conservatively say that if you’re making one such transaction per day, you become responsible for 1/300,000 of those 22 TWh/year. Actually, as long as you’re losing in this gamble – as the vast majority of individual investors do – you’re producing more than that share because you’re feeding the pool where more transactions happen. That’s 73,000 kWh/year, or 22.4 tons of CO 2 per year, or 120 people bicycling(!!). Or, looking at it from a different angle – making just three Bitcoin transactions per year is enough to offset you bicycling all the year(!!!).

Yes, instead of bicycling to the office every day, just give up on three Bitcoin transactions per year – you will get the same CO 2 reduction .


Sure, bicycling does reduce CO 2 footprint. However, in IT there are lots of ways to save even more (often much more) than by bicycling; it can be as simple as optimizing your own program so it uses less power, readjusting screen your saver, or even giving up on just three Bitcoin transactions per year(!).

We usually print purely technical articles in Overload , but hope that this article on a broader subject is still of interest to our readership.


[Bentov] Iddo Bentov, Ariel Gabizon and Alex Mizrahi (no date) ‘Cryptocurrencies without Proof of Work’, available at: https://fc16.ifca.ai/bitcoin/papers/BGM16.pdf

[CarbonFootprint] Carbon Calculator, available at: https://www.carbonfootprint.com/calculator.aspx

[Economist] ‘Why bitcoin uses so much energy’, in The Economist explains , published 9 July 2018 at https://www.economist.com/the-economist-explains/2018/07/09/why-bitcoin-uses-so-much-energy

[Handy18] Susan Handy, ‘Want to save tons of greenhouse gases? Bike it.’, in Science & Climate , published 6 September 2018, available at: https://climatechange.ucdavis.edu/what-can-i-do/want-to-save-tons-of-greenhouse-gases-bike-it/

[Loganberry04] David ‘Loganberry’, Frithaes! - ‘An Introduction to Colloquial Lapine!’, available at http://bitsnbobstones.watershipdown.org/lapine/overview.html

[NoBugs17] ‘No Bugs’ Hare (2017) ‘The Importance of Back-of-Envelope Estimates’, Overload 137, available at: https://accu.org/index.php/journals/2341

[WallStreetMojo] ‘Differences Between Investment and Speculation’ in WallStreetMojo , available at: https://www.wallstreetmojo.com/investment-vs-speculation/

Sergey Ignatchenko has 15+ years of industry experience, including being a co-architect of a stock exchange, and the sole architect of a game with 400K simultaneous players. He currently holds the position of Security Researcher.

Your Privacy

By clicking "Accept Non-Essential Cookies" you agree ACCU can store non-essential cookies on your device and disclose information in accordance with our Privacy Policy and Cookie Policy.

Current Setting: Non-Essential Cookies REJECTED

By clicking "Include Third Party Content" you agree ACCU can forward your IP address to third-party sites (such as YouTube) to enhance the information presented on this site, and that third-party sites may store cookies on your device.

Current Setting: Third Party Content EXCLUDED

Settings can be changed at any time from the Cookie Policy page.