Follow Best Practices for Creating Energy-efficient Client Device Applications

• Design applications that allow screens to darken and disks to idle by avoiding behaviors that unnecessarily prevent systems from remaining in a sleep state. Moving from sleep states to full activity states requires some energy, thus, develop algorithms to not keep waking idle processors unnecessarily.
• Where possible, eliminate code that keeps processors from transitioning to sleep states.
• Employ development frameworks that allow an app to be respectful of sleep status and resilient in handling nonessential workloads.
• To prevent users from disabling sleep, become more context aware, and take steps to ensure that systems don’t enter sleep states when users are passively interacting with them (e.g., watching or listening).
• Develop power-aware strategies for handling timers and looping. Investigate the use of compiler switches that unroll deterministic loops, and make other adjustments that reduce the overall number of instructions executed (e.g., remove polling).
• Use energy-aware tools to identify patterns of processor use in your apps.

Tools And Techniques for Evaluating and Optimizing Application Energy Consumption Performance

• Evaluate app productivity versus power consumption
• Instrument code to report specific metrics about operations performed, timings, and collateral conditions
• Generate large performance data sets using a variety of execution regimes
• Evaluate the power consumption impacts of alternative libraries, drivers, and frameworks
• Validate optimizations and remediation
• Instrument apps in ways that allow customers and third-party testers to certify apps as energy efficient

• With threading
• Called from Java*
• Called from C#
• Called from Objective-C
• With Linux system information utilities
• CPU use histogram generator tools
• Cluster energy efficiency
• PL sampling measurements

Mobile Device Battery Life Conservation

• Replace timer-based designs with event-driven or interrupt-driven logic.
• Avoid using timers as a high-resolution time source. If there is no workable alternative, ensure that timer resolution is reset to the system default when it is not actively engaged in its specific task.
• Apps designed to provide passive display of content should explicitly increase display dimming timeout to accommodate playback using power request or availability APIs. The requests should be explicitly rescinded when the app is minimized or inactive.
• Screen savers and the like should not alter dimming timeouts. Unless there is an aesthetic reason for them, screen savers do nothing to maintain the health of LCD monitors and are simply wasting energy. Let screens dim, if practical.

Conclusion

Helpful Links and Additional information on Power Management Tools and Resources

• Software development information from Climate Savers Computing*
• Intel® Energy Checker SDK and user guide
• Learn more about The Green Grid*
• Microsoft Power Management Functions* reference
• Red Hat Linux 6 Power Management Guide*
• Power Management for Linux*
• Fine-Grained Energy Profiling for Power-Aware Application Design: http://research.microsoft.com/apps/pubs/default.aspx?id=73662*
• Intel white paper: “Energy Efficient Platforms—Considerations for Application Software and Services” (http://www.intel.com/content/www/us/en/green-it/energy-efficiency/energy-efficient-platforms-2011-white-paper.html?wapkw=considerations+for+application+software+and+services)
• BLA requests, questions, and feedback: BatteryLifeAnalyzer@intel.com

About the Author

The Intel Power Checker 2.0 now supports measurement both on battery and with the system plugged into an external AC power source. External power measurement is only supported on Intel® Second Generation Core processors and if the Intel® Power Gadget software has been installed.

For this article, I took a very compute-intensive parallel application that I wrote to solve instances of the logic puzzle Akari. The code uses a backtracking algorithm to explore how to place light bulbs onto a grid under constraints dictated by the rules of the puzzle and the layout of the puzzle instance. Potentially millions of independent tasks can be generated by the code as the solution space is searched by threads executing those tasks. This solution method is eminently scalable to a large number of threads and is able to keep many cores running at peak speed for a sustained amount of time.

How to Use Intel Power Checker

The Intel Power Checker provides a GUI wizard that leads you through the four steps of power analysis. These four steps in the checker are described below. Before starting the assessment, be sure to know which section of your application (a workload) you want to be measured, as the Power Checker will only measure a 30 second execution interval. (If you want to measure the entire execution workload, you should try some other tool, like Intel Power Gadget.) Your workload could be a compute-intensive portion or an I/O-intense section or just some point in execution that typifies the majority of expected usage.

Step 1: Specifying the Power Meter device

If you have an external power meter attached to your test system, you can select the model being used on the first screen of the wizard. The default is that no external device is being used. For this default case, Intel Power Checker will determine if the system is capable of providing power consumption data and if the correct power driver, EzPwr.sys, is installed. (The driver is part of the default installation of Intel Power Gadget.)

Step 2: Measure System Baseline

The first measurement that the Intel Power Checker will perform is on the next screen within the wizard. This is to measure the baseline power consumption of the hardware without your application running. Prior to this measurement phase any unnecessary processes such as operating system updates, Windows Indexing Service, virus scans, media players, and internet browsers should have been shut down. In other words, to get the most accurate results you should make your test system as idle as possible and ensure that nothing will become a foreground process during your measurement runs.

Once you have a quiescent system, click the “Start” button to begin this phase of the testing. The Intel Power Checker waits 15 seconds to allow the system to come to an idle state before starting the measurements. You need to be sure to position your mouse and the keyboard out of reach, or keep your hands away from them, to avoid any stray contact that might trigger some response from the platform. After the pause, the checker will observe the system for 30 seconds in this idle state. A progress bar will show the time remaining in each part of this phase. Once the baseline data collection is complete, click the “Next” button to proceed to the next phase.

Step 3: Measure Active Application

Before you are taken to the next screen in the wizard, you are instructed to start the application you are interested in measuring. Start up your application and click the “OK” button to advance the GUI to the next screen. Once you have reached the Step 3 screen, use the scroll bar to locate your application in the process list and click on that line to select it. If your application is not listed, click the “Refresh List” button so that your application’s process will be available to select. In addition, you can use the “Apply Filter” button to narrow down the list in order to find your application’s process quickly. .After selecting your application from the list, click “Next” to move on to the data collection for this phase. Before starting the assessment, be sure your application has reached the desired point of measurement. If there are some initial setup computations that are not of interest, you will need to get past this point before letting Intel Power Checker begin measurement. For my Akari application, there is very little setup time. It was typically in the thick of computation by the time I had gotten to the point of selecting the process from the list.

As soon as I could, I clicked the “Start” button to begin capturing measurement data. Since this is one of the crucial power measurements for your application, always begin capturing data after the workload or critical section has begun and make sure this active execution will run longer than the 30 seconds needed to complete the measurement time.

Step 4: Measure Idle Application

The final phase is to measure your application’s idle power consumption. This is another important phase of energy efficiency measurement of an application since your application must not only do efficient computation, but also not waste energy when sitting idle.

This step doesn’t make much sense within my compute-intensive application since there is no idle state of the application. Once you start the application on a given puzzle instance, it simply computes all legal solutions in parallel and then ends. As (multiple) solutions are found, they are printed out by the thread that found it. If there are no solutions, a message is printed just before the application terminates. This latter case describes the workload I used for my tests. Because you must have your application running in “idle” mode for this step, I left the application running at full speed and simply allowed Power Checker to take its measurements.

If your application does have an idle state, perhaps waiting for interaction from the user, the checker will give the system 15 seconds to calm down fully before taking a final 30 second measurement.

Upon completion of this last data collection phase, you will be able to proceed to the results screen within the Intel Power Checker wizard. After all three measurement phases have been completed; a Tool Report File will be generated containing all of the results for later analysis.

What data is presented

The View Results screen of the Intel Power Checker wizard provides basic information about the software assessment. The type of processor in your system and the type and model of the power source that was used are given. Four numerical values for each of the three measurement phases are presented. These values are:

• Elapsed Time: The exact number of seconds that each of the phases lasted.
• Energy Consumption: The rate that the battery was discharged during each of the three phases.
• Average C3 State Residency: The percentage of time that the system was in the C3 state during the data collection period.
• Platform Timer Period: The number of milliseconds that the platform timer collected

Typical results would hopefully show a larger percentage of time spent in the C3 State Residency for the application idle time measurement (the middle of the three columns on the View Results screen). As my puzzle solving application was still computing as much as it did in the active execution measurement step, this was not the case for my results. This is atypical for the intended type of applications Intel Power Checker assumes will be measured. Thus, the C3 State Residency values provided by the tool for the idle application were not valid for my particular application.

The name of the report file and the directory to which it will be found are listed on the View Results screen.

Some Caveats

Below are some things you should consider before and during a measurement run using Intel Power Checker.

• Before you start using Intel Power Checker, be sure your chosen workload will run for at least 30 seconds from the point you wish to measure power consumption. In my case, I required a data set that would force the application to run for at least 75 seconds (30 for active measurement, 15 for idle setup, and 30 for idle measurement) plus the time I needed to click boxes and find my application in the process list. Since I ran the application on several different numbers of threads, I needed to be sure that the fastest execution time was still large enough to get all the timings steps completed during a Intel Power Checker run.
• Upon starting Intel Power Checker, the checker may first report that the platform timer period is invalid. In this case, some currently running (background) process has changed the default and it will be up to the user to determine which currently running application has changed the value. Once you have identified the culprit you must stop this process or service before restarting Intel Power Checker. If you are unsure about which active process is preventing Intel Power Checker from starting, you will need to turn off processes one at a time and try Intel Power Checker until the error message doesn’t come up.
• Instructions on the Step 3 screen ask you not to touch the keyboard or mouse. If you are measuring an interactive application or you must interact with the application to generate activity for the full 30 seconds, you will need to touch the keyboard and/or mouse. If possible, a workload that can forego interactivity and still compute for the 30 seconds of measurement time would be best. However, if interaction by the user is part of how the application is utilized, interfacing through peripherals will give you a more accurate measure of the overall energy consumption for typical application usage.
• A data file is created during each phase of the Intel Power Checker assessment to hold the current information. If you cancel the assessment in any of the three phases then a data file will not be created for that phase. After all three phases have been completed, a Tool Report File, in XML format, will be generated containing all of the results. You can find the name of the report file and where it is located on the View Results screen.
• The “Submit Results” button on the View Results screen is optional and only intended for members of the Intel® Software Partner Program to submit their measurement results to the program. If you are not a member, do not submit your results. Simply click on the “Close” button after you have examined the results compiled by Intel Power Checker.

Some Results

The purpose of this article is not to determine the best scenario for running my Akari solver application in the most energy efficient way. You will want to do this for your application, though, and this article has given you the background on Intel Power Checker to determine if this checker can help you quantify the current power consumption of your application. Also, as you make modifications to the application you will be able to determine if those changes improve the energy efficiency or cause your application to suck more power than before.

In addition to the average C3 State Residency percentage, the checker delivers the total number of Joules expended during the 30 seconds of execution time measured. From this I can compute the average Watts for execution parts of the application. I have found that a better metric for comparing different applications or different runs of the same application is milliwatt hours (mWh). You need the total execution time of the execution portion of the application to compute this value. Since Intel Power Checker only measures activity in 30 second segments, you will need to have some timing data available, which I happened to have for the different runs I made of my Akari application.

I found significant differences when running with and without Hyper-Threading Technology (HT) turned on. Also, if the platform was running on battery (DC) power or from the wall socket (AC) power, a difference in execution time and power usage was evident. For example, when running with HT on and a full complement of four threads on the 4 logical cores in my system, I saw the AC power run 1.19X faster that when running the same workload on DC power. However, the former run took 1.15X more power.

Comparing results between runs on DC power versus AC power is a not a good comparison, especially in this case. The power source is detected by the system and the processor is allowed to run with Intel® Turbo Boost Technology at a higher frequency if the platform is using external power. Even so, you may need to be concerned about power consumption of your application in both power source circumstances and you will need to run measurement experiments within each setup to gauge how well your application modifications affect overall power consumption.

System Requirements

You can use Intel Power Checker on a laptop or netbook based on Intel® Core™ processor or Intel® Atom™ processor technology. A desktop with an external power meter or a desktop that is capable of providing the power consumption information can also be analyzed. A Java* Runtime Environment (JRE) (version 6 update 11 or higher) is also required to run the checker. Supported operating systems are Microsoft Windows* XP (Service Pack 3), Microsoft Windows Vista* (Service Pack 2), Microsoft Windows* 7 (Service Pack 1 [32-bit and 64-bit]), and Microsoft Windows* Server 2008 R2.

Download link

To download the Intel Power Checker installation package, go to the following link:

http://software.intel.com/partner/app/software-assessment/. Click on the Intel Power Checker tab to move down to the download link.

Other supporting links

There is a video demonstration of using Intel Power Checker, “A Look at Intel Power Checker,” at the link: http://software.intel.com/en-us/videos/channel/intel-software-partner-program/a-look-at-the-intel-power-checker/1127786023001. Dave Valdovinos and Taylor Kidd, both from Intel, show off the GUI wizard as it measures the power performance of a game-like application.

More Work, Less Power

Energy Efficency

EE=Work/Energy

Code Instrumentation

Energy Consumed

1. Use a power meter to collect actual “platform energy and power” information.
   
   There are several different power meters that work with the Intel Energy Checker SDK. Please consult the Intel® Energy Checker SDK User Guide included in the download or found on the Intel® Energy Checker SDK page to determine which power meters will work and how they should be attached to the test system.
   
2. Use Intel® Power Gadget to collect “processor energy and power” usage information on 2nd Generation Intel Core™ processor family. External power meters can also be used which report platform power together with Intel Power Gadget that provides processor power.The blog Accessing Intel® Power Gadget From Intel® Energy Checker SDK by Intel engineer Jun De Vega discusses how to enable Intel® Power Gadget with Intel® Energy Checker.
   
3. Choose to use the simulation method which will use the CPU utilization percentage returned from the OS. This method does not require a hardware probe. The Intel Energy Checker SDK offers this method as an option for all processors (rather than just the 2nd Generation Intel Core processor family as with the Intel Power Gadget) in order for enable the user who does not have a power meter. Included in the SDK is a support library for accessing this metric.

Figure 1: Conceptualized drawing of Intel Energy Checker setup with Instrumented Application, Power Meter and Environmental probes attached

Intel Energy Checker Extras

Figure 2: PL GUI Monitor running while a picture is being rendered

Optimizing Applications for Ultrabooks

Summary

About the Author

For the purposes of this article - when I refer to Intel Inspector XE - I am referring to the memory error analysis within Intel Inspector XE and/or Intel Parallel Inspector

Useful Settings for memory error analysis in Intel® Inspector XE:

Settings which impact memory error analysis in Intel Inspector XE:

Settings not recommended for use with memory error analysis in Intel® Inspector XE:

Settings which have no impact on memory error analysis of Intel Inspector XE:

Notes:
1) Memory Error Analysis Level 1 (Memory Leak Detection) requires information in the executable and all shared libs in your application to properly walk the call stack:

a) Frame pointers: Use -fno-omit-frame-pointer.

b) Exception handling information: enabled via -fasynchronous-unwind-tables, -fexceptions, or -O0

2) Using Debug versions of the Microsoft C Runtime Libraries (/MDd and /MTd) enables the Microsoft* debug heap manager. see: Using the Microsoft* debug heap manager with memory error analysis of Intel® Parallel Inspector.

Note: There are other options which may add frame pointer or Exception handling to your binary as a side effect, Examples: -fexceptions (which is the default for C++).or -O0 . To make sure the executable (and shared libs) have this information, use the objdump -h <binary> command. You should see .eh_frame_hdr section there.

More Information:

This article addressed the most obvious switches that developers would have concerns over. Most switches will work with Intel® Parallel Inspector and/or Intel Inspector XE - but not every switch combination is tested. If you have information regarding other switches, please add a comment to this article. If you have question regarding a particular switch please submit an issue to the Intel Inspector XE Forum.

Versions:
Intel® Inspector XE 2011
Intel® C++ Compiler 11.X,12.X
GCC Compiler 3.4.6 – GCC 4.5.0
MS Visual Studio 2005, 2008, 2010

The Intel^® Thread Profiler feature of VTune™ Performance Analyzer for Windows* offers a powerful browser to examine data collected during instrumented runs of application code but unfortunately it only runs in the Microsoft Windows* environment.  However, the "Enabling collector for Linux*" enables users to do native data collection of their applications on their Linux machine and view those results on a Windows machine. This article describes the process.

Tools Needed:

• Intel VTune Performance Analyzer 9.1 for Windows* which includes
  • Intel Thread Profiler for Windows*
  • Enabling collector for Linux* (tprofile_cl - which you get by installing  Tprofile3.1_XXXrdc_lin.tar.gz)

This collector is available in the VTune Peformance Analyzer product download area on http://registrationcenter.intel.com

• Intel^® Compiler for Linux* (optional)

For information on purchasing or evaluating these products please visit http://www.intel.com/software/products.

Binary Instrumentation:

What: Use for most IA-32 and Intel^® 64 architecure based POSIX*, Intel^® Threading Building Blocks, and OpenMP*^§ Applications.

How:

1)     Setup the Intel Thread Profiler Environment for IA-32 architecture by executing:

# source /opt/intel/itt/tprofile/bin/32/tprofilevars.sh

or for Intel 64 architecture:

# source /opt/intel/itt/tprofile/bin/32e/tprofilevars.sh

depending on your environment.

2)     Run the application using the Intel Thread Profiler Command Line 

# tprofile_cl myapp

3)     Copy^† the newly created results directory(default = threadprofiler) containing the .tp files back to the Windows system.

a.      Optional: Copy^† the binaries(including any .so files) and source to the windows system

4)     Open^† (File:Open) bistro.tp in Intel Thread Profiler for Windows.  If your application creates multiple processes... there will be a tprofile.pid.tp file for each process created by the main process.  You will have to open up the tprofile.pid.tp for the process you want to analyze.

^§ Binary Instrumention for Intel Thread Profiler works better with the OpenMP* Compatibilty Libraries (dynamic version: libiomp5.so or libguide40.so) available via an Intel Compiler. This library has been instrumented for Intel Thread Profiler with the User-Level Synchronization API's. This library is used by default with the Intel Compiler, and can be used with an OpenMP* GCC* compiled application. If a 3rd party OpenMP* library is used, Thread Profiler can still collect data, but Intel Thread Profiler will not comprehend the OpenMP calls - it will be analyzed as a POSIX* application.

Note: The OpenMP* compatibility library in Intel^® C++ and Fortran Compilers 11.1 Update 1 (11.1.046) through 11.1 Update 3 (11.1.059) does not work with Intel Thread Profiler. You need an OpenMP library from either an earlier version or the OpenMP library which ships with Intel C++ and Fortran Compilers 11.1 Update 4 (11.1.061) and later.

Source Instrumentation:

What: Use for POSIX* applications when Binary Instrumentation is not practical (Servers for example) - or on Intel^® Itanium^® architecture systems.

How:

1)     Setup the Intel Thread Profiler Environment for IA-32 architecture by executing either:

# source /opt/intel/itt/tprofile/bin/32/tprofilevars.sh

or for Intel 64 architecture:

# source /opt/intel/itt/tprofile/bin/32e/tprofilevars.sh

depending on your environment.

2)     Compile the Application with the Intel^® Compiler using the switch:

-tprofile

3)     Run the Binary

4)     Copy^† the generated .tp file and the .tpd file to the Windows* system.

5)     Copy^† the binaries (including any .so files)

a.      Optional: Copy the source to the Windows* system

6)     Open^† (File:Open) .tp in Intel Thread Profiler for Windows*

OpenMP*-Specific:

What: This mode is specific to OpenMP* applications.

How:

1)     Compile the application with an Intel Compiler using the switch:

-openmp_profile

2)     Run the application

3)     Copy^† the generated guide.gvs file back to the Windows* system

a.      Optional: Copy^† the binaries(including any .so files) and source to the Windows* system

4)     Open^† (File:Open) guide.gvs in Intel Thread Profiler for Windows*. When it loads the data it will ask you the MHz of the system.  Enter the MHz of the Linux* system on which you ran the binary.

^† Cross Mounting the Windows* system to the Linux* system is another perhaps easier way to copy/access files to the Windows* system.

Useful Compiler Settings for Intel Thread Profiler:

Switch	Purpose
-g (highly recommended)	Intel Thread Profiler uses the symbols to associate addresses to source lines.
"Release" Build (-O2)    (highly recommended)	The time to execute a section of code may change if you don't use your normal production switches (Not -O0).  Potentially causing you to analyze and attempt optimization on a section of code that is not a performance problem.
-tprofile (optional)	Use this setting to do Source Instrumentation.  Note: Only the Intel Compiler supports this setting

Useful Settings for OpenMP* Applications compiled with the Intel Compiler for Intel Thread Profiler:

Switch	Purpose
-openmp (required)	Use this setting if you are using Binary instrumentation analysis
-openmp_profile (optional)	Use this setting if you are using OpenMP Specific Analysis

Useful Setting for applications using Intel Threading Building Blocks for Intel Thread Profiler:

Switch	Purpose
-D "TBB_USE_THREADING_TOOLS" (highly recommended)	This setting adds the User-Level Synchronization API's allowing Intel Thread Profiler to properly identify Intel Threading Building Blocks.