I recently wrote a piece about 8 ways to make your software more energy efficient.
The company that provided the advice, the Software Improvement Group (SIG) based in Amsterdam in the Netherlands has set up a lab together with the nearby Hogeschool van Amsterdam (HvA) to investigate further how to make software more energy efficient.
The Software Energy Footprint Lab (#SEFL) will enable researchers to find answers to questions such as:
- How do different database management systems compare to each other in terms of energy consumption?
- How do different programing languages/compilers compare to each other in terms of energy consumption?
- How does asynchronous requests compare to synchronous requests in terms of energy consumption?
- How does unsigned integer arithmetic operations compare to signed arithmetic operations with respect to energy consumption?
- How accurate are software energy profiling tools?
SIG's Head of Research Joost Visser explained some of the thinking behind the energy efficiency investigations, which aside from sustainability and energy drivers, also have key drivers for organisations in terms of cost and scarcity.
"There are basically two types of this problem that you can break this down and look into. One is across the software lifecycle. So just as with software defects where the later you find them the more expensive they are, so with energy efficiency, if you try to optimise your software once it's already in production, you may have to make an explicit investment that might not provide an adequate payback. But if you already know what requirements you need to keep in mind at the design stage for energy efficiency, then, for example, you might actually choose a different communication protocol which can improve your efficiency. At each of the development process, there are things to do: in requirements, in the coding and in the testing.
"Another issue is the hierarchical level of software. The thing you might see as the consumer is the application. But actually that's not the first level that impacts energy efficiency. The first level is the user themselves. If they know what the consequences are of clicking here and searching there, they might behave slightly differently and it might have an impact on energy efficiency. If you give people feedback, they will behave differently.
"There is a premium on green products. People want to be green - but they have to be able to make a meaningful choice. There are various elements to consider. First there is the application layer. Then we have the various components from which the software application is built: a database; a runtime environment framework, and Java as a virtual machine. Then underneath there's the operating system.Then there is communication. You have to think about your mobile device uses radio to communicate when you're browsing. You may have to make an explicit switch to a Wi-Fi network which might be more energy efficient. Is it more energy efficient than 3G? We don't know yet. That is one of the things we're going to find out.
"If you keep all your browser tabs open, do you as a user know if that has any impact, or is that negligible? If you knew it was consuming energy, maybe you'd take the trouble of closing them because it has value for you. Energy consumption goes further than simply your own device. If you're browsing, you're pulling information in, and the server starts doing things for you and data starts being generated. It might be stored, consuming energy, for the next 50 years. And it makes a difference how it gets archived or stored. All of this has to be made simple for the consumer to comprehend.
"Then there's the organisational side, those organisations that have bespoke software built for them. They might be interested in 'green' from an idealistic point of view. Their clients are interested too and they want to be socially responsible. But those organisations are also very much interested in the cost aspect. Energy costs are rising and it's not just costs, but scarcity too. If more work implies more energy, at some point you may not be able to get it as easily as before. Either you will get it back in higher energy costs or it just won't be there.
"One of the things we need is a benchmark. To have a benchmark, you need comparable things. But think about it. You have online payments for a bank versus using a browser. The type of work you do with the software, the user transactions, so to speak, is completely different. If one consumes a certain amount of energy and the other consumes double that, what does that mean? Does that mean the one that consumes more is worse? Not necessarily. It may simply be doing more work. So we have to develop KPIs that allow meaningful comparison. We could talk about how much energy per function point. That sounds good, but actually it's completely wrong, because a function point is about functional size and how many features you offer. It doesn't have anything about the workload in it. You have to involve the workload into the KPI otherwise it cannot work.
"But workload is something that's completely different between different vendors and operations systems and end users. Comparing an operating system to an end user application will not work. That's why we're trying to build these things up through the work of the lab."