Comments on: IBM, Big Green, Rational and Eco-aware Programming

By: Bill Higgins

Bill Higgins — Thu, 14 Feb 2008 11:07:29 +0000

(Warning: I’ve never previously thought about this topic, so consider this all conjecture for the purposes of brainstorming :-)).

I think James Urquhart is on an interesting point re: utility computing. When I was looking at this several years ago, we always talked about how in traditional non-utility environments, servers run at an average of around 10-25% utilization, but you need all of these servers to handle peak load. But most of the time you’re sucking a lot of power just to keep the fans and memory running on an otherwise idle server.

Utility computing intends to solve this problem by spreading the load of many applications across many servers with the theory being that different applications have different peak times, so you can run at a much higher average utilization (similar to how insurance spreads risk across a large number of people). So you need net less servers for the same number of applications and as JamesU mentioned, you pay as you go.

By: Tom Raftery

Tom Raftery — Wed, 13 Feb 2008 09:53:34 +0000

Love the photos James. They are infra red and normal light photos of racks in a data centre. They indicate beautifully one of the major inefficiencies with current data centres - air mixing.

You can see a clear delta of temp from the cooler bottom of the racks to the warmer top (where warm air from the back of the racks is spilling over the top and heating the air you have spent so much cooling.

This has a knock-on effect on the lifespan of equipment in racks meaning the higher up a rack the equipment is, the sooner it fails!

The best way to combat this is to stop mixing of air in DCs by implementing a containment strategy. From an efficiency point of view, cold-aisle containment makes most sense in this latitude.

The disadvantage of cold-aisle containment is that it means the DC room is hot and this has issues of perception for any customers entering it. That needs to be overcome beforehand with education.

By: Jeff Barr’s Blog » Links for Tuesday, February 12, 2008

Jeff Barr’s Blog » Links for Tuesday, February 12, 2008 — Wed, 13 Feb 2008 05:38:42 +0000

[...] Greenmonk: IBM, Big Green, Rational and Eco-aware Programming - “I am beginning to wonder if beautiful code is green code. Code generation tends to generate pretty ugly code - but is it less efficient? Developers that write beautiful code may end up in great demand for their green coding: but this is pure conjecture at this point…“ [...]

By: James Urquhart

James Urquhart — Wed, 13 Feb 2008 01:05:09 +0000

One interesting aspect of writing more efficient code: its affect on utility computing pricing. If we will be charged for CPU cycles consumed, it seems that the most efficient software will be the cheapest software. In the cloud/utility computing world, green = cheap.

By: People Over Process » Can Code be Green? Does Beauty Matter?

People Over Process » Can Code be Green? Does Beauty Matter? — Tue, 12 Feb 2008 18:04:24 +0000

[...] an IBM green event, James asks: On that note I am beginning to wonder if beautiful code is green code. Code generation tends to [...]

By: Dave Johnson

Dave Johnson — Tue, 12 Feb 2008 17:36:58 +0000

Efficient code is good from the point of view of power into a server but if it takes the engineer longer to write green code then they may end up boiling more water for tea or purchasing more aluminum caffeinated beverage cans. Then it becomes a lifecycle assessment question I guess? However, if the engineer can take less time to write green code that sounds like a competitive advantage.

By: phil jones

phil jones — Tue, 12 Feb 2008 12:47:26 +0000

May not be so serendipitous, unfortunately.

There’s usually a trade-off between programmer work and computer work. With beautiful code pushing more of the effort to the computer.

A simple example, beautiful code is breaking your code into smaller functions for clarity and easier reuse. But more functions means more instructions executed. People really concerned about performance and minimizing computer instructions, unwind their programs into large repeated chunks rather than call functions.

Or take garbage collection, the computer has to do more work to clean up after the programmer who can forget about the memory she’s allocated.