By David Bicknell
It may take a little time, but in the future organisations will be able to track the energy efficiency of their software and know how much it is costing them to run.
It follows an idea developed by a Dutch SME that specialises in the quality of software. Amsterdam-based Software Improvement Group (SIG) has partnered with the nearby Hogeschool van Amsterdam (Amsterdam University of Applied Sciences) to create the Software Energy Footprint Lab (SEFLab).
SEFLab is now setting out to establish how the quality of organisations’ software code affects their energy consumption. The work will couple SIG’s knowledge and expertise in software monitoring with the enthusiasm and technical expertise of the local university students.
Campaign4Change asked Dr Joost Visser, SIG’s Head of Research how it is going about tackling the energy efficiency of software, and what elements of the problem it needs to examine.
Joost Visser: 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. In a car, the person that is actually touching the accelerator has a lot of influence on how much fuel you would use. To reduce your fuel usage, you may need to change your (driving) behaviour. The same thing applies with users of software. 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.
C4C: What sort of user feedback have you had?
JV: We did a survey around 9 months ago where we asked a lot of users about these types of things and the overwhelming conclusion of that survey was that, ‘Yes, we would like to change our behaviour but at the moment we have nothing to go on. We don’t know how to make that change.’
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. Microsoft has made a big effort in its operating system to take energy efficiency into account but I think there are many more steps to be made there. 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.
C4C: One of the areas that many organisations are talking about is the impact of consumerisation and the use of touch devices creating a new user interface that organisations’ applications will have to be rewritten for. What does than mean from an energy efficiency perspective?
JV: One of the very very real challenges now is that we want to go to those new devices with mobile strategies but time to market dictates how we think about energy efficiency. So you might choose to do develop once on different devices but on many devices, there’s no accounting for the energy consumption. You might go to HTML5, for instance, but it might consume much more energy than when you create a native application. I think by making the choices visible, we will enable people to choose. We will take away the time-to-market issue and people will be able to say,’ OK, we can have this a couple of weeks later and still make things provably more energy efficient’, which consumers will appreciate.
C4C: Will we get to a stage where the consumer will think about the energy efficiency, or are they really only going to be thinking about the coolness of the product i.e. I want an iPad and I don’t really care what the energy efficiency is?
JV: Let’s be realistic about this. Consumers want to get hold of new things. They’re right – they’re consumers. So the coolness of the device has to incorporate the energy efficiency. It’s a lifestyle product. If you offer that, they’ll want it.
C4C: But in the corporate world previously, the IT department would buy the product. Now the user, the consumer, is buying the product and he or she wants a cool devices and they don’t really know about the energy efficiency side of things.
JV: If you compare it to other types of products, fridges, for instance, suppliers do compete on energy efficiency. They all want to be rated A, and that’s partly to do with regulation and partly to do with the demands of the customer. But an essential thing to make that work is that there is a measurement, a consumable rating, that’s meaningful. And now with software, we are developing the science behind it.
Is it about green hardware? Or is it using an energy efficient battery? Or just using a bigger battery? It gives you as a consumer the incentive to use it. There is also the recycling of the batteries to be taken into account, of course.
C4C: Going back to the way the user is using the software. If you take the car analogy, ultimately there is a cost for you if you’re not driving efficiently. How do we portray those costs in terms of energy efficiency of software?
JV: Maybe you should get feedback about your consumption, not in terms of the litre of fuel you used, but in terms of euros. You want to make that last step. Similarly in software there is a lot of knowledge about CPU cycles and megabytes. But in the end you want to know what is the calorific value of what you’re doing. And that has to be put into some perspective.
C4C: If you were to take it to the nth degree, would you be able to get an idea of how much electricity or energy you had used in your browsing session?
JV: If you keep all your 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 the 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.
C4C: Is there any way you can create a benchmark or figure that talks about how much inefficient software usage can cost?
JV: Not yet. For data centre efficiency, there is the PUE. It has lots of drawbacks as well. But is has had a good impact and made choices more clear. We are working on it. We have some development of KPIs. But it’s hard. There’s a real research challenge here. One reason is the mapping of software applications to hardware. It’s not one to one. We may have one software application running on many pieces of hardware and due to virtualisation and other techniques, we have many applications running on the same hardware. With the hardware you can map how much energy goes through it. But how do you map that to the consumer of the energy i.e. the software? That’s a very difficult puzzle.
Another thing is that we’d all like to have 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. One suggestion is to 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. Yet it doesn’t have anything about the workload in it. You have to involve the workload into the KPI otherwise it cannot work.
Now 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 up through the lab.
C4C: You could end up having two years of discussions between vendors over what would be an appropriate standard for energy efficient software, couldn’t you?
JV: The way to make these protracted processes shorter is to have people with lots of initiative who just go for it in their own sphere of influence, and show that it can be done, and create a reality that others can follow. International standardisation processes take a long time, but you shouldn’t wait for it. You should go for it.