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

The application ‘ffmpeg’ consist of three executables and 5 libraries. All the sources can be downloaded using the following svn command:

Ø      svn checkout svn://svn.ffmpeg.org/ffmpeg/trunk ffmpeg

 Required patch

One version which I tried ( download: svn checkout svn://svn.ffmpeg.org/ffmpeg/trunk ffmpeg –r 17944)

has a known problem with the sources. If you try to build the code, then you will get a compile time error:

 libswscale/swscale.c:488: error: ‘PIX_FMT_YUV420PLE’ undeclared

The solution is solved by copying the contents of the libswscale directory from .   http://www.ffmpeg.org/releases/ffmpeg-0.5.tar.bz2    (see http://www.ffmpeg.org/download.html)

Please Note, only the libswscale directory should be copied over the top of the existing files.

Build Instructions

Following instructions will help you build ffmpeg under a Linux system assuming that the tar ball from the download is copied to <install_directory>:

 Ø      cd  <install_directory>

 Ø      cd tar xvfz  ffmpeg.tar.gz   #Extract the tar ball to your local directory. You will find a directory tree under the name ffmpeg installed. All the required sources are installed within this tree provided that you are not enabling any additional third party libraries.

 Ø      cd ffmpeg

 Ø      ./configure –help <cr> # to show all the options available to rebuild ffmpeg. For a reference build with gcc there is no need to provide any parameters to configure. However if you would like to enable any third party libraries like ‘libfaad’, ‘libx264’ etc. then you need to add --enable-libfaad --enable-libx264 etc. as parameters to configure. If this is required make sure that you have these sources available on your development environment and that the third party libraries are rebuilt with the selected compiler / compiler options.

 Ø      ./configure <parameters as below>

 Ø      make <cr> #recommended sequence is ‘make clean’ followed by ‘make’. The rebuild will take several minutes (depending on your development environment). Two versions of each executable are produced: ex. ‘ffmpeg’ and ‘ffmpeg_g’. The ‘*_g’ contains the executable with debug information while the ‘*’ is the stripped version. In addition ‘ffplay, ffplay_g, ffserver and ffserver_g’ are produced as executables and libavutil, libavcodec, libavformat, libavdevice and libswscale are rebuilt.

 Icc build:

Depending on what version of icc you are using different configure parameters may be necessary.

 Using icc v10.1.xxx:

 Ø      ./configure cc=icc --extra-cflags=”-xL –O3” --extra-libs=-lsvml <cr> # Without linking in the extra library (libsvml.so) you get several references unresolved.

 Using icc v11.0.xxx:

 Ø      ./configure cc=icc –extra-cflags=”-xSSE3_ATOM –O3” –extra-libs=-lsvml <cr> #  The option –xSSE3_ATOM do require that you run the code on a processor which does support the ‘movbe’ instruction. If you would like to test the code on a processor not supporting the ‘movbe’ instruction you can add the option ‘-minstruction=nomovbe’ in the extra-cflag part of the command line above.
Ø      Make sure that the LD (linker) options do not contain ‘–march=generic’ in the config.mak file. This option causes an error from the compiler.

Using icc v11.1.xxx:

Ø      To avoid a run time erratum following source change is needed:   Open file ./libavcodec/x86/dsputil_mmx.c and on line #2944 insert // before || __ICC > 1100. The line is highlighted below.

Ø      After the change it will look like: #if ARCH_X86_64 || ! ( __ICC) // || __ICC > 1100

Ø      ./configure cc=icc –extra-cflags=”-xSSE3_ATOM –O3” <cr> # This simple configure does work but you get better performance if you also add the ‘--extra-lib=-lsvml’. Additional compiler switches can be used to improve the performance – for example ‘-no-prec-div’, ‘-vec-‘. As the no-prec-div has an effect on the fp calculations please refer to the compiler documentation before it is used. In addition the ‘-xSSE3_ATOM’ switch are no longer requiring a processor with ‘movbe’ support.

 Cross compilation.

It is standard practice to build the library and executables on a development machine and then copy the resultant files to the MOBLIN target.  You can use the option --enable–cross-compile in this case.

Once you have completed the configure stage you can just run the ‘make clean’ followed by ‘make’. You could expect additional warnings produced.

Building ffmpeg with third party libraries:

The application can support 21 different external 3^rd party libraries. Each of those are selected in the configure process by adding the option ‘--enable-<library-name>’.

Below is an example of using some of the different external libraries available:

 Ø      ./configure <other options as above> --enable-libfaac --enable-libfaad --enable-libmp3lame --enable-libtheora --enable-libx264 --enable-libxvid 

The invocation above assumes that you will be using 6 external 3^rd party libraries:

 - libfaac       # for example you can download ‘faac-1.28.tar.gz’ or later version from the web.

 - libfaad       # for example you can download ‘faad2-2.7.tar.gz’ or later version from the web.

 - libmp3lame # for example you can download ‘lame-398-2.tar.gz’ or later version from the web.

 - libtheora    # for example you can download ‘libtheora-1.0.tar.tar’ or later version from the web. Please note that you can not use ICC v 10.1 to rebuild this library due to a compiler issue. This has been fixed with 11.1 version of the compiler.

 - libx264      # for example you can download ‘x264-snapshot-20090117-2245.tar.bz2’ or later version from the web.

 - libxvid      # for example you can download ‘xvidcore-1.2.1.tar.gz’ or later version from the web.

Performance Notes: 

Best option combination for ICC: “-xSSE3_ATOM –O3 –vec- -static –no-prec-div –ansi_alias”. Also make sure you add –extra-libs=-lsvml in your configure invocation.

Two ways of improving the performance of ffmpeg:

1) Use the external 3rd party libraries which are supported – 20+ are available. They are optimized for their specific field. You need to select the suitable library – download the code and build them using the ICC.

2) Use PGO. Here it is important to produce a set of .dyn files for the most common conversion you will be using. The code size improves a bit and the performance also gets a boost provided that you use any of the conversions for which you generated a .dyn file. If you select a totally different conversion you actually could get a slower performance compared to both gcc and icc (general optimized version). For those who are not familiar with the PGO optimization this is a three step procedure:

a. Add the option –prof-gen to the extra-cflags section for the configure generation. Build ffmpeg.

b. Run the resulting binary on your target. Make sure you use representative input files and output formats. You may want to repeat this process several times. For each run you will have a .dyn file generated on the target. Copy these files over to your development system.

c. Now use the options –prof-use and –prof-dir <directory path where you have the .dyn files which you copied in step b> [make sure to remove –prof-gen option]. Generate a new make file with configure and build your ffmpeg. You may see a number of warnings ‘missing .dpi information for <file name.’ This is information only and can be ignored. The finally generated ffmpeg should be both smaller and faster.

Optimization Notice

Intel's compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include SSE2, SSE3, and SSSE3 instruction sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors. Certain optimizations not specific to Intel microarchitecture are reserved for Intel microprocessors. Please refer to the applicable product User and Reference Guides for more information regarding the specific instruction sets covered by this notice. Notice revision #20110804

Introduction

Build environment

The build instructions below are based on the assumption that the build environment is a Fedora10 installation. 

A copy of the installation disks can be found here. http://fedoraproject.org/get-fedora

It is important that the GCC tools are installed when the Fedora installation is installed.

Cross-development

The clutter libraries  and test environment  are first built on a Fedora installation, and then the resultant executables and libraries can then be copied over to a MOBLIN2 platform.

Virtualisation

The steps below can be undertaken on a virtual machine, the only restriction being that not all virtual machines support video acceleration  

The tests

There are a number of tests that can be used to benchmark the clutter library. The benchmark performance is measured by how many Frames Per Second (FPS) are achieved.

Building the Clutter Libraries

Downloading the sources

The sources for the clutter library can be obtained by using the following command.

In a development directory of your choosing download the sources

   git clone git://git.clutter-project.org/clutter

   git clone git://git.clutter-project.org/clutter-box2d

Progress for each download should be reported similar the following:

$ git clone git://git.clutter-project.org/clutter

Initialized empty Git repository in /home/intel/dv/clutter/clutter/.git/
remote: Counting objects: 25225, done.
remote: Compressing objects: 100% (10261/10261), done.
remote: Total 25225 (delta 20575), reused 18319 (delta 14944)
Receiving objects: 100% (25225/25225), 6.99 MiB | 104 KiB/s, done.
Resolving deltas: 100% (20575/20575), done.

Building the Sources

Directory structure should look similar to this:

             <dev-dir>/clutter/
            <dev-dir>/clutter-box2d

In each of these sub directories build the libraries as follows:

Choosing which compiler

Building with GCC

For our installation, we'll use the environment variable  $PREFIX custom directory so as not to override any existing installation

     export PREFIX=/opt/custom/gcc
    ./autogen.sh --prefix=$PREFIX

Building with ICC

To build the library with the Intel compiler use the following commands

    export CC=icc
    export CXX=icc

   export PREFIX=/opt/custom/icc
  ./autogen.sh --prefix=$PREFIX

Continuing the build

When autogen has completed you should get a message similar to the display below 

  
                                  Clutter    0.9.7
                         ====================
                                  prefix:   /opt/custom/gcc
                                Flavour:   glx/gl
                                 XInput:   no
                          GL headers:   GL/gl.h
                    Image backend:   gdk-pixbuf
                       Target library:   libclutter-glx-0.9.la
               Clutter debug level:   yes
                 COGL debug level:   minimum
                      Compiler flags:   -Wall -Wshadow -Wcast-align -Wno-uninitialized -Wno-strict-aliasing -Wempty-body -Wformat-security -Winit-self
        Build API documentation:   no
  Build manual documentation:   no
         Build introspection data:   auto

Now build the source by calling make

The progress of the make will be reported, the last few lines looking similar to this:

   Making all in tools
     CC    disable-npots.o
     LINK  libdisable-npots-static.la
     LINK  libdisable-npots.la
   Making all in po

Installing the new library

To install the new library call:

make install

Note, depending on the permissions of the installation directory (set with the $PREFIX variable in the previous steps) you may need to do this as root.

Building the tests

The test directory has a number of tests. The README describes the tests as follows 

"The conform/ tests should be non-interactive unit-tests that verify a single feature is behaving as documented. See conform/ADDING_NEW_TESTS for more details.

 The micro-bench/ tests should be focused performance test, ideally testing a single metric. Please never forget that these tests are synthetic and if you are using them then you understand what metric is being tested. They probably don't reflect any real world application loads and the intention is that you use these tests once you have already determined the crux of your problem and need focused feedback that your changes are indeed improving matters. There is no exit status requirements for these tests, but they should give clear feedback as to their performance. If the frame rate is the feedback metric, then the test should forcibly enable FPS debugging.

 The interactive/ tests are any tests who's  status can not be determined without a user looking at some visual output, or providing some manual input etc. This covers most of the original Clutter tests. Ideally some of these tests will be migrated into the conformance/ directory so they can be used in automated nightly tests."

To build the tests, from the top level of the test directory do: 

    make

The build will report:

    Making all in data
    Making all in conform
    Making all in interactive
    Making all in micro-bench
    Making all in tools

Running the tests

Having built the tests, each test can be run from the command line.

Automatic running of  tests.

Many of the tests do not run to completion, but keep running,  The script in the appendix below gives an example of how the tests can be automatically called and killed after a predefined time.

Appendix 1 -  Script to drive test cases

#!/usr/bin/perl
# list of tests TODO: EDIT THESE TO YOUR REQUIREMENTS
@Tests=("test-actors", "test-behave", "test-clip","test-cogl-offscreen","test-cogl-primitives","test-cogl-tex-convert","test-cogl-tex-foreign","test-cogl-tex-getset","test-cogl-tex-polygontest","test-cogl-tex-tile","test-depth","test-layout","test-multistage","test-pixmap","test-project","test-random-text","test-rotate","test-scale","test-script","test-sharder","test-text","test-texture-quality","test-textures","test-threads","test-unproject","test-viewport");

#@Tests=("test-actors", "test-behave");
@Results=();

# for each test run it for 10 seconds
my $Timeout = 10;
## chdir interactive;
my $bStarted = 0;

foreach my $Test (@Tests)
{
    # print "executing $Test\n ";
    eval {
        local $SIG{ALRM} = sub { die "alarm\n" }; # NB: \n required
        alarm $Timeout;
        # system("./$Test --clutter-show-fps > res.$Test.txt");

        # mark end of prev test
        push @Results, "END" if $bStarted;
        push @Results, "TEST:$Test\n-----------------------\n";
        $bStarted = 1;
        open (RUN,"./$Test --clutter-show-fps &|");
        while(<RUN>)
        {
            push @Results, $_;
        }
        alarm 0;
    };
    if ($@)
    {
        die unless $@ eq "alarm\n"; # propagate unexpected errors
        # timed out
        system("killall -9 lt-test-interactive");
     }
}
# mark the end of the last test
push @Results, "END" if $bStarted;

# process the results
my $NumTests = 0;
my $Total = 0;
my $Max = 0;
my $Min = 9999;
my $TestName="";

print "\nName Min Max NumTests Average\n";
foreach my $Line (@Results)
{
    if($Line=~/^TEST:(.*)/)
    {
        # print "IN TEST $Line";
        $TestName= $1;
        chomp $TestName;
        $NumTests = 0;
        $Total = 0;
        $Max = 0;
        $Min = 9999;
    }

    if($Line=~/END/)
    {
        # print "IN END :$Line";
        $Average = 0;
        $Average = $Total/$NumTests if $NumTests > 0;
        print "$TestName $Min $Max $NumTests $Average\n";
    }

    if($Line=~/\*\*\* FPS: (.*) \*\*\*/)
    {
        # print "IN FPS: $Line";
        $NumTests++;
        $Total = $Total + $1;
        $Max = $1 if $1 > $Max;
        $Min = $1 if $1 < $Min;
    }
}

print "exiting ..\n";
 

 Appendix 2 - Essential notes on installing Fedora  

When installing Fedora you must install the Software Development tools.

Design Choices

Many of the functional parts of this application are foundational to everyday applications, requiring features such as user authentication, configuration storage and retrieval, network communications, and user interaction. It’s important to modularize the design as much as possible to both break the overall project down into manageable pieces and to make it easier to reuse the code.

The application checks each time it runs to see whether any user credential information has been entered. If not, it presents a typical user name/password login dialog box and stores the information in an encrypted local configuration file. A preferences dialog box makes it possible to change the user name and password after initial setup along with other program options.

For the initial release of this program, I assume that there is an active network connection. This is a bit of a stretch for the Compal JAX10* MID I tested on: It did not have an active 3G radio, so there was no “always-on” Internet connection. I was able to simulate having a consistent connection by using Wi-Fi, instead. Later versions might check for connectivity and, if currently disconnected, queue up the message to send the next time a connection to the Internet is available.

Another design consideration for the mobile form factor is deciding what happens when a button is pressed. With this particular application, there is a consequence for choosing single-key action; every time the user presses one of the action buttons, a message is sent to Twitter. If you assume the user won’t inadvertently press a button or do something like put the device in a back pocket with the application running, it shouldn’t be a problem. Alternatives might include adding a confirmation dialog box to each action (“Really send message?”), adding a button or a timer to lock the screen, or exiting the program by default after the message is sent.

Building a UI for the Small Screen

One of nice things about Python* is the abundance of libraries to do just about anything you need to do. The Compal* MID used for this project has a number of useful libraries installed as a part of the base operating system, and I chose to take advantage of them. The GTK+* user interface (UI) library contains a wealth of resources for building everything from a simple dialog box to a complex data-entry form. PyGTK is a wrapper around the GTK+ library and provides access to virtually every routine through standard Python objects.
Building a login dialog using PyGTK consists of creating a simple window with individual text boxes for username and password. You can find a good example and explanation of these techniques on the PyGTK tutorial page. In the following code snippet the pass_input.set_visibility(False) line causes the password to be blanked by a dot symbol:

def login(self):
        dialog = gtk.Dialog('Login', 
                            self.window,
                            flags=gtk.DIALOG_MODAL | gtk.DIALOG_DESTROY_WITH_PARENT,
                            buttons=(gtk.STOCK_CANCEL, gtk.RESPONSE_REJECT,
                                     gtk.STOCK_OK, gtk.RESPONSE_ACCEPT))
        dialog.set_default_response(gtk.RESPONSE_ACCEPT)
        
        userbox = gtk.HBox(False)
        
        user_label = gtk.Label('Username:')
        userbox.pack_start(user_label)
        
        user_input = gtk.Entry()
        user_input.set_activates_default(True)
        userbox.pack_start(user_input)
        
        dialog.vbox.pack_start(userbox)
    
        passbox = gtk.HBox(False)
        
        pass_label = gtk.Label('Password:')
        passbox.pack_start(pass_label)

        pass_input = gtk.Entry()
        pass_input.set_activates_default(True)
        pass_input.set_visibility(False)
        passbox.pack_start(pass_input)
	  dialog.vbox.pack_start(passbox)

A second option with GTK+ is to create a table that fills the screen with a matrix of buttons that essentially takes up all the screen real estate. Although doing so might not be as visually appealing, it does accomplish the task of building a finger-friendly interface in which you can easily “click” the right button. It also provides a few more options for adding descriptive text to the button for the Twitter application. In Python, the matrix would look something like this:

def create_table(self):
        self.table = gtk.Table(3,4,True) # Create a 3 row by 4 column table
        button1 = gtk.Button("Button 1") # Create a button named button1
        self.table.attach(button1,0,1,0,1) # put button 1 in location 0,1
        button2 = gtk.Button("Button 2")
        self.table.attach(button2,1,2,0,1)	
        button3 = gtk.Button("Button 3")
        self.table.attach(button3,1,2,0,1)
.
.
.	
        button12 = gtk.Button("Button 12")
        self.table.attach(button12,1,2,0,1)

The lines with a single period are meant to indicate that the sequence repeats down to the final definition of button12.

Coding Practices

Python is a language that allows you to write code by the brute-force method, as in the lines above, or in a more elegant way using concepts like iteration. If you were to define all 12 buttons in a linear fashion, you would need 26 lines of code. Using the Python for construct, you can accomplish the same task in a mere seven lines of code. That equates to less than one-third of the code for this simple example, but the difference would be substantial for a larger table. Here’s the code in a more “Pythonic” way:

    def create_table(self):
        self.table = gtk.Table(3,4,True)
        for row in range(3):
            for col in range(4):
            	name = 'Twitter %i' % (row*4 + col + 1)
            	button = gtk.Button(name)
            	self.table.attach(button, col, col+1, row, row+1)

Keeping your code manageable is important when scripts start to get large. Python functions are a good way to break down your code into small, manageable pieces. It’s also important to point out that everything in Python is an object. You can see this to some extent in the create_table function through the use of the self construct. The function create_table creates a gtk.Table and returns it as an object—hence, the use of self to refer to the object being created. There is an abundance of resources on the Web if you’re not familiar with object-oriented programming concepts.

Taking advantage of all the built-in language features and functions is another way to keep your source code manageable. Python has a module for reading and writing configuration files named ConfigParser. This module provides all the tools you need to save and read program configuration information. It supports different sections and creates a file of name–value pairs within each section. There are even individual methods to retrieve specific types, such as getboolean, getint, and getfloat.

If you can’t find what you need in the Python standard library, chances are that someone else has already written what you need. A quick Google* search typically returns multiple choices for a specific tool. Python-Twitter is a good example of a helper library to accomplish the heavy lifting of sending messages to the Twitter service. It’s hosted on Google Code* and even comes with several sample applications.

You can test code on the Compal MID in several ways. File transfer over a USB port is drop-dead simple and works well.  Optionally, you could attach a USB keyboard to the Compal MID and use the VI editor directly on the device for your editing and the Python interpreter for testing. This method works okay for small proof-of-concept efforts but gets out of control for anything but small, simple programs. Another, similar approach is to use Virtual Network Computing* (VNC) to remotely view the screen on the device through your workstation.

Another way is to use the emulator approach.  The Moblin* project has a tool called the Moblin Image Creator* (MIC) for building platform-specific images. With MIC you can also use the Xephyr* emulator tool to launch an independent session for testing purposes. This method has the advantage of a rapid build / test cycle to help work the bugs out of your code in short order.

A final way might be to test the initial version of the software on your Linux* desktop.  The advantage is that you don’t need MIC.  The disadvantages are that you may need additional hardware for your desktop (GPS, for example) and that you can’t test MID specific functionality (such as screen characteristics).

Lessons Learned

Don’t get bogged down in the details too early in the process. It’s important to completely flesh out your requirements in the beginning, then make some design decisions based on a clear picture of what you’re trying to accomplish. Get comfortable with your development tools—especially the debugging portion—as you’ll probably use them more than you think.

The easier it is for you to test and debug your code, the quicker you’ll get it running.

Have a convenient way to transfer files to your device that doesn’t require a lot of motion. This could be as simple as keeping an easily accessible USB cable plugged into your workstation. When you get down to squashing bugs, it helps to make the process as smooth and painless as possible, especially if you’re editing all the code on a workstation and have to move it over to the device for testing.

Summary

Building a solid application for the MID platform requires the same set of disciplined steps you would use in any software project. Be sure you don’t skip steps like these:

• Take your time on the design process, and consider alternatives.
• Think through the UI design from a user’s perspective before you start coding.
• Write your code with testing in mind.
• Have a clear set of requirements that you can test.
• Use tools such as source code control, and check in your code frequently.

About Author

Paul Ferrill has been writing in the computer trade press for more than 20 years. He got his start writing networking reviews for PC Magazine on products like LANtastic and early versions of Novell Netware. Paul holds both BSEE and MSEE degrees and has written software for more computer platforms and architectures than he can remember.

Power Efficiency – Analysis and SW Development Recommendations for Intel® Atom™ processor based MID platforms [PDF | 2MB ]

Background

The objective of this paper is to investigate Intel® Atom™ processor based MID (Mobile Internet Device) platform power (including chipset components) characteristics for typical workloads, such as media playback, browsing, idle, etc. The results are aimed at providing recommendations for SW developers on how to best optimize applications for power efficiency.
The platform power characteristics were captured using two methods:

• Instrumented Crown Beach/Menlow Software Development Platform (SDP) (including Intel® Atom™ processor and chipset) enabling discrete component power measurements using Fluke NetDAQ* equipment
• Linux* tool, PowerTOP*, to extract information on processor C-state (sleep) residency, P-state (execution) residency and wakeup characteristics.

The Intel® Atom™ processor provides low power features such as:

• New core x86 micro-architecture
  • In-order execution
  • Multithreading support. Hyper Threading Technology (HT) aka. Simultaneous Multi-Threading (SMT). Not available for all Atom SKUs.
  • Enhanced macro-op execution
• 45nm technology
• Enhanced Intel® SpeedStep® Technology
• Up to SSSE3 instruction set support
• Deep Power-Down Technology - C6 processor sleep state
• Dynamic cache sizing
• Enhanced dynamic clock gating
• Enhanced L2 data pre-fetcher

The chipset provides features such as:

• Graphics HW acceleration (including video acceleration used by media player)
• Intel® Display Power Saving Technology
• Intel® Rapid Memory Power Management

The OS/SW stack used for this investigation is Moblin* Linux with the Helix* media framework using HW accelerated video codecs. Other OS or SW stacks such as RedFlag*, MIDinux*, or Microsoft Windows* Vista are out of scope for this investigation.

The "Recommendations" chapter summarizes the findings from the analysis and provides guidelines on how to develop power efficient SW on the MID platform. The following chapters are divided into "Technical Background", which describes some key technical concepts, "Measurement procedure", which outlines the methods used to capture the data presented in this paper and "Workloads", which breaks down results for each of the workloads analyzed.

To read the rest of the article, please download the PDF below.

Recommendations

1. Be aware that one power inefficient application in Idle is enough to cripple battery life for the whole system.
2. Develop context aware applications that adapt to system state changes Refer to http://software.intel.com/en-us/articles/energy-efficient-software-developing-power-aware-apps for articles on developing for context awareness.
   • Power state change (system sleep/wake transitions): The application shall handle system power state change gracefully and not incur unnecessary delays. The application shall not prevent system from changing power state unless absolutely necessary.
   • Battery state change: Adapt behavior due to switch from AC to/from battery power. Some features, such as automatic updates, could potentially be deactivated to save power when powered by battery.
   • Network state change: Adapt application behavior to network connect/disconnect events. Some features could potentially be deactivated, saving power when not connected to network (flight mode).
3. Develop "Data Efficient" applications that minimize data movement to/from external storage or RAM. Also investigate if data movement can be grouped or batched to decrease frequency of drive spin up/down.
4. Utilize extended SIMD instruction sets such as SSE3, improving performance and indirectly reducing application energy usage.
5. Utilize tools to achieve power optimizations or identify power optimization opportunities
   • Utilize the Intel® Compiler for MID to compile the code into a binary specifically adapted to the Intel® Atom™ micro-architecture. This has the potential to greatly improve performance and in some cases also energy efficiency
   • Utilize PowerTOP to find components waking up the system excessively
   • Utilize Application Energy Toolkit to graph/analyze energy consumption

1. Make sure the system is configured to power the screen off if there is no user input for a suitable time interval. This reduces the average power in the chipset and allows additional power savings from LCD power down.
   
   Refer to chapter "5.1.2: Processor & Chipset power usage in Idle mode" for details.
2. Using on-demand governor to regulate P-state, depending on workload, improves system power efficiency.

1. Optimize to meet performance goals
2. Establish baseline before power optimizations
   • Gather data using PowerTOP in single threaded mode (Powertop currently not as accurate in HT mode)
     1. Wakeups/s
     2. Cx state residency
     3. Px state residency
   • If possible utilize external power meter to measure average power during application idle compared to system idle and during key workload execution
3. Investigate behavior during application idle compared to system idle. Explore difference in wakeups/s, Cx/Px states. Optimally an application in idle should have none or minimal impact on total system idle power
4. Use Intel® VTune™ for MID to identify functions that show high C0 residency running key application workloads. Utilize processor "unhalted ref clock" counter to assess C0 residency. Note that "Unhalted core clock" is unreliable due to frequency change (if Intel® SpeedStep® Technology is enabled) and that "Time stamp counter" is unreliable at and below C4 due to disabled PLL. "unhalted ref clock" / wall clock time can be used to compute true C0 residency.
5. Re-architect/re-code
   • Look for activities that force processor into C0 state (interrupts)
   • Coalesce or remove unnecessary activities to reduce wakeups
   • Look into data efficiency bottlenecks (disk, memory, network)
   • Note that optimizing for speed may increase C0% which might be OK since overall energy reduces due to performance speed up

For further details on the above and related topics please find detailed articles at Intel Software Network (ISN): Energy Efficient Software http://software.intel.com/en-us/articles/energy-efficient-software/.

Technical Background

This chapter explains some of the technologies in focus for this paper.

Measurement Procedure

Note that this paper does not analyze all component parts of a typical MID form factor device. MID devices will feature a range of wireless communication components such as WiFi, WiMax, WWAN or BT all increasing the average platform power footprint. Extended analysis of form factor devices might include networked workloads such as audio/video streaming, Chat or Email, VOIP, P2P solutions, connected browsing and gaming.

Workloads

• Idle behaviour in typical system idle states
• Video playback using Moblin Media Player & Helix framework
• Multi-threaded Video decode, audio transcode and Flash workloads used for HT impact analysis
• Browsing using Moblin Browser

• HT on/off
• C6 on/off

• Home Screen - HTML
• Home Screen - HTML - Screen off
• Home Screen - Clutter (OpenGL)
• Home Screen - Flash (UI created in Flash, embedded in HTML)
• XTerm
• Moblin Browser with default home page loaded

Appendix A - Atom™ processor specifications

Appendix B - HW setup and NetDAQ power measurement setup

Acronyms

• To validate 2+ hours of HD Video playback on an Intel–based "Cantiga" platform equipped with hardware accelerated video decode.
• To understand the impact of software playback application local power plans on creating energy efficient software and extending the battery life.

• "RV" – encoded in MPEG-2 & Bitrate: 40.000 Mbps
• "300" – encoded in VC-1 & Bitrate: 29.999 Mbps
• "Casino Royale" – encoded in H.264 & Bitrate: 33.000 Mbps

• Framerate: 23.976 Hz
• Resolution: 1920x1080
• Aspect ratio: 16x9
• xvYCC Stream: No

• Storage: Blu-ray* discs
• Optical Drive: Panasonic* Notebook SATA Blu-ray* drive
• Memory: 2GB (2X1 GB) DDR3 1066MHz
• CPU: T9400 @2.53 GHz Intel® Core™2 Duo Mobile (Penryn) Processor
• Chipset Video mode was set to VLD (Default Setting).
• HDD 80 GB SATA* Mobile HD 7200 RPM
• Operating System: Microsoft Windows Vista* 32bit
• Vista* Power Plan: Balanced
• Screen mode: Full Screen
• Battery Level: 100% at start of each test
• Testing Time & Nature: 5+ minutes per title starting at Chapter 1 for each test run

Figure 2. Application-1 Blu-ray* HD Video Playback



Table 1. Power Consumption during Application-1 Blu-ray* HD Video Playback

	H.264		VC-1		MPEG2
	MaxBattery	MaxPerf	MaxBattery	MaxPerf	MaxBattery	MaxPerf
Blu-ray Drive	3.32	3.57	3.74	3.74	2.56	1.40
HDD	1.66	1.88	1.60	1.61	1.69	1.55
CPU	2.23	2.29	3.26	3.22	2.21	2.41
Memory	2.09	2.29	2.33	2.32	1.83	1.91
GMCH	4.55	4.79	4.99	4.88	4.52	4.55
Platform	19.29	20.06	21.18	21.05	16.34	17.65
LCD Display	Not instrumented

• Application-1 is the most energy efficient software on both MaxPerf and MaxBattery Power settings for all encodings H.264, VC-1 & MPEG2.
• MPEG2 encoding significantly consumed less power on Application-1 and Application-2 when compared to H.264-2 and VC-1 encoding. This holds true regardless of application power plan settings.
• VC-1 encoding is the most costly encoding in the study on both applications. We find it interesting in the study that there is slight difference with VC-1 encoding on both applications regardless the power plan settings comparing to MPEG2 and H.264.
• As indicated early in this paper, there is no significant difference seen on the overall total platform power when plan power is set to MaxPerf on each application for H.264 and VC-1 encodings. Surprisingly, this also holds true that there is no difference between the two applications except in the case of MPEG2.
• As indicated before, LCD was not instrumental in this study. From a side power study on the impact of LCD brightness level, full brightness can consume around 5-6 watts, and 50% brightness can consume 3-4 watts. This also depends on LCD configuration such as bit rate and size.
• The Table 3 and Figure 4 data above clearly shows the overall total platform power consumed between 16 Watts and 22 Watts for all encodings. This data supports and proves that two hours of HD video playback can easily be reached in all encodings on Intel® Cantiga chipset, in particular with MPEG2 encoding with respect to LCD brightness level and battery size.

• Power Management Schema: Experiment and research more on their local power management schema since the paper surprisingly shows marginal differences in both H264 and VC-1 encodings on each application local power schema (independent from Vista* power plan).
• Power-Awareness Application: Applications should respond to appropriate OS power events and also shut down non-essential functions that may increase battery energy consumption, i.e., many applications use SetTimer() to invoke particular functionality after a specific time interval.
• Explore Device Buffering: Explore device buffering and content caching for VC-1 and H.264 without having any side performance risk or penalty on loading high intensive computation in the cache. Table 1 and Table 2 show Blu-Ray* Optical Drive power consumptions are below 3 Watts with MPEG encoding that may suggest data efficiency and device buffering .
• Optimizing the Application: Both applications in this paper use SSE2 and SSE3 micro-architecture. We therefore recommend that developer’s video playback applications take steps to optimize software decoders to take advantage of hyper threading, multiple cores, and special instruction sets such as Intel SSE4X and AVX that may help significantly optimize the application. There are also data efficiency techniques such as memory buffering and caching that can further improve energy-efficiency.

• Make Better Batteries:
  Battery life is a key differentiator in notebook PCs. Therefore, OEMs should increase the adoption of notebook PCs that require focus on longer battery life with high quality and capacity that can go all day on a single charge.
• Adapting Energy-Efficient Hardware:
  This paper clearly demonstrates the significant impact of Intel–based "Cantiga" platform equipped with hardware accelerated video decoders (Penryn CPU) on power saving compared to Intel-based "Matanzas" platform (Merom CPU). OEMs are highly recommended to continue investment in Intel® consumer platforms, both mobile and desktop, which include energy-efficient devices. In particular, 45nm processor technology (Nehalem) and dedicated hardware accelerators for high-definition video decoding. These new platform architectural changes will reduce CPU and total platform power and boost performance. In addition, Nehalem processors have Quad cores to support multi-threading and Intel® SSE4 and AVX instructions to enhance performance.

• Selecting Appropriate OS Power Plan:
  Each platform has different power profile settings that can be changed by the end user. These power settings can differentiate CPU performance and energy-efficiency with respect to CPU frequency. Therefore, before choosing your workload, it’s highly recommended to select the appropriate power plan and power sources such as AC/DC that can have an impact on the overall platform performance and power saving. Also, MS Vista* "Balanced" power profile allows Intel® SpeedStep™ technology and the OS to dynamically change the CPU frequency on demand. Also, it’s recommended to:
• Shut down OS unnecessary functions or features:
  For OEMs, and ultimately for consumers, OS Vendors (OSV) continue to develop OS features and tools that can make notebook PCs energy efficient and power aware. An effective energy efficient OS should monitor and measure any running process with respect not only to its performance but also to its power behavior. It’s been proven from this paper and other power studies, that video player, Web Media, Screen Saver, system update, Scan, Disc defragmentation, LCD Brightness level and more can impact overall power consumption. Thus, having a system with tools and gadgets that can be aware of the system power source and its status so that the behavior can be changed dynamically, or alerts end user to take an early action against any source of unnecessary running tools/features in order to save power, delivers the best possible user experience.

Processing power and the size of memory in the average computer has increased significantly over the years. The fact that most computers implement virtual memory and have large amounts of physical memory has desensitized many programmers to the need of conserving physical memory. Many programmers may wonder, "Why should I care about memory; the OS takes care of everything for me?". If you are writing programs targeted to "ultra" mobile devices such as mobile phones or mobile internet devices, known as MIDs, it is important that you care. An example of this kind of device is the Apple iPhone*. In the iPhone SDK, Apple states that only one iPhone application can run at a time. This restriction is not placed on the iPhone because of the operating system since it is a based on a Unix multitasking OS. This restriction is because of small memory size. Desktops and laptops run multiple applications easily since there are typically a gigabyte or more of RAM memory and if the application needs more, the OS will use virtual memory to page in and out of physical memory using "fast enough" storage devices. Mobile devices may have the similarly featured multi-process/multi-tasking operating systems and virtual memory systems but they do not have the large amounts of RAM available for applications to use. This paper presents information and specific examples on how to write applications with memory size and usage in mind so that there is not significant performance degradation when multiple applications are running at the same time.

In order to understand how to use memory efficiently in an application, one has to understand how the application uses the memory. Some people confuse optimizing for memory with optimizing for size of a data storage device such as a hard drive or solid state device storage. I bring this up because I do not want to confuse the reader about the size of the program on the mass storage device and the size of the program "in memory". A perfect example of this when I asked a couple of "C/C++" programmers what they do to minimize the amount of memory used in a program -- they said they use the compiler options to "optimize for size". Although it is true this can optimize the in memory footprint of an application, it does not necessarily minimize the in RAM memory, just because the file is smaller on disk. Although, there is a relationship between on disk size and in RAM size, since the executable file on disk is very similar to the in memory footprint, but I digress. Let us first look at what a program looks like "on disk".

There are predominately two types of program file formats, Executable and Linking Format (ELF) and Portable Executable (PE) format. The ELF file typically runs on a Linux/Unix/Apple OS while the PE file typically runs on a Windows* OS.



This paper is not going to go into significant detail on file formats, but it will describe the basics so you can understand how executable files are loaded in memory by the operating system and how to minimize an applications runtime memory footprint.

The reason it is important to understand the file format and what the loader has to do is that the executable file on disk is very similar to the in memory footprint after the OS has loaded it. This is intentional so that the program loader has to do a minimal amount of work when loading the program into memory. The program loader will take the binary files and load them as specified in the header sections. Once the program is loaded in memory for the most part the OS can treat it like any another memory mapped file.

Having identified file formats, let us look at the types of binary objects that compilers and linkers generate to make up the PE or ELF content. The three executable binary file types generated by a compiler/linker are executables, static libraries, and shared libraries. Executables and shared libraries are be loaded by the operating system at runtime as opposed to static libraries that are included into the other two files directly and "fixed at link time".

Partitioning software into classes and libraries is in general good coding practice. However, the programmer needs to be aware of the implementation. For example, the use of static libraries in memory can be a problem. Static libraries will be duplicated in physical memory in separately linked binary objects. I have seen many applications that use static libraries duplicating code several times in the same or multiple processes. For example, an executable and a .dll or .so, that both use the same static library, will duplicate the code since they are both independently linked.

A shared library’s implementation is different from that of a static library and it has to be treated differently by the loader; hence, the ELF and PE file formats have to account for the difference. The ELF file format distinguishes the two by providing a Relocation Header Table where as the PE file format embeds the information in the individual sections. The most common sections of the ELF/PE formats are divided into the following section:

• .text – Contains all of the "code"
• .data – Contains all of the initialized data
• .idata – Contains import data – names of other files and functions called
• .edata – Contains export data – names of files and functions available to other modules
• .reloc – Contains relocation information

The sections of interest are the .text (code section) and .data sections that may require fix up code.

On Windows, a shared library is known as a .dll or dynamic link library and on Linux the shared library is known as a .so or shared object. Although the implementation is different, the characteristics of these libraries or objects are similar. Shared libraries (.dll/.so files) provide the convenience of static libraries from a programmer’s point of view of sharing code without a lot of the memory duplication. Multiple applications may use the same set of libraries without increasing the size of the text when multiple applications are running at the same time. Applications using the same .dll/.so may be (assigned as owning memory by the OS) tagged for some of the same memory but in reality, it is shared with other processes. There is only one copy in physical memory for the read only memory but its usage is charged against every process that has loaded the dynamic library. The actual memory in use can be calculated by subtracting out all shared memory that is counted more than once. If you are interested in calculating exact numbers there are utilities that parse the ELF or PE sections and indentify which sections are shareable.

So why would you ever use static libraries? Shared libraries are nice but they may come with a cost in startup performance. In order to use shared libraries the operating system needs to do the following when the binary is loaded:

• Locate the shared library on disk
• Check to determine if the shared library is already loaded in the process space
• Allocate memory for the shared library
• Resolve Fix ups for the .text and .data sections

This all takes time and space. Both Windows and Linux provide explicit dynamic linking routines such as LoadLibrary or dlopen() and GetProcAddress() or dlsym() respectively. These routines effectively call the same routines that the implicit linker calls.

On Linux the only shared library that is statically linked is the glibc. Linux uses a pre-link virtual address for all other shared libraries. A compiler switch helps with the fix-up by providing a hint to the compiler to generate code that is designed to be position independent (-fPIC), and it avoids referencing data by absolute address as much as possible. A developer asked me why should we care, doesn’t the operating system take care of all this? The operating system will take care of any of the fix code for you but it is very inefficient if you don’t use the right options and create a shared library just for the sake of creating a shared library. For example a text relocation is a memory address in the "read-execute" text segment of a shared library. Say a non-PIC text segment calls into a memory location that needs to "fixed up" by the runtime. In Linux this is performed by the ld.so in glibc during the startup of the dynamically linked executable. If the developer didn’t design the code correctly there would be significant memory and fix-up penalties associated with the code. For example, a non-PIC compiled libmpg3 library has roughly 6000 memory locations left inside the shared library to point to some 300 functions and data referred to by the instructions. So why not use –fPIC all the time? There may be some cases where you may not want to use PIC. For the code to set up the PIC register (ebx typically) it takes about three instructions and an additional 1 – 2 instructions per symbol accessed in the data object. In addition, the PIC register is being used so the compiler is not free to use it for other purposes resulting in possibly less then optimal code performance by limiting the number of registers available to the compiler. On Linux, to test if, a shared object requires relocation in its text segment, tools such as "readelf –d binary.so" and inspect the output for any TEXTREL entry. The fact that TEXTREL exists indicates that text relocations exist.

On Windows the code that is compiled into a DLL uses a define _WINDLL to provide the compiler hints to avoid position dependent code minimizing fix-ups. Windows also provides for the dll to be rebased which improves the load time of the shared code as well as a minimizes the size of the image directory table since it will be first try to be loaded at the address specified by the rebase address.

So what is a "fix-up"? Fix-ups are adjustments to specific addresses that are not relocatable. For example say I have an STL string

string MyString="Initial Value";

The loader has to allocate the string "Initial Value" in the data segment and initialize a pointer the value. If the shared library needs to be relocated or rebased, the value of the pointer needs to be fixed up at runtime to point to the new address, creating a pointer to a pointer. This also happens to functions.

In general a well designed application can save significant memory by using shared libraries. Let us look an example of an Adobe Air application using their common runtime. It runs in a working set of 58,508 KB with 14,348 KB shareable memory unshared. Now let us launch a second Air Application. It runs in a 43,864 KB working set with 13,748 KB shareable memory unshared. When these two applications run by themselves, there is some sharing with the operating system already but running together, we have increased the amount of memory shared by 12,880 KB, a memory savings of 22 percent in the first application and 29 percent in the second application.

Given the fact it seems obvious to used shared libraries to minimize memory usage, here are some things to think about as a part of your application design. The more shared libraries you use the more fragmented your memory space can be because of code alignment which may result in wasted memory. You can dynamically load and unload shared memory, which may slow down performance when doing specific tasks but significantly improve memory. For example, if you have code that does a specific task infrequently such as converting a file from one format to another format; explicitly load a shared library to do the conversion only when the user requests the conversion and then unload the library.

Now we know we should look very closely at using shared libraries if possible. This includes using the C-Runtime Libraries as much as possible since they will most likely are already loaded. If your application does not dynamically load and unload the shared library, it may not help the amount of memory your application appears to take running by itself but it will significantly help the platform run multiple applications at a time. In the example of the two Air applications, the 29 percent savings may make the difference of placing an artificial limitation of one application at a time on a system. So what are some other things you can do to optimize your application for memory? Now let us look at specific optimizations that will help in improving the size of the application. Let us go back to the comment of "just setting the compiler to optimize for size".

Most compilers come with the option of optimizing for size. Typically, what this does is some or all of the following:

• Disables function, jump, loop and label alignment (removes gaps in memory due to the alignment)
• Disables pre-fetch loop arrays
• Does not perform loop unrolling
• Disables inline of functions

What I have found with 10 different client applications, of varying types is that the code size isn’t significantly improved between the "optimize for size" verses the "full optimization" option, typically less than 5 percent with a few exceptions for specific cases where significant vectorization or loop unrolling is taking place. What I did find is that compilers vary widely in size. In some cases I saw code size differences as much as two times the size. The main reason for the code size swings is because of the optimizations due to performance optimizations as stated earlier. I did do a comparison of the two times the size of binary and it was almost 4 times as fast as the smaller code. A size verse speed tradeoff. Many compilers provide optimizations for specific processors. Target the processor you are running on if possible. This will reduce the size of code by eliminating the other branches of code optimized for other processors if you know your targeted machine. I guess the lesson learn here is look at the compiler and options you select and don’t be afraid to look at other compilers and options. There is not any magic dust you can use that works in all cases for all code. The bottom line is not all compilers are the same, so what about linkers?

Some linkers provide an option to incrementally link files. Although the compiler typically has incremental linking turned on for debug and off for release, make sure it is off in your release code. Incremental linking is nice for developers that are changing code all of the time but is very bad when it comes to releasing code. The way incremental linking works is that on each segment of code it is padded with int 3 so that if the code is changed the linker will only have to re-link the effected section of code up to the padded int 3 region. In large executables the padded int 3 sections can easily put you into the hundreds of kilobytes or even megabytes. Also, remember to remove any debug symbols from the linker options that may be left behind in inadvertently.

So where does this leave us? I hope that you are a little more informed on how to write programs with tight memory requirements. Designing your applications to take full advantage of shared memory seems to give the biggest benefit. Determine which functions are needed in multiple places and share them. Take advantage of explicit loading of shared memory for large sections of code that rarely get used if possible. You should not only play around with different compiler options, but also look at different compilers and see what it does on your specific code. There is not a one size fits all here, the following list are a few of my findings and remember as you design your application don’t forget to think about memory.

• • Share as much memory as possible within and outside of your application. I have found this usually gives you more memory then all of the other optimization techniques.
    • Look at how you partition functions or classes. Try to make use of reusable code as much as possible and use shared libraries as the package implementation.
    • Determine how to best take advantage of other shared libraries that are already loaded on the system. Many applications are using a lot of the same functionality that you are and maybe running simultaneously. For example, a c-runtime is most likely already loaded into memory. If you are considering an application that uses other runtimes such as a Java runtime or Adobe Air runtime, some of the runtime code may be shared with other applications running simultaneously as well.
  • Experiment with the Compiler and it options
    • As stated earlier there is not a one size fits all for compilers and their options. Most compilers have an optimize for size option, however what I have found is that in a lot of the cases full optimization produces very similar code perhaps only slightly larger and slightly faster. You almost have to take it on a case-by-case basis.
    • When selecting compiler options if you know the target you are compiling to and do not plan on sharing the binary across platforms set the compiler option for the targeted platform. This provides about a 5 percent improvement on size and can significantly improve performance of the application since the compiler can be more specific in generating code optimized for the target platform.
    • Watch for options that may take up significant memory such as loop unrolling or linker options that is designed for debug such as incremental linking. Although loop unrolling may not be the most expensive as far as memory in some applications other it may be significant. Moreover, from what I have seen incremental linking is always an expensive option and provides no runtime benefits.
    • Watch out for segment alignments. Some compilers align segments of text on large boundaries sometimes up to page sizes of 4096 bytes. This could end up wasting a lot of memory just to align a text or data segment.
  • Use the stack often but be careful of static or unnecessary variable initializations. Remember if you use initialize the variable it will require you to have a copy of the value in a read only data section in many cases.