January/February 2013 (Vol. 15, No. 1) pp. 19-27
1520-9202/13/$31.00 © 2013 IEEE

Published by the IEEE Computer Society
Enabling Green IT through Energy-Aware Software
Manuj Sabharwal , Intel

Abhishek Agrawal , Intel

Grace Metri , Wayne State University
  Article Contents  
  Energy-Saving Software Techniques  
  Energy-Aware Software Case Studies  
Download Citation
Download Content
PDFs Require Adobe Acrobat

Software behavior can significantly affect computer energy efficiency in everything from small devices up to servers in data centers. However, there are multiple techniques that software developers can use to reduce the energy consumption of drivers and applications.

Software behavior can significantly affect computer energy efficiency, on everything from small devices up to servers in data centers. There are multiple techniques that software developers can use to reduce the energy consumption of both active and idle drivers and applications. The article discusses software power optimization case studies to demonstrate software energy-efficiency principles. This article is part of a special issue on green IT.

Green IT infrastructure is incomplete without energy-aware software. 1 Software plays an important role in overall platform energy efficiency. Although platform hardware designers work diligently to reduce the power consumption of components, one ill-behaving, power unfriendly software component on the system can thwart any power-management benefits built into the hardware.
A computing platform is a combination of hardware, software, and other technologies that allow the software to run. The energy-saving techniques we describe here apply to all types of platforms—embedded platforms, smartphones, tablets, netbooks, notebooks, desktops, data center servers, and even supercomputers. All of these devices run software, which requires energy, so the energy efficiency of the platform is extremely important.
In the smartphone world, most users find it intolerable if a device requires recharging after less than a full day's use. Notebook computer manufacturers are still striving for the elusive all-day PC, although some of the thinner and lighter models are getting close to offering all-day use without recharging. A big concern for data centers is the cost of the electricity required to run the servers and air conditioning units to keep the room and servers cool.
Although most of a platform's energy-saving features are transparent to the software developer, and applications have very little direct control of such features, the software's behavior can greatly influence the effectiveness of any energy-saving features built into the platform.
Energy-Saving Software Techniques
Well-behaved software lets the energy-saving features work. Poorly behaved software inhibits energy-saving features, leading to a shorter battery life and higher energy costs. Here, we cover some general software energy-optimization techniques.
Computational Efficiency
The effort that computer scientists put into software performance saves not only time but also energy. We call this the race to idle. The faster we can complete the workload and get the computer back to idle, the more energy we can save. Using efficient algorithms, multithreading, and vectorization can help improve performance.

Efficient algorithms. Algorithms and data structures are a long-standing research area in computer science. The choice of algorithms and data structures can make a vast difference in application performance. For a particular problem, a stack might be better than a queue, and a B-tree might be better than a binary tree or hash function. The best algorithm or data structure to use depends on many factors, and a study of the problem and careful consideration of the architecture, design, algorithms, and data structures can lead to an application that delivers better performance with less power.

Multithreading. Multithreading the software delivers better performance and is more energy efficient. To illustrate this, we used a performance-benchmarking application—Maxon's Cinebench 11.5 ( www.maxon.net/en/products/cinebench)—and measured the energy consumed on a 4-core, 8-thread Intel processor.

Figure 1 shows the CPU energy use over time using one, two, four, and eight threads. As you can see, completing the workload with a single thread takes considerably longer and uses more energy than any of the multithreaded runs. In fact, the eight-thread case (normalized) uses about 25 percent less energy than the single-threaded case. The added advantage is that the eight-thread run was completed in about one-fourth the time, and the processor is available for other computation.

Figure 1. CPU energy measurements from various runs of the Cincebench 11.5 on an Intel Core i7 system. Completing the workload with a single thread takes considerably longer and uses more energy than any of the multithreaded runs.

Vectorization. Another method to improve computational efficiency is vectorizing the code instead of using scalar code, using advanced instructions such as Single-Instruction Multiple Data for instruction-level data parallelism. If you can vectorize your solution, you'll get better performance and a corresponding power benefit.

To test this, we took two different audio decode algorithms and optimized them using an Intel Advance Vector Extensions (Intel AVX) instruction set. Using a method we have for turning the AVX feature on and off, we measured both the performance and average power of an audio decode workload. When AVX is enabled, the workloads run considerably faster—1.65 and 1.34 times faster, with a huge savings in power (see Table 1 ).

Table 1. Performance and power impact of Advance Vector Extensions (AVX) instructions.

Data Efficiency
Data efficiency reduces energy costs by minimizing data movement. It can be achieved by designing

    • software algorithms that minimize data movement,

    • memory hierarchies that keep data close to processing elements, or

    • application software that efficiently uses cache memories. 2

Here, we present some examples of applying data-efficiency methods to save energy.

Managing disk I/O. We analyzed hard disk power characteristics while performing various activities and developed some guidelines for optimizing power during disk I/O. Detailed information about our analysis, including sample code, appears elsewhere. 3

We based the analysis on the typical performance characteristics of hard disk drives, which are affected by revolutions per minutes, seek time, rotational latency, and the sustainable transfer rate. Furthermore, the actual system throughput depends on the data's physical location on the drive.

Table 2 summarizes the results of our four separate experiments.

Table 2. Energy usage of hard disk drives using various I/O methodologies.

Prefetching and caching. We also conducted a study to determine if prefetching and caching can save energy during DVD playback. 4 We analyzed the power consumption of three different DVD playback software applications with different out-of-the-box configurations—primarily, using the maximum power-saving mode versus no power-saving mode. The workload used for the analysis was a standard definition DVD movie that was included with the MobileMark 2005 benchmarking tool ( www.bapco.com).

Our experiments showed that DVD drive spin-up was the most power hungry activity (requiring over 4 W for a brief period), so reducing spin-up can lead to energy savings. Continuous DVD reads consumed approximately 2.5 W of power and is another area for potential savings. Table 3 shows the measured energy usage for the three DVD playback applications.

Table 3. Energy consumed during DVD playback.

From the results, three guidelines emerge that can help save energy during DVD playback. First, buffering—implemented by the first DVD application—reduced DVD power consumption by 70 percent. Second, it helps to minimize DVD drive use—reducing DVD spin-ups, spin-downs, and read accesses saves energy. Finally, it's best to let the operating system manage the CPU frequency. We don't recommend changing the CPU power scheme to run the processor at the highest available frequency. Instead, let the operating system set the appropriate P-state, adjusting the CPU frequency as needed.

Context Awareness
Humans naturally use context to understand the world, makes decisions, and adapt to the environment. Context awareness in computers means that they can sense the environment in which they're operating, and software can be designed to react to changes in the environment.
Context awareness was first introduced by Bill Schilit in 1994. 5 The objective is to create applications that can respond or adapt to changes in the environment. For the physical environment, this requires sensors and the ability to generate events or state changes to which the applications can react. Some examples of context-aware behavior are when a notebook PC responds to a change from AC to DC power by automatically dimming the display, or when it quickly parks the hard drive heads when sensors detect that the device is falling—to avoid a head crash. Embedded systems are particularly context-aware because, in many cases, they're designed specifically to monitor and react to environmental conditions from sensor data. The use of sensors is growing rapidly in smartphones and tablets and includes light sensors, gyros, accelerometers, GPS receivers, and near-field communications.
Context awareness makes our devices "smarter," and the behavior of applications can be passive or active. A passive response to a context change would be to ask the user what action to take ("Switch to power-saving mode?") or acknowledge that a state change has occurred ("You have 10 percent battery left. Okay?"). An active response would be to take action automatically, either as a built-in feature (dim the display in a dark room) or as a user-configurable option (skip full-system virus scan when using the battery). Software applications can take advantage of context awareness to save energy, as the following two examples show.

AC or DC? Does it benefit an application to know whether a notebook PC is plugged into an AC power source or operating on battery? In many cases, the answer is yes. In Windows, you can achieve this by querying a unique globally unique identifier (GUID) called GUID_ACDC_POWER_SOURCE. 6 Armed with this information, you can adapt the application's behavior and possibly extend the battery life for the current usage.

Platform power policies. Microsoft Windows provides built-in power policies— high performance, balanced, and power saver. It gives the system user the option to choose between better performance or a longer battery life. Application software can use power polices in the following ways: adjust application behavior based on the user's current power policy, change application behavior in response to a change in power policy, or change the power policy to suit the application behavior. Once again, Windows system GUIDs are available to implement these behaviors. 7
Energy-Aware Software Case Studies
Here, we present multiple case studies on real-world applications to show what issues lead to energy inefficiencies, how to diagnose them, and how to apply the energy-efficient software methodologies we've discussed to optimize applications.
Experimental Setup
Setting up the environment is important when measuring how battery life affects software on IT platforms. We divided the platform testing into two phases: phase 1 used a clean operating system (OS), while phase 2 used an OS with an application installed.
To establish a baseline battery life for the OS and minimum additional device usage, you must first eliminate certain overhead effects in the power measurements by changing several settings for a newly installed Windows:
First, disable automatic updates and scheduled events (such as system restore) and the display idle timeout: 8
C:\>powercfg -setdcvalueindex SCHEME_CURRENT SUB_VIDEO VIDEOIDLE 0C:\>powercfg -setactive SCHEME_CURRENT

Then disable the sleep idle timeout:
C:\>powercfg -setdcvalueindex SCHEME_CURRENT SUB_SLEEP STANDBYIDLE 0C:\>powercfg -setactive SCHEME_CURRENT

Next, disable the screen saver, system restore, and UAC elevation prompts:
reg.exe ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion \Policies\System /v EnableLUA /t REG_DWORD /d 0 /f

You'll also need to force idle background tasks to execute:
Rundll32.exe advapi32.dll,ProcessIdleTasks

When called from the command line, the ProcessIdleTasks work occurs asynchronously in the background and can take 10 to 15 minutes to complete. The task manager reports which processes are running, and the disk is likely active during this time.
Finally, you must ensure that search indexing is enabled, which is the Windows default.
After collecting the estimated battery life for the idle clean OS, you can move to the next phase of capturing the battery life with applications installed. We implemented the experiment using two case studies.
Windows IT Build
We compared the battery life of the Windows 7 Enterprise build to that of the Windows 7 traditional IT build. IT build refers to traditional software apps loaded with security. We performed the test using an Intel laptop with a 2nd generation Core processor and a fully changed battery capacity of 65.360 mWh.
For each Windows version (Windows 7 Enterprise clean install and Windows 7 Intel IT build), we ran the battery drain test by

    • creating a baseline system configuration for our testing using a Windows 7 Enterprise clean installation;

    • configuring the power and operating system settings for testing (as discussed earlier);

    • running the battery tests;

    • installing an IT clean build;

    • running the battery drain test, which involved fully charging the battery for 6 to 8 hours, turning on the system and waiting for it to be idle (this took 15 minutes), removing the plug, and recording the how long it took for the battery to fully drain;

    • running the battery drain test after installing the security software; and

    • analyzing the results.

Figure 2 shows the battery drain test for differ-ent builds and packages. The Windows 7 vanilla build had a battery life of 5 hours, 24 minutes (324 minutes), the Windows 7 IT build had a battery life of 4 hours, 10 minutes (250 minutes), and the Windows 7 IT build excluding security software had a battery life of 4 hours, 22 minutes (262 minutes). So, running security applications on the IT build degrades the battery life by approximately 19 percent, compared to a degradation of only 5 percent without these applications.

Figure 2. Battery drain test results for the Windows 7 clean build versus the IT build on an IT-managed laptop. Battery life degrades approximately 19 percent on the IT build when running security applications, compared to only 5 percent when Windows 7 IT build runs without these applications.

Application and System Idle
To evaluate software behavior on Ultrabook devices, we measured how the battery life affects an application when running idle on a 2nd generation Intel Core i7 mobile processor with a clean version of a Windows OS.
Figure 3 illustrates the impact of various idle applications on the platform's battery life (each application was run individually). Browser 4, for example, decreased the total platform's battery life by approximately 200 minutes when idle with no user input for at least 30 minutes. Chat 3, on the other hand, decreased the battery life by approximately 180 minutes when just running in the background. Combined, running these applications when idle significantly affected the battery life.

Figure 3. How idle applications running on a clear version of Windows can affect battery life. Browser 4, for example, decreases the total platform's battery life by approximately 200 minutes, when idle with no user input for minimum 30 minutes. Chat 3, on the other hand, decreases the battery life by approximately 180 minutes when just running in the background.

Figure 4 compares a clean copy of Windows running with no applications installed and all of the Figure 3 applications open and running in the background. If a clean copy of Windows idle maintains 100 percent of the battery life, running applications at idle can decrease the battery life by 38.2 percent, which is significant—especially if the applications are running idle and without any user activity. IT staff that rushes to a prebuild software stack must consider evaluating the software to ensure its impact on battery life is minimal.

Figure 4. Battery-life usage comparison. Running applications at idle can decrease the battery life by 38.2 percent.

A big question for developers is how to measure and reach the optimum amount idle application time during development. The Battery Life Analyzer (BLA) is a power-management analysis tool developed by Intel to identify issues that affect battery life. 9 BLA helps identify a wide range of issues during software analysis, such as software CPU use, OS timer resolution changes, frequent C state transitions, excessive Interrupt Service Routine (ISR)/Deferred Procedure Calls (DPC) activity, and graphics vertical blank interrupt updates.
We selected a media player application (from those in Figure 3 ) to optimize for maximum battery life (that is, a clean OS installation). We then used BLA and Windows Performance Analyzer (WPA) 12 to analyze the performance.

Analysis using BLA. We profiled the application using BLA for 120 seconds. Figure 5 shows how the C-state affects media software when idle. There's a significant decrease in C7-state package residency when the application is open and idle (that is, not playing a movie or music). The drop in C7-state package residency is due to the increase in C0–C1, C2, and C6-state package residency. The application—even when idle—was performing CPU and network activity, which led to an increase in package C0 and C2 state residency.

Figure 5. Playback application C-state residency analysis. C7-state package residency decreases significantly when the application is open and idle.

Further examining the increase in C0 and C2 state package residencies, we used the BLA software analysis tool to determine if any one process had an especially significant impact. Table 4 shows the calls-per-second activities when the software was idle. The "hal.dll" process, which is associated with OS tick activity, experienced a huge increase in calls when the timer tick changed to 1 millisecond (causing 1,000 calls per second), down from the OS default of 15.6 msec (64 calls per second). The change in the timer tick rate not only affects CPU power use but also increases other components' power use, such as memory and uncores power. Overriding the timer tick rate reduced battery life by 20 percent.

Table 4. Results from the Battery Life Analyzer for idle software.

Analysis using WPA. BLA provided good, high-level information about the software and C-state behavior, which can help developers find issues that cause degradation in battery life during software development. To explore how individual API calls affected power, we used WPA, which is packaged in the Windows Assessment Development Kit. 10 We profiled the playback application in an idle state using the Windows Performance Recorder installed with WPA. We did a system-wide collection for 180 seconds and also enabled symbol decoding, which can be turned on from the menu (Trace Tab, Load Symbols) or by adding the following variable to the Windows Environment Variables:
_NT_SYMBOL_PATH: srv*c:\symbols*http://msdl.microsoft.com/download/symbols;

Using WPA shows that the playback application, even when idle, used between 0.5 and 2 percent of the CPU, and system processes used 2 percent of the CPU. For an idle application, system CPU use should be less than 1 percent to avoid increasing the C0-state package residency—which was already high in this particular media player application.

To understand why the application had so many wake-ups, which caused the high C0 residency, we analyzed the stack walk for the wake-up events. WPA showed calls for WaitForSingleObject every (approximately) 2.4 msec, causing a ring 0 transition. Calling WaitForSingleObject with a small time-out is as damaging to battery life as a call to Sleep with 1 msec. The application-thread context switches out after 2.5 msecs, causing a timeout from the WaitForSingleObject. To avoid this, the application can increase the time-out period to infinite and wait for any job to be called. Changing the timer tick activity and removing WaitForSingleObject significantly improved the battery life (see Table 5 ).

Table 5. Battery life changes for the media application.

The world is moving toward green technologies, and consumers are increasingly demanding a longer battery life in their mobile devices. The demand for higher performance and new usage models will also continue to grow. Energy efficiency will be crucial for the computing industry in the future, both to increase battery life for mobile platforms and reduce energy expenses for desktop and server platforms.
Modern processors and platforms have many energy-saving features, and software should work in harmony with these features. Developers must exploit performance features by emphasizing computational efficiency and being frugal with data movement to improve data efficiency. They should also implement intelligent application behaviors by exploiting context awareness and seriously considering the effect of idle software.
Some of the experiments and data summarized in this article are based on years of experimentation and research conducted by Intel engineers. We acknowledge the tireless efforts and contributions of Bob Steigerwald, Rajshree Chabukswar, Jun De Vega, Karthik Krishnan, Tareq Darwish, and Jamel Tayeb.


Manuj Sabharwal is a software engineer in the Software Solutions Group at Intel. His research interests include exploring power enhancement opportunities for idle and active software workloads. He also works on enabling client platforms through software optimization techniques. Contact him at manuj.r.sabharwal@intel.com.
Abhishek Agrawal is a senior technical lead in the Software Services Group at Intel, and he leads software power enabling for Intel's clients and Intel Atom-based platforms. He chairs the industry-wide power management working group for Climate Savers Computing Initiative. He's a member of IEEE and ACM. Contact him at abhishek.r.agrawal@intel.com.
Grace Metri is a PhD candidate at Wayne State University and a software engineer intern in the Software and Services Group at Intel. Her research interests include power-aware computing, the energy-efficiency of mobile devices, and energy-efficiency within the cloud. Metri received her MS in computer science from Wayne State University. She's a member of IEEE and ACM. Contact her at gmetri@wayne.edu.
[%= name %]
[%= createDate %]
[%= comment %]
Share this:
Please login to enter a comment:

Computing Now Blogs
Business Intelligence
by Ray Major
Cloud Computing
A Cloud Blog: by Irena Bojanova
The Clear Cloud: by STC Cloud Computing
Enterprise Solutions
Enterprise Thinking: by Josh Greenbaum
Healthcare Technologies
The Doctor Is In: Dr. Keith W. Vrbicky
Hot Topics
NealNotes: by Neal Leavitt
Industry Trends
Internet Of Things
prpl Matters: by Art Swift
Mobile Computing
Shay Going Mobile: by Shay Shmeltzer
NGN-Insights: by Martin Nuss and Uday Mudoi
No Batteries Required: by Ray Kahn
Software Technologies: by Christof Ebert