Wandering Thoughts archives

The program energy efficiency optimist's view

Despite what I wrote last entry, I think that there is an energy efficiency optimist's view and that it has a lot of validity. It goes like this:

First, there are an increasing number of interesting devices on which power efficiency really does matter significantly, either because it saves you money (such as compute clouds where you are charged very precisely for resource usage) or because it lets you run at all (laptops on battery power, low-power netbooks, cellphones, and so on).

Second, there is likely a collection of various easy energy efficiency improvements that haven't been made, either because the programmers involved haven't looked for them before now or because they haven't cared; before there were interesting devices where this really mattered, being energy inefficient probably just made your program run slowly (if you even noticed).

Thus the optimist's view is that the problem matters and we have ways to make relatively rapid, meaningful progress. In the process we may even improve things for other people, making real differences in things like startup times.

(This is the same view as the optimist for anything, broadly that the new problem matters and we can easily do things about it now that we actually care.)

(This seems to be actually working in the Linux world, at least to some degree, and creating useful results. Although I can't dig up the references right now, I have a memory that people looking into these issues turned up the fact that some programs looked at several thousand files on startup, which had obvious bad effects on the startup time even on fast desktop machines.)

The cost of program energy efficiency

There's been somewhat of a movement of late to make programs be energy efficient (both for applications that might be running on laptops and for applications that might run in a cloud computing environment with detailed charging). This all sounds very good and worthwhile, and hard to argue against.

But it has a problem (the same problem as always, really). In general, such efficiency is not free since development time is not limitless. Saying that applications should be optimized to be 'green' in this way is to say that they should have less features or be slower to develop or both.

(And this is just as true of open source programs as it is of commercial programs.)

Despite this, it may come to pass that 'green' applications will appear and that the greenness of an application will matter. But if it does, it will be because the costs of not being green have changed, and changed enough to matter, not because it is a praiseworthy thing in general. And advocating for energy efficiency in programs without figuring out how to pay for it is once again solving the technical problem without considering the more important social one.

Now it's time to be honest: this is a fairly pessimistic view of the situation. The more optimistic one is that there are a number of improvements that are basically costless if they're done when the code is being written, situations where there is an equally good but more energy efficient ways of doing something (in the same way that select() is better than busy-waits). Getting people to use these better ways would only take education and persuasion, and I think that's already started happening.

Encapsulation may be in the eye of the beholder

Here is an interesting question: is getloadavg() a more or less encapsulated way of getting the load average than (on Linux) reading /proc/loadavg? I wound up thinking about this in the aftermath of feeling rueful about discovering Python's interface to getloadavg(), and I don't think it's as simple as I made it out to be in my original entry.

For me, what it comes down to is different perspectives. An interface like getloadavg() is nicely encapsulated for someone who can easily use the C library; you get an interface that works on any system that supports it. But for someone using alternate languages like Python, Perl, or Ruby, a file as an interface is much more accessible than a something that's wrapped up in the C library, and thus the interface it provides is much more abstract and usable. You would much rather be able to get the information by just reading a file than have it only available if you can figure out how to call a new C library function.

(I would go so far as to say that a new interface that is only available by calling a C library function is not so much wrapped up in the C library as locked up in the C library.)

So: from the perspective of getting the load average on a lot of different Unixes in a C program, getloadavg() is more encapsulated. But from the perspective of getting the load average from a lot of different environments on a Linux system, I'd argue that /proc/loadavg may be more abstracted and encapsulated, since it's available to everything and you use it just the same way in all of the languages.