Thursday, September 24, 2009

Green software

Long ago I wrote a blogpost where I was mentioning that for an always-on (wall-plugged) workstation, the latest (then) fad of lowering power consumption is not that essential since, as a developer, all you care about is overall machine speed to get the job done and the cost of power is negligible compared to the cost of on developer hour (and then rent, administrative overhead, etc.)

Well, that is one aspect. The other aspect is when power consumption is important. This is clearly a major factor for large datacenters where a big chunk of their cost is power (for the machines and cooling) so they keep a keen eye on performance per watt. The specifics of the business are different there: you don't have developers on top of each machine, but you have hundreds / thousands of machines providing some service to remote users. The cost of maintaining that datacenter determines the cost you sell your services to users and your overall competitiveness.

Another scenario I've personally noticed as of late (see my other article somehow related to this) is the importance of performance per watt when working on your laptop's battery !

Now, the overall system performance per watt is a given of the machine you happen to own. You can't actually tweak that very much, except some hardware upgrade here and there and operating system optimization.

So what you are left is the actual software you use everyday and its performance per watt. Let's call that productivity per watt. Lower performing sofware might exhibit different issues:


  • Consuming too much CPU
  • Hitting the disk too often. IDEs are notoriously culprits here when a normal clean build deletes and recreates hundreds of files on disk. Even some feature like compile on save doesn't save much since developers save often and all this disk writing might actually stop the disk from going to sleep (and thus consume less power).
  • Hitting the network too often or too much. No point in checking for software updates when the user is on battery. No point downloading that 200MB "update" file -- updates should consist of binary diffs and be as small as possible (Google is looking into this as it becomes very important the more users you have). Also, laptops generally use WiFi is they are not plugged in and (I think) that consumes even more power than ethernet.


These are all optimization issues but the main culprit is not scaling down when on battery: this includes being smart about redundant tasks like re-indexing the Maven repository or checking of non-essential upgrades that could be deferred to a time when you're not on laptop battery .

What we seem to be missing is a new metric to evaluate applications: productivity per watt and teaching users to pick applications the same way they pick an A+ energy rating fridge.

Looking forward to see which IDE uses less power to refactor a class or just to stay idle.

No comments:

The case of the different jsch 0.1.54 binaries

As part of the Apache NetBeans IP clearance we are combing through all the code and dependencies. One interesting thing we bumped into wa...