Today, businesses are constantly seeking ways to improve their sustainability, both in terms of their profit and environmental impact. One often overlooked influence is the performance of the software that businesses create. By investing in software performance engineering, businesses can not only reduce their hardware and development costs, but also minimize their carbon footprint. So let’s explore sustainability from a software perspective!

In this blog post, we will focus on the following four different areas: (1) Pro­duc­tiv­ity of Re­search & De­vel­op­ment (R&D), (2) cost of purchased hardware, (3) carbon footprint of purchased hardware, and (4) energy efficiency during operation. These points touch different aspects of software performance engineering, from optimizing compilation time to optimizing runtime and memory consumption.

In the following, we assume a company that ships an embedded device with its own software. The hardware needs to be purchased, is bundled with software that the company produces, and sold to end customers or businesses. For example, think of an automotive supplier that ships a camera device or an engine control unit.

Business Sustainability

The two major cost drivers that our example company has, are buying the hardware and writing the software. Performance engineering can help bring down both of these costs.

R&D Productivity

From our experience in big embedded projects, one of the biggest R&D time wastes is build time. In the past, we saw projects that had a 1.5 hour build time, and due to the software architecture a single change in an innocent looking header file could cause a complete rebuild. This is not only a minor inconvenience for software developers, it is also an actual cost factor for the business. Employees need to switch context to a different task and that causes a decrease in productivity. Under the right circumstances (different compiler, different operating system, different file system, no virus scanner, etc.) this 1.5 hour build was a matter of 5 minutes.

It gets even worse if the local build is unstable, or if the Continuous Integration (CI) performs additional stages (like smoke tests, static code analysis, etc.) that are difficult to perform on a local setup. De­ve­lo­pers increasingly start to rely on CI as their default check instead of doing a local build and test locally first. And with that, the CI job queue gets longer and longer until a single developer may only get one build though per day. The other option is that the company buys more CI resources, with increases infrastructure cost instead.

Of course, build time is not the only issue here. It is every software that is used by R&D. Imagine you speed up a custom, time-consuming layer in your neural network training software. Suddenly, your AI experts might be able to train two networks per week instead of just one.

Hardware Cost

The hardware our example company plans to deliver has a certain processing power, RAM and flash memory, or other read-only memory (ROM), for storing the program. A project we helped out in the past required more ROM than was physically available on the device, about 100 kB more. The cost for larger ROM was estimated to around 0.00014 EUR/kB (0.014 cent). That cost does not include any complications that adding more memory to a device brings along, like the need for more elaborate packaging and cooling solutions. If the company plans to sell 230 million devices, that already makes about 32,000 EUR/kB. With the need for 100 kB additional kilobyte for every device, that’s 3.2 million EUR.

Depending on the market situation, customers might not be willing to pay this extra “software bloat” fee. If the company managed to pass the cost to the customers, it would still waive 3.2 million EUR in profits.

Environmental Sustainability

According to the Greenhouse Gas Protocol, emissions are categorized into three scopes. Scope 1 includes all direct emissions, e.g. from the factories or vehicles of the company itself, scope 2 includes indirect emissions from purchased electricity, and scope 3 includes all other indirect emissions.

Software performance engineering can mostly influence scopes 2 and 3. Many international companies already keep track of scope 2 emissions, so we want to focus on two examples for scope 3 emissions here. One of them is upstream (purchased hardware) and the other is downstream (product use) in the value chain.

Mobile phone companies publish commendable sustainability reports of individual products. In order to make a practical example, we will use the carbon footprint of an iPhone 14 (128 GB memory) from 2022. From Apple’s Pro­duct En­vi­ron­men­tal Re­port iPhone 14:

Total: 61 kg CO₂e (GWP100)

• 79% production
• 2% transport
• 18% use
• <1% recycling

GWP100 CO₂e is the amount of CO₂ that one would need to emit right now to cause the same global warming potential over 100 years.

Hardware Carbon Footprint

Of course, our example company needs to buy the hardware (parts) that it ships its software on. These hardware components, e.g. a CPU or a microcontroller, are counted as scope 3 upstream emissions.

According to a study in 2021, more modern fabrication processes typically have a larger carbon footprint. Next-generation hardware, i.e. hardware that can perform more computations per Watt hour, typically uses more modern fabrication processes, and thus has a bigger carbon footprint. Bigger hardware (be it in terms of memory or processing power) also very likely has a bigger carbon footprint than smaller hardware from the same generation. For example, the Pro­duct En­vi­ron­men­tal Re­port iPhone 14 mentions that the iPhone 14 with 256 GB memory (instead of base 128 GB version) has a ~10% higher carbon footprint.

Let’s try to quantify the hardware carbon footprint from our example. CO₂e caused by the production of a single iPhone 14 is 79% of 61 kg, that is 49.4 kg. If we assume 230 million devices, which is almost exactly the number of smartphones shipped by Apple in 2023, we arrive at 11.4 million tons of CO₂e. That is about the amount of actual CO₂ emitted by Yemen, Senegal or Honduras in 2022. Recall, these 11.4 million tons of CO₂e are GWP100.

Emissions related to hardware come from semiconductor manufacturing. According to the McKinsey report “Sustainability in semiconductor operations: To­ward net-zero production” from 2022, typical semiconductor plants have most emissions in scopes 1 and 2:

• 35% in scope 1, mostly for fluoride-based etching chemicals, and
• 45% in scope 2, which is energy, among others, for environmental control, water purification, gas abatement, and lithography equipment.

While the 45% scope 2 emissions are actual CO₂ from burning fossil fuels, the 35% scope 1 emissions are mostly not CO₂ but other gases. These gases are used to etch wafers and clean rooms or equipment. They typically have a much longer lifetime than 100 years, and so GWP100 CO₂-equivalents do not fully capture the environmental impact.

Energy Efficiency During Operation

According to Apple’s sustainability report, the average use of an iPhone 14 causes 18% of the 61 kg carbon footprint. That is 10.98 kg CO₂e. In this case, it is almost completely actual CO₂ from burning fossil fuels to generate electricity.

The sustainability report also mentions that the calculations assume “a three- or four-year power use”. If we calculate with 4 years and an overall usage duration of 4 hours per day, we arrive at a carbon footprint of \(\frac{10.98}{4 \cdot (4 \cdot 365+1)} \frac{g}{h} ≈ 1.88 \frac{g}{h} ≈ 0.52 \frac{mg}{s}\). For all 230 million devices, that makes about 120 kg/s.

How much of that is wasted due to unnecessarily slow software? Let’s assume, 1 in 10 seconds are wasted, i.e. 10%. Over the complete lifetime of all 230 million devices, that makes 0.25 million tons of CO₂e. If the software, however, wastes 9 out of 10 seconds (which is not as unlikely as one would think), that makes 2.25 million tons of CO₂e over the lifetime of all devices.

Needless to say, less en­er­gy-con­strained devices, that are not batt­ery-lim­it­ed, consume a lot more energy than mobile phones. So if software wastes runtime on a datacenter server CPU, the effects will be orders of magnitudes higher.