Tools and Techniques for Solving Power and Performance Problems

September 9, 2014, Intel Developer Forum, San Francisco—Intel engineers explained and demonstrated some issues facing developers using iA-based mobile and embedded devices in their products. The use of specialized tools helps to identify and manage power and performance issues.

The primary tool they advocate is the Intel System Studio which can provide views of CPU, OS, memory, and software operations. the many variables usually require different tools for each operating system, so the ISS complements the other tools and plugs into the various integrated development environments and exports the hardware data for analysis.

For example, compiler optimizations may not get best efficiency from the components if the code and compiler are not in sync. The language semantics and code organization may not use all of the hardware capabilities, so data collection and hardware and software profiles can identify operating hot spots. Some data include CPU time per task, cycles per instruction, and provide the ability to drill down to the source code.

The code layout may hinder inter-procedural optimizations which will ignore global context for optimizations that are local to the process. The tradeoff is that global optimizations are harder to debug, so it is better to globally optimize on the final pass only. In-lining code helps to reduce calls and increases performance and helps with dead code elimination and copy propagation.

The concept of profiling the code on x86 and Android devices provides access to more data on the OS, BIOS, etc. to provide information on time in code, threading, and load balancing. The associated power profiles consider active versus idle states. Keeping awake locks and wakeups to a minimum helps performance, and may reduce total power. As a result, work to keep C states at maximal levels and P states should maximize at the lowest states.

Power and performance are affected by device drivers which may bury resource and power demands deep in the stack, so they are not easily observed on a normal trace or profile. The problem may be that the device driver calls for some operation on extended intervals and takes over many of the resources for the function. The ensuing interrupt and recovery add considerable overhead to the desired processes.