There are many blogs and articles on the internet that discuss analyzing an application to figure out ways to reduce power consumption. Finding where an application consumes power can be very challenging, especially with developers who are new to power optimization. In this blog I am going to talk about how to quickly determine, at a high level, if an applications power footprint can be reduced and how by optimizing the systems C States, Performance Optimization, Platform Timer Optimization, Interrupt Rate, and finally, Context Switching. Analyzing an application for power can differ from platform to platform. Here I will concentrate on mobile platforms such as Notebooks, Laptops, Ultrabook running the Microsoft* Windows operating system.
The basic rule of power saving is to allow the system to go the deepest C states as often as possible and as long as possible (more information on C states is explained in this Wikipedia article: http://en.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface). Microsoft suggests a power aware/conscious application should have a software percentage C3 state greater or equal to 99% when running idle. C-states, according to Microsoft definition, are states when the CPU has reduced or turned off selected functions resulting in less power consumed. Different processors support different numbers of C-states in which various parts of the CPU are turned off. To better understand the C-states that are supported and exposed, contact the CPU vendor. Generally, higher C-states turn off more parts of the CPU, which significantly reduce power consumption. Processors may have deeper C-states that are not exposed to the operating system.
Performance Optimization vs Power Optimization
In most cases, when an application is optimized for performance, it is also optimized for power. Let assume that an application, before optimizing for performance, takes 5 minutes to complete a task. After optimization, it finishes within 4.5 minutes. This means that, in general, running the optimized version of the application will save the system an estimate of 0.5 minutes, resulting in a reduction of power consumption. Of course depending on the nature of the application, reducing the running time does not always reduce power consumption.
The platform timer resolution is another counter that affects power consumption: by default, the value of the platform timer resolution on mobile systems is 15.6ms. Some multimedia applications like audio or video player software change this value to 1ms to ensure smoothness of the audio/video stream. Lowering this value to 1ms means the system will have to wake up every 1ms instead of every 15.6ms, thus preventing a processor from staying longer in a deep C state resulting in higher power consumption. The key here is to avoid changing the default value of the platform timer resolution unless it is absolutely necessary.
Besides the percentage C3 state and the platform timer resolution, the interrupt rate is the next important counter worth mentioning. Interrupt rate, according to Microsofts definition, is the average rate, in incidents per second, at which the processor received and serviced hardware interrupts. This value is an indirect indicator of the activity of devices that generate interrupts, such as the system clock, the mouse, disk drivers, data communication lines, network interface cards, and other peripheral devices. These devices normally interrupt the processor when they have completed a task or require attention. Normal thread execution is suspended. Similarly, reducing the interrupt rate will allow the system to stay in the deep C state longer resulting in saving power. From the application point of view, reducing the I/O activity will help reduce the interrupt rate. For example, instead of writing a small amount of data to a file many times, arrange data in big chunks and write to file less frequently.
Context Switching Rate
Context switching rate also plays an important role in affecting power consumption. It is the combined rate at which all processors on the computer are switched from one thread to another. Context switches occur when a running thread voluntarily relinquishes the processor, is preempted by a higher priority ready thread, or switches between user-mode and privileged (kernel) mode to use an Executive or subsystem service. A high rate of context switching means that the processor is being shared repeatedly. High context switching causes more overhead and prevents the system from going idle thus increasing power consumption. One way to reduce the context switching rate is to reduce the number of active threads in the system.
So far, I have discussed some of the most common pitfalls that would cause an application to consume more power. In my next blog will discuss how to use power tools like PowerCFG and Xperf to analyze applications to identify these pitfalls and root cause where they are prevalent in the application itself.