Microsoft has a blog on "How Much Does Your Code Cost?", interjecting humor into a typically dry topic.

The big difference is that with cloud computing, you’re renting computing power in a data center somewhere. As far as you’re concerned, it could be on Saturn. Except that the latency figures might be a bit excessive. If you’ve accidentally opened one of those magazines your network administrator takes with him to the bathroom, you might know that these data centers contain racks and racks of servers, all with lots of twinkling lights. If you’ve ever been to a data center, you’ll know that they can be very hot near the server fans, much colder around the cooling vents, and noisy everywhere. All this activity results from removing the heat that the servers produce. But that heat doesn’t get there all by itself – the servers create it from the electricity they use. What’s more, it requires even more electricity to remove that heat.

Consider sending this post on to those who are involved in SW decisions to get them thinking of the impact of their SW code.

When you’re up against deadlines to turn in a software project, you probably are focused on ensuring that you meet the functionality requirements set out in the design specification. If you have enough time, you might consider trying to maximize performance. You might also try to document your code thoroughly so that anyone taking over the project doesn’t need to run Windows for Telepaths to work out what your subroutines actually do. But there is probably one area that you don’t consider: the cost of your code.

You mean what it costs to write the code, right? No.

Er, how about what it costs to compile? You’re getting warmer...

What it costs to support? No, colder again.

OK, you win. What costs do you mean?

I mean what it costs to run your code. In the bad old days, when clouds were just white fluffy things in the sky and all applications ran on real hardware in a server room somewhere or on users’ PCs, then cost simply wasn’t a factor. Sure, you might generate more costs if your application needed beefier hardware to run, but that came out of the cable-pluggers’ capital budget, and we all know that computer hardware needs changing every other year, so the bean-counters didn’t twig. A survey by Avanade showed that 50% of IT departments don’t even budget for the cost of electricity to run their IT systems. For more information, see this Avanade News Release, at http://www.avanade.com/_uploaded/pdf/pressrelease/globalenergyfindingsrelease541750.pdf

Life would be so much easier in the data center if SW developers and others thought of the data center infrastructure costs direct relationship to the code they write and how it is architected.

The good thing is cloud computing is helping to get SW developers to think about the costs to run their code.

If you deploy applications into the cloud, it is highly likely that your service provider will be charging you based on the energy that you use. Although you don’t see electricity itemized as kw/hr, you are billed for CPU, RAM, storage and network resources, all of which consume electricity. The more powerful processor with more memory costs more, not just because the cost of the components, but because they consume more electricity. In many ways, this is an excellent business model, as you don’t have to buy the hardware, maintain it, depreciate it, and finally, replace it. You simply pay for what you use. Or putting it another way, you pay for the resources you use. And this is the point at which you need to ask yourself: How much does my code cost? When power usage directly affects the cost of running your applications, a power-efficient program is more likely to be a profitable one.

The blog post references Visual Studio and Intel resources to help SW developers.

It is possible that future versions of Visual Studio will include options for checking your code for power usage. Until that time, following these recommendations should help minimize the running costs of your applications within a cloud-based environment.

Reduce or eliminate accesses to the hard disk. Use buffering or batch up I/O requests.

Do not use timers and polling to check for process completion. Each time the application polls, it wakes up the processor. Use event triggering to notify completion of a process instead.

Make intelligent use of multiple threads to reduce computation times, but do not generate threads that the application cannot use effectively.

With multiple threads, ensure the threads are balanced and one is not taking all the resources.

Monitor carefully for memory leaks and free up unused memory.

Use additional tools to identify and profile power usage.

For more ideas on how to reduce the memory, check out the following resources and tools:

Energy-Efficient Software Checklist, at http://software.intel.com/en-us/articles/energy-efficient-software-checklist/.

Creating Energy-Efficient Software, at http://software.intel.com/en-us/articles/creating-energy-efficient-software-part-1/.

Intel PowerInformer, at http://software.intel.com/en-us/articles/intel-powerinformer/.

Application Energy Toolkit, at http://software.intel.com/en-us/articles/application-energy-toolkit/.