Assault on Batteries with the Intent to Perform

by Richard Winterton


How you use your laptop has a dramatic effect on the battery. See what a curious Intel engineer discovered while writing this paper.

It has been a continuing challenge to get higher performance for a minimum amount of power, but until someone can change the fundamental laws of physics, performance and power will be opposing forces. This paper presents data obtained from the Google Desktop Search “Performance-Power Plug-in*” and sample code available at the Performance Power Management Forum to show how a platform approach may be taken to find ways to improve the performance per watt ratio of some applications.

A Different Approach
There are usually several ways to approach a technical problem: from the bottom up or from the top down. For example, Intel is working on a new dielectric used on transistors to speed up transistor switching time and reduce leakage current. This will improve performance and decrease power. This is an example of a bottom up approach. Another approach Intel is taking is to look at what can be done at the platform level, which is looking at the problem from the top down. This paper explains a top down approach of optimizing applications for performance per watt.


As an engineer, one of the first things I do when optimizing hardware or software is take a measurement or a “benchmark” of where you are so that you have something to compare to as you change your design. In fact, applications should be more interested in the big picture: how much power is the “system” using at a specific time. If you can obtain information about a system and measure its performance repeatedly, you now have a “benchmark.” You can then make changes to the system and easily measure the effects of the changes. After all, the end goal is to improve the user’s experience, both in terms of performance as well as being mobile for longer periods of time.

Benchmarking and measurements may be considered an uninteresting subject; however, they are essential to improving performance. There has to be a measurement taken to improve something. That measurement should be something useful and meaningful. It also has to be repeatable to measure differences when changes are made to the system. One example is the effect of how the system is used and battery drain rate. The reason I picked battery drain is because that is what is important to the end user: “How long can I continue to work?” “How does what I am doing affect how long I can work?” These are really the big picture questions for the end user. Another example: I am on battery power and listening to music as I write this paper. If I discover that I will not be able to finish the paper with the battery time I have left, I need to make a decision. Either turn off the music and lower the power consumption, or make the article shorter. To the chagrin of some of you reading this article, I chose to discontinue the music. Before I refer you to the code on how I measured the performance and battery drain I will show you results I found rather interesting.


Workloads come in several types, and two that come immediately to mind are statistical and “real life” workloads. Both have their place, but usually “real life” benchmarks are the most meaningful to the average user. I took a collection of MP3s and WMAs, burned a data CD containing a mixture of both encoded formats, and played them on the CDROM on my laptop. The reasons I decided to do this are two fold-one of which has nothing to do with this paper. I just got tired of listening to the same songs over and over on a regular CD, which is probably true for a lot of users. Second, the audio player, in this case Microsoft’s Media Player*, needs to read the CDROM and use more CPU resources to decode the content. Although the decoder is not CPU intensive, it keeps it operating at around 14% CPU utilization while I listen to the music and write the paper. Before I get too far ahead of myself let’s set up a baseline of my test situation:

  • Writing a paper using Microsoft Word*
  • Not listening to music
  • Running the laptop on battery
  • Using a remote screen connected via a docking station.


As illustrated in the graph below, I have a steady state of 13 watts battery drain rate.

Google Plug-in Battery Drain Rate Graph
Writing a paper, with a docking station, no music


Just as a point of interest, I decided to change the screen over from the remote CRT to the laptop LCD still running on battery. As shown in the graph below, it significantly changed the drain rate from 13 watts to 18 watts, just by using the laptop display. Not really a surprise, but the five watts is significant.

Google Plug-in Battery Drain Rate Graph
Writing a paper without a docking station, no music


The Tests Continue

Then I decided to run the test while listening to non-cached music. Switching from the docking station to the LCD display AND playing music made the drain rate jump significantly to a steady state of about 23 watts. I could hear the CD continually spinning while I was listening to the music.

Google Plug-in Battery Drain Rate Graph
Writing a paper without a docking station, listening to non-cached music


Now this is what I found to be really interesting. After a period of writing and listening to music, the drain rate was up from 23 watts steady state, to varying from 25 to 28 watts. This was caused by Media Player set to play the songs in a random order. Since the files were being cached, I could hear the CD spin up and down. This resulted in a less steady state drain rate varying from 28 Watts to 25 Watts. It makes complete sense in allowing the CDROM to spin down, but only if the duration of time it is stopped saves more energy than it takes to spin it up and down. To paraphrase another law of physics: once an object is in motion it is easier to keep it in motion than to spin it up and down.

Google Plug-in Battery Drain Rate Graph
Writing a paper without a docking station, listening to partially-cached music


This statement is true until the duration of time that the CDROM is stopped takes less energy than it takes to spin it up. This is apparent for two reasons: I noticed that the CDROM had stopped spinning for a significant amount of time, and second, it was obvious that the songs were being cached from the battery drain rate graph. As shown in the graph below, the drain rate dropped to 21 watts and remained at a steady state.

Google Plug-in Battery Drain Rate Graph
Writing a paper without a docking station, listening to cached music


These graphs show that what I did and how I used the system has a significant impact on the battery drain rate. Just in this simple example of writing a paper and listening to music, I saw drain rates range from 13 watts to 28 watts depending on what the application was doing and how I used the system. If 13 watts and 28 watts were held at a steady state between the two extremes, the result is a difference of over twice the battery life. Obviously this isn’t going to happen since I saw in the graphs that the drain rate does vary. The important thing to realize is that I was measuring the effects at a system level.

Taking the measurements was really simple and helpful in determining what was going at a system level. Performance in this case wasn’t just the CPU, but other factors came into play. CPU utilization (decoding the MP3 and WMA files) was just a small part of the overall power usage in this case. Effective use of the CDROM and LCD were critical components at the system level to improve the overall user experience. It is obvious to me from this example that Intel’s emphasis on the platform level is the right move if we want to make the user experience better. As you can see, understanding specific characteristics of the system helps the application make decisions to operate in a more performance per watt “friendly” manner. Getting the information is fairly simple. Deciding how to interpret the data is a little more difficult.

Battery Charge/Drain Rates

Battery charge/drain rates vary depending on the system, the battery technology, and battery age, and what is going on when you are measuring the rates. The graphs shown previously are taken from a Google Desktop* plug-in that is available from Google Desktop Web site. Parts of the source code used in the plug-in, such as determining the battery drain rate, is available from the Intel® Digital Content Management Forum Web site in the Simple Examples message thread ( The simple solution in the file contains information on how to understand what is going on at the platform level. This solution contains the source code on how the plug-in gets the battery charge/drain rate used in the Google plug-in. The BatteryInfo.h file and BatteryInfo.cpp file include the following five functions:

  1. void biUpdateBatteryDriverInfo(BATTERYINFO_T *bi, int nBatteries);
  2. void biFastUpdateBatteryDriverInfo(BATTERYINFO_T *bi, int nBatteries);
  3. int biGetBatteryCountAndOpenInfo(BATTERYINFO_T *bi, int nBatteries);
  4. void biCloseBatteryInfo(BATTERYINFO_T *bi, int nBatteries);
  5. int biGetTimeRemainingAtRate(int BatteryIndex, LONG AtRate);


Using these five function calls along with information about the CPU utilization and correlating time to functionality make it easy to see how to optimize this use case for performance per watt.

In Summary

This paper provides a real life use case to highlight a platform approach to optimizing applications with performance per watt in mind, and also provided two specific opportunities for enhancement:

  • Media Players reading data from the CDROM need to be optimized to rip and cache data to reduce battery drain rate. If the files are not cached and not accessed in an optimized manner, the battery drain rate is significantly increased.
  • If the user decides battery life is critical, and all that is being done is writing a paper and looking at the black and white text on the screen, the LCD intensity level may not be as important. Turning down the intensity of the display will significantly lower the battery drain rate.


More important is the big picture that this approach exposes. It is critical to have a platform perspective when optimizing applications for performance per watt. The most important feature for the end user is providing a platform that gives the user the experience they want. Can I use a PC in the living room without the noise of the fan ruining the experience? Can I take my laptop anywhere and do the things I want to do? Can I write a paper on how to optimize software for a better platform experience and listen to music without the battery running out before I am fin...

Additional Resources


Community Forum


Developer Center


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