"Green" Code Development

Ultrabook™ is a new word in the mobile devices world. Slim design, lightweight, as powerful as a PC and as portable as a tablet. Consumers like Ultrabook for that, but for me, software developing is more interesting - how can I make my applications for Ultrabook more Ultrabook-friendly?

Ultrabook is a mobile device and, as every mobile device, it has a battery. Power efficiency is very important in the mobile world. Every user wants to use their device as long as possible without charging the battery.

Let's take a look on any mobile platform (smartphone, netbook or Ultrabook). Every platform has three main parts - battery, hardware, software.


The Battery is a power source for the mobile platform. Manufacturers of batteries and storage cells every year try to make batteries more capacitive.


The only power consumer in the system. Hardware consumes power to perform some tasks. Hardware vendors try to save battery life too, for example every new Intel CPU is more power effective.


Software is the main reason why we need mobile platforms. Software is not consuming power directly, but it works over hardware and uses hardware resources. And software developers have ways to save battery life. How? Let's see.
One of the important parts of hardware is the CPU. The CPU can manage self-power consumption with C-States. For those who are not familiar yet with C-States, I would like to show what C-States are in a short explanation and illustration.

C0 — active state.
C1 — idle state, but the unit is ready to go to active state with small latency.
C2 — like C1, but in this state the unit consumes less power and has a larger latency to go to the active state.
C3 — "sleep" state, in this state the unit clears L2 cache. Consumes less power but has a big latency.

This is not a complete list, CPUs have more states, but this is not so important for this article.
Here is a picture to illustrate states, power consumptions and latency:

As you can see, the most power-efficient state of CPU is always in "sleep". In this way, the most power-efficient application is an application that is not launched. This application does nothing and consumes nothing. But nobody needs those kinds of applications; every useful application should do something for the user. The compromise is - applications work only if the application really needs to do something, and if the application is doing something it does it as fast as possible.
This is very important for applications that do something in the background. These kind of applications should sleep as long as possible and awake only if there is something to do.

Event-driven software

Here is an example of "incorrect" code. This code reads data from the socket and passes it to some handler function.

// Read data
result = recv(serverSocket, buffer, bufferLen, 0);

// Handle data
if(result != 0)

// Sleep and repeat

What is wrong with this code? In any case, the socket has data to read or not, so the code is running. This affects CPU power consumption. Even if there is nothing to do, the code will wake up the CPU, and the CPU will consume power.
"Good" code will never wake up anyone, and will never ask every 1000 ms (or some other interval) if there is something to do. "Good" code will "sleep" until something interesting happens. Every OS has a mechanism for this, like synchronizing objects, events, and mutexes and so on. Let's rewrite the code using events. This code is incomplete, with no error handlings. This code is just to show the principles of event-driven software.

WSAEVENT wsaSocketEvent;
wsaSocketEvent = WSACreateEvent();

WSAEventSelect(serverSocket, wsaSocketEvent, FD_READ|FD_CLOSE);
// Wait until data will be available in the socket
WaitForSingleObject(wsaSocketEvent, INFINITE);

// Read data
result = recv(serverSocket, buffer, bufferLen, 0);

// Handle data
if(result != 0)

This code will "sleep" if there is nothing to do. No data in the socket - no activity.


Events are cool for development of power-efficient software, but in some cases we need to do something periodically. For example to play an animation or to play a sound / video.

Let’s talk about timers. The default timer resolution on Windows* 7 is 15.6 milliseconds. How does this affect applications? For example, you need your application do something every 40 ms. You set up your timer with a 40 ms interval. For the first 15.6 ms interval, it is too early to do something. For the second 31.2 ms interval, it is too early to do something. Your timer procedure will fire only after the third interval, after 46.8 ms. In most cases, an additional 6.8 ms does not matter.

This affects not only timer functions, but also the Sleep() function. For example, if you call Sleep(10), and have the Windows* timer resolution set to the default 15.6 ms, your code will "sleep" not for 10 ms, but for 15.6 ms.

This is not a problem in most cases, but can be a big problem for time-critical applications. For example, for a video player, this could be a problem since videos should play smooth. For applications that use animation, this could be a problem too. In some cases, the application could adjust the system timer resolution using the timeBeginPeriod() function from Windows* Multimedia API. This function allows you to reduce the timer resolution to as low as 1ms (to get the minimal available resolution, call the timeGetDevCaps() function). This is good for applications, but bad for the life time of the battery, and could reduce the life time of the battery as much as 25%.



How can we find a compromise? This is simple to describe, but not always simple to implement. Adjust the system timer resolution only if you really need a smaller resolution. For example, while a video or an animation is playing, restore the timer to default if the application is in an idle state, minimized, the lid is closed, or the display is turned off. Another good practice is to not change the timer resolution if the mobile device is using the battery, like in Opera* and Chrome* browsers.

From the user's perspective, to understand how to extend the life of the battery, use the Powercfg utility from Microsoft. Using this utility you will find power related problems, which drivers do not support power efficient modes, and you will see which applications adjust the system timer resolution.

Timers Coalescing

Windows* 7 brings a new feature for developers of power-efficient software called timers coalescing. Lets see an example picture of how it works.

Windows* groups timers to combine timer expirations with system timer interrupts.
A more detailed description can be found here.


Timer coalescing is the ability of the Windows* kernel to group multiple software timers from different applications and device drivers and expire them all at the same time. When you combine timer coalescing with the platform timer interrupt distribution improvements in Windows* 7, timer coalescing further helps increase the idle duration of the APs. This helps save processor and platform power by waking each AP only when it needs to perform the work for multiple software timers. After that work is complete, the processor returns to a low-power idle state for an extended period of time.


To use this feature you need to set up your timer with


BOOL WINAPI SetWaitableTimerEx(
__in HANDLE hTimer,
__in const LARGE_INTEGER *lpDueTime,
__in LONG lPeriod,
__in_opt PTIMERAPCROUTINE pfnCompletionRoutine,
__in_opt LPVOID lpArgToCompletionRoutine,
__in_opt PREASON_CONTEXT WakeContext,
__in ULONG TolerableDelay

Full description of this function can be found at MSDN.

If you want to know more about timers you can read Timers, Timer Resolution, and Development of Efficient Code.

Do This as Quickly as Possible

One more way to develop power-efficient software is to "teach" your application how to do things faster. You can do this by using hardware optimizations like SSE, AVX and others. Do you know that when using Quick Sync feature of the Sandy Bridge platform you can boost your code, and encode / decode video 10 times faster? Here is comparison chart, including Quick Sync, at Tom's Hardware.


After we make software optimizations, we need to understand how our optimizations affect power-efficiency.

1. Intel® Power Checker is a simple tool to evaluate the idle behavior of application.

2. Intel® Battery Life Analyzer

Intel® Battery Life Analyzer (Intel® BLA) is a tool that moniters various software and hardware activities that affect battery life. More complex, but a more informative tool.

3. Joulemeter from Microsoft*

Utility to measure power consumption of hardware parts.

Для получения подробной информации о возможностях оптимизации компилятора обратитесь к нашему Уведомлению об оптимизации.