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

> psexec -i 0 amplxe-cl.exe -c=hotspots -r \path\for\your\result_dir --target-pid=PID

5. Run your workload
6. Detach VTune Amplifier XE from the service:

> psexec -i 0 amplxe-cl.exe -command detach -r \path\for\your\result_dir

7. Open the collected results in VTune Amplifier XE GUI

Steps to profile Windows service in GUI mode
1. Configure analyzed service to run with permissions of current user
2. Run <amplifier_xe_install_dir>/amplxe-vars.bat to configure VTune Amplifier XE environment
3. Get PID of analyzed service
4. Start the Interactive Services service:

> net start UI0Detect

5. Start VTune Amplifier XE GUI (from command line):

> psexec -i 0 amplxe-gui.exe

6. You will get a blinking task bar icon. Click on that icon and an interactive Services Detection dialog box will pop up. Choose "View the message", that will make Windows change to session 0, which normally does not have any UI elements. But in this session 0 you should see the VTune Amplifier XE GUI, and another dialog box that you can use to get back to your normal logon session.

7. Attach to the services process and use the VTune Amplifier XE GUI as you are used to.

8. After you are done profiling, you can analyze the results in that session. Or close the VTune Amplifier XE GUI and click "Return now" in the dialog box. Then you can reopen the VTune Amplifier XE results in the normal logon session.

9. Stop the Interactive Services service:

> net stop UI0Detect

Some other hints to profiling in session 0
• You can always go back and forth between session 0 and your normal logon session by selecting the "View the message" and "Return now" buttons in the Interactive services dialog boxes.

• Note that other users on the same machine might see the Interactive Services Detection window as well. Make sure they know about this, so they leave the dialog box alone.

• You can run VTune Amplifier XE as a different user than the service process. For this use "-u" parameter of psexec to specify the user under which the service is running. You will be prompted to type the password for the account:

> psexec -u mydomain\myaccount -h -i 0 amplxe-gui.exe

 
*Other names and brands may be claimed as the property of others.

Developing and validating embedded software stack stability and peripheral device interfaces for System-on-Chip (SoC) designs gets ever more challenging. Driving factor is the increased level of device integration and need of timely and synchronized messaging.  Additionally driving this is a fragmented and specialized software and operating system ecosystem, as well as increased time-to-market pressure. In this article we will examine how software tools can help developer productivity by using specialized development and validation technologies. Furthermore we will examine key development, analysis and debug use cases as required with most common types of embedded Intel architecture platforms.

Introduction

Over the past several years we have seen the traditional embedded market segment experience a transformation from fixed function and isolated embedded systems to a new category of intelligent systems. The transformation is changing the way people engage with and experience computing. Implications from this shift are that devices are more capable and interact with each other and these usage models demand greater performance, an increasingly capable cloud of services, and software technology and tools that support these new classes of devices. These devices are secure, connected and managed. Several industry analyst firms such as IDC* and others are seeing this shift and have created a new embedded sub-category called "Intelligent Systems". The increased usage of system-on-chip (SoC) designs in traditional embedded market segments as well as the new category of Intelligent Systems requires the developer as well as tools vendor a like to reassess the entire development process from design, code generation and debug to system performance analysis.

When developing the system software stack for embedded devices you are frequently confronted with the question how to set up the most appropriate development environment first. It helps to understand the options for approaching software development targeting embedded systems. In this article we will focus on SoC designs using an application processor based on x86 or Intel architecture. The target application processor architecture being similar to the architecture of the system most likely used by the developer for his or her development work has some unique advantages and widens the choices available.

These choices range from traditional native development of applications on the development host for later deployment on a target device to full blown traditional embedded cross development using a QEMU* based virtual machine, a remote debug connection to a physical target device and a sysroot or chroot based build environment. We will attempt in this article to shed some light on each of these options for Intel® Atom^TM Processor targeted designs.

One of the most commonly used operating system for Intel architecture based embedded systems is a customized flavor of Linux*. These may range from something based mainstream Linux* distributions to custom builds from scratch. Linux distributions specialized on embedded and mobile computing applications like Wind River* Linux*, Yocto Project*, or Android*, are playing a more and more prominent role. Frequently embedded designs have a real-time requirement for at least parts of the software stack. This implies that isolating those components of the software stack that have this requirement and ensuring that they do have only minimal dependencies on the non real-time part of the software stack becomes one key challenge of developing and defining embedded systems software.

Furthermore, when talking about SoCs, understanding the interaction between all the platform components becomes vitally important. You may be developing device drivers that take advantage of special GPU features or use micro-engines and other hardware accelerators found on the platform. You may be designing the software interface for the many wireless radios found in today's small form factor devices. In either scenario, being able to analyze the message timing - making sure the variable values that are exchanged between the different platform components contain the right value at the right time, becomes important for platform software stack stability. Being able to access device configuration registers easily and in a comprehensive manner also simplifies developing device drivers and controlling platform component interaction timings.

To ensure this, the following exhaustive steps are enforced by Intel Cluster Checker test modules:

1. · Check that base libraries and their uniformity (base_libraries)
2. · Check that MPI tools have consistent paths (mpi_consistency)
3. · Check that per-node MPI jobs can do Hello World independently (intel_mpi_rt)
4. · Check that a global Hello World is successfully executed across compute nodes (intel_mpi_rt_internode)
5. · Runs Intel MPI Benchmarks such as Ping Pong to check available latency and bandwidth (imb_pingpong_intel_mpi)
6. · Stress the communication system by running the HPCC benchmark (hpcc)

If the tool reports something, then an MPI application might have issues to complete their work.

These steps will even catch potential timeouts due wrong configuration on the network stack; and most important, bad cabling or down hardware interfaces. However, if the cluster uses InfiniBand adapters then there is a known issue to be aware of. The global MPI check can hang as any other MPI application will do if InfiniBand is not correctly configured and online.

Intel(R) MPI Library Runtime Environment (All nodes), (intel_mpi_rt_internode, 1.8.....................................................^C

Caught signal INT, cleaning before termination.

With InfiniBand setups, the configuration of Intel Cluster Checker must define openib and dat_conf as dependencies of intel_mpi_rt_internode. This action will ensure that the InfiniBand devices are properly detected and healthy. openib check hardware devices, and dat_conf the DAPL software interface.

<intel_mpi_rt_internode>

<add_dependency>dat_conf</add_dependency>

<add_dependency>openib</add_dependency>

</intel_mpi_rt_internode>

This decision cannot be done automatically as choosing were to use or not the low latency, high bandwidth capabilities of InfiniBand during the check is at discretion of the user. For instance, the administrator may want to double check that an Ethernet fabric can be properly used to run MPI applications.

Be aware that this manual requirement may be lifted in the near future.

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

In the case of legacy projects, ask the developers to submit new code only if they reduce the number of findings.
In the case of coding from scratch, allow no findings before uploading new code in your repository.

When enabling the check (-diag-enable sc3) and compiling the code, a new folder will be created where the findings will be stored using a custom XML format.

$ file rXsc/data.X/rXsc.pdr
rXsc/data.X/rXsc.pdr: XML document text

$ xml sel -t -m /diags/diag -v "concat(message/thread/stacktrace/loc/file, ':', message/thread/stacktrace/loc/line, ':', sc_verbose)" -n rXsc/data.0/rXsc.pdr
/home/$USER/work/$PROD/src/pool.c:157:pool.c(157): warning #12178: this value of "ret" isn't used in the program
/home/$USER/work/$PROD/src/pool.c:186:pool.c(186): error #12192: unreachable statement
/home/$USER/work/$PROD/src/pool.c:216:pool.c(216): warning #12135: procedure "pool_done" is never caled

>/opt/intel/vtune_amplifier_xe_2011/bin64/amplxe-cl -collect hotspots -r test1 – my_test_exe
Warning: Symbol file is not found. The call stack passing through the module [vdso] may be incorrect
Using result path `/home/vtsymbal/test1
Executing actions 75 % Generating a report                                     
Summary
-------
Elapsed Time:  6.354
CPU Time:      6.210
Executing actions 100 % done
 

>ldd -d my_test_exe
        linux-vdso.so.1 =>  (0x00002aaaaaac6000)
        libtbb.so.2 => /opt/intel/tbb/tbb40_233oss/lib/libtbb.so.2 (0x00002aaaaabc7000)
        libstdc++.so.6 => /usr/intel/pkgs/gcc/4.5.2/lib64/libstdc++.so.6 (0x00002aaaaadf5000)
        libm.so.6 => /lib64/libm.so.6 (0x00002aaaab117000)
        libgcc_s.so.1 => /usr/intel/pkgs/gcc/4.5.2/lib64/libgcc_s.so.1 (0x00002aaaab26c000)
        libc.so.6 => /lib64/libc.so.6 (0x00002aaaab481000)
        librt.so.1 => /lib64/librt.so.1 (0x00002aaaab6c2000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00002aaaab7cb000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00002aaaab8cf000)
        /lib64/ld-linux-x86-64.so.2 (0x00002aaaaaaab000)
 

The information in the table below is composed from the "Intel® Processor Identification and the CPUID Instruction" and the official Intel® product information source.

For identifying a particular processor, please use the Intel® Processor Identification Utility for Microsoft® Windows^TM operating systems or the bootable version for other operating systems[2].

Notes

• The -EP suffix denotes a Dual Processor, meaning this processor is designed to operate in a Dual Processor platform (but can still operate in a Single Processor platform). The -EX suffix denotes a Multi-Processor (MP), meaning this processor is designed to operate in a Multiprocessor platform, but can still operate in a Single or Dual processor platform configuration.
• The Family number is an 8-bit number derived from the processor signature by adding the Extended Family number (bits 27:20) and the Family number (bits 11:8). See section 5.1.2.2 of the "Intel Processor Identification and the CPUID Instruction".
• The Model number is an 8 bit number derived from the processor signature by shifting the Extended Model number (bits 19:16) 4 bits to the left and adding the Model number (bits 7:4) . See section 5.1.2.2 of the "Intel Processor Identification and the CPUID Instruction".