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.

Overview of MeeGo Networking

• QWebView.pro - the Qt project file
• mainwindow.ui - the definition of the main window GUI
• mainwindow.h - the header file for the main window
• main.cpp - the source file for the application
• mainwindow.cpp - the source file for the main window

• QLineEdit named urlEdit
• QPushButton named refreshButton
• QWebView named webView
• QTextEdit named debugTextView

:: error: collect2: ld returned 1 exit status

QT       += core gui network webkit

#include <QtWebKit>

void MainWindow::on_refreshButton_clicked()
{
    QString targetURL = ui->urlEdit->text();
    ui->debugTextView->append("URL Entered: " + targetURL);
    ui->webView->load(QUrl(targetURL));
}
void MainWindow::on_webView_loadStarted()
{
    ui->debugTextView->append("Load Started");
}
void MainWindow::on_webView_loadFinished(bool )
{
    ui->debugTextView->append("Load Finished");
}

private slots:
    void on_webView_loadFinished(bool );
    void on_webView_loadStarted();
    void on_refreshButton_clicked();

• QNetworkAccessManager.pro - the Qt project file
• mainwindow.ui - the definition of the main window GUI
• mainwindow.h - the header file for the main window
• main.cpp - the source file for the application
• mainwindow.cpp - the source file for the main window

• QLineEdit named urlEdit
• QPushButton named fetchButton
• QTextEdit named returnText

private:
    Ui::MainWindow *ui;
    QNetworkAccessManager *netmanager;
    void fetchURL(QUrl);

#include <QtNetwork>

QT       += core gui network

void MainWindow::fetchURL(QUrl targetURL)
{
    netmanager->get(QNetworkRequest(targetURL));
}

private slots:
    void fetchFinished(QNetworkReply*);

MainWindow::MainWindow(QWidget *parent) :
    QMainWindow(parent),
    ui(new Ui::MainWindow)
{
    ui->setupUi(this);

// The following coded added for our example
    netmanager = new QNetworkAccessManager(this);
    connect(netmanager, SIGNAL(finished(QNetworkReply*)), this,
        SLOT(fetchFinished(QNetworkReply*)));
}

void MainWindow::fetchFinished(QNetworkReply* reply)
{
    ui->returnText->append("Fetch Finished!");
    QString *replyText = new QString(reply->readAll());
    ui->returnText->append(*replyText);
}

void MainWindow::on_fetchButton_clicked()
{
    QUrl targetURL = QUrl(ui->urlEdit->text());
    fetchURL(targetURL);
}

void on_fetchButton_clicked();

Potential Issues

• QNetworkInterface, among many other things, provides a simple way to enumerate the network interfaces reported by the OS and their network settings such as IP addresses. You can also test flags associated with each interface to determine its state. It is important to keep in mind that just because an interface may be up, it may not be able to access a network resource across the globe or even on the same local network. On the other hand, if no interfaces with valid IP addresses are returned by this class, you can be fairly certain that no network resources will be reachable.
• QNetworkConfigurationManager and QNetworkConfiguration classes provide detailed information about a specific network configuration. One of the more useful properties is the BearerTypeName which may be Ethernet, WLAN, WiMAX, CDMA 2000, etc. Of course the OS must correctly report the type on any give platform.
• QNetworkAccessManager is the basis of the second example here but there are options not shown in the example for checking connectivity. In particular, the networkAccessible() function should return the general state of connectivity for the QNetworkAccessManager object.
  
  Unfortunately, in my testing I was not able to get a return value other than QNetworkAccessManager::UnknownAccessibility.

void MainWindow::fetchFinished(QNetworkReply* reply)
{
    ui->returnText->append("Fetch Finished!");

// Redirection handler
    QUrl redirectURL = reply->attribute(
         QNetworkRequest::RedirectionTargetAttribute).toUrl();
    if(redirectURL.isValid())
         fetchURL(redirectURL);

    QString *replyText = new QString(reply->readAll());
    ui->returnText->append(*replyText);
}

Navigating Proxies

void MainWindow::fetchURL(QUrl targetURL)
{
// Addition to set system proxy
    QNetworkProxyFactory::setUseSystemConfiguration(true);

    netmanager->get(QNetworkRequest(targetURL));
}

void MainWindow::on_refreshButton_clicked()
{
    QString targetURL = ui->urlEdit->text();
    ui->debugTextView->append("URL Entered: " + targetURL);

// Addition to set system proxy
    QNetworkProxyFactory::setUseSystemConfiguration(true);

    ui->webView->load(QUrl(targetURL));
}

QSslSocket: cannot call unresolved function SSLv3_client_method
QSslSocket: cannot call unresolved function SSL_CTX_new
QSslSocket: cannot call unresolved function SSL_library_init
QSslSocket: cannot call unresolved function ERR_get_error
QSslSocket: cannot call unresolved function ERR_error_string

Summary

About the Author

Tom Propst is a Software Engineer at Intel focusing on mobile application development and optimization. Tom is defined outside of the office by his love for cycling.

QThreads

#include <QCoreApplication>
#include <QThread>
#include <QtGui/QImage>
#include <QString>
#include <QDebug>

class LoadThread : public QThread
{
public:
    LoadThread() { filename = ""; image = NULL; }
    LoadThread(QString str, QImage *img) { filename = str; image = img; }

protected:
    void run() { image->load(filename); }

private:
    QString filename;
    QImage *image;

};


int main(int argc, char *argv[])
{
    QCoreApplication a(argc, argv);

    QString filename1 = "1.jpg";
    QString filename2 = "2.jpg";
    QString filename3 = "3.jpg";

    QImage image1, image2, image3;

    LoadThread *thread1 = new LoadThread(filename1, &image1);
    thread1->start();

    LoadThread *thread2 = new LoadThread(filename2, &image2);
    thread2->start();

    LoadThread *thread3 = new LoadThread(filename3, &image3);
    thread3->start();

    thread1->wait();
    thread2->wait();
    thread3->wait();

    if (!image1.isNull() && !image2.isNull() && !image3.isNull()) {
        qDebug("All pictures loaded!\n");
    }

    return 0;

}

#include <QCoreApplication>
#include <QtGui/QImage>
#include <QString>
#include <QtCore>
#include <QDebug>

bool LoadImage(QString str, QImage *img) {
    return img->load(str);
}

void CheckResult(QFuture<bool> res1, QFuture<bool> res2, QFuture<bool> res3) {
    if (res1 & res2 & res3) {
        qDebug("All pictures loaded!\n");
    }
}


int main(int argc, char *argv[])
{
    QCoreApplication a(argc, argv);

    QString filename1 = "1.jpg";
    QString filename2 = "2.jpg";
    QString filename3 = "3.jpg";

    QImage image1, image2, image3;

    QFuture<bool> result1 = QtConcurrent::run(LoadImage, filename1, &image1);
    QFuture<bool> result2 = QtConcurrent::run(LoadImage, filename2, &image2);
    QFuture<bool> result3 = QtConcurrent::run(LoadImage, filename3, &image3);

    CheckResult(result1, result2, result3);

    return 0;

}

#include <QCoreApplication>
#include <QThread>
#include <QtGui/QImage>
#include <QString>
#include <QDebug>
#include <QMutex>

int totalByteCount;
QMutex countLock;

class LoadThread : public QThread
{
public:
    LoadThread() { filename = ""; image = NULL; }
    LoadThread(QString str, QImage *img) { filename = str; image = img; }

protected:
    void run() {
        image->load(filename);

        if (!image->isNull()) {
           countLock.lock();
           totalByteCount += image->byteCount();
           countLock.unlock();
       }
    }

private:
    QString filename;
    QImage *image;

};

int main(int argc, char *argv[])
{
    QCoreApplication a(argc, argv);

    QString filename1 = "1.jpg";
    QString filename2 = "2.jpg";
    QString filename3 = "3.jpg";

    QImage image1, image2, image3;

    totalByteCount = 0;

    LoadThread *thread1 = new LoadThread(filename1, &image1);
    thread1->start();

    LoadThread *thread2 = new LoadThread(filename2, &image2);
    thread2->start();

    LoadThread *thread3 = new LoadThread(filename3, &image3);
    thread3->start();

    thread1->wait();
    thread2->wait();
    thread3->wait();

    if (!image1.isNull() && !image2.isNull() && !image3.isNull()) {
        qDebug("All pictures loaded with a total byte count of %d\n", totalByteCount);
    }

    return 0;
}

#include <QCoreApplication>
#include <QtGui/QImage>
#include <QString>
#include <QtCore>
#include <QVector>

class MyImage {
public:
    MyImage() { filename = ""; image = NULL; }
    MyImage(QString _filename) { filename = _filename; image = NULL; }
    QString filename;
    QImage *image;
    void load() {
        if (filename != "") {
            image = new QImage(filename);
        }
    }
};

void ImageLoad(MyImage &myImg) {
    myImg.load();
}

int main(int argc, char *argv[])
{
    QCoreApplication a(argc, argv);

    QVector <MyImage> images;

    images.push_back(MyImage("1.jpg"));
    images.push_back(MyImage("2.jpg"));
    images.push_back(MyImage("3.jpg"));
    QFuture<void> done = QtConcurrent::map(images, ImageLoad);

    done.waitForFinished();

    bool flag = true;

    for (int i = 0; i < images.size(); i++) {
         if (images[i].image->isNull()) {
             flag = false;
             break;
         }
     }

    if (flag) {
        qDebug("All pictures loaded!\n");
    }

    return 0;
}

About the Author

Download Article

Streamlining the Mobile Development Process

Maemo* + Moblin™ = MeeGo*'s Heritage

MeeGo* and the Open Source Community

The Take-home Lessons of the Antix Move to MeeGo*

About the Author

Tip 1: Be Flexible with Your Presentation Layer

Tip 2: Use Middleware That's Already Multiplatform

Tip 3: Consider Mobile Users

Tip 4: Allow for Multiple Input Methods

Tip 5: Plan for Localization

Tip 6: Choose a Development Environment That Makes Porting Easy

Summary

References

About the Author

Since Intel Atom processors are based on the IA-32 architecture and support Intel® Streaming SIMD Extensions-3 (Intel® SSE3), VTune™ Amplifier XE can be used to analyze software running on the machine. This should work for any of the supported platforms and operating systems listed in the Release Notes.

VTune™ Amplifier XE supports the Atom processor both for general operations such as data collection and data analysis, as well as Atom-specific event-based sampling analysis (EBS).

When using VTune™ Amplifier XE on an Atom based device two different approaches are commonly used. The first approach is to run the complete VTune™ Amplifier XE on the Atom target. This implies installation of the full product and requires significant hardware resources to be installed on the machine. In this case all types of analysis can be made from within VTune™ Amplifier XE GUI.

A second approach is to use a remote collector on the target Atom machine, the results being then analyzed on a PC that has the full VTune™ Amplifier XE product installed (the host machine). In this mode, VTune Amplifier XE just requires that the remote data collector and command line tools are installed on target machine - see Figure 1.  Refer to the product Release Notes for installation guidelines.

Once the data collectors are installed on the target, use the command line tools to collect raw data.

With remote data collection, those data need to find their way back to the host machine for analysis, viewing and reporting, but this can be done by a variety of means, from network copies to remotely mapped file systems.

Figure 1 - Remote data collection using VTune™ Amplifier XE

For example:

>amplxe-cl -collect concurrency -result-dir r001cc my_app

This command runs Concurrency analysis for the my_app application and stores the results in directory ‘r001cc.’

When the collection is finished, the ‘r001cc’ directory will contain everything needed on the host machine to complete the analysis.

Configuring the Hardware Event-based Sampling Analysis

• When full product is installed on the target system

There are no predefined collection types for the Intel® Atom™ processor, but users can create custom profiles based on available Performance Monitoring Unit (PMU) events.

To create a new analysis type, press the ‘New’ button and select ‘New Hardware Event-based Sampling Analysis.’

Then press the ‘Add Event’ button and select the desired events from the list of available events provided for the current microarchitecture.

Note: You can copy the generated command line and configuration file and use them for data collection without the GUI. To do that press the ‘Get Command Line’ button and read instructions.

• When only data collectors and command line tools are installed on the target system

Running EBS data collection remotely requires both a configuration file (.cfg) and a command line that will be fed to the collection tool running on the target.

If the full product is not available on the target machine, you might be able to configure something on the host machine that can be used on the target:

- Start a new project and configure Hardware Event-based Sampling Analysis

- Edit the generated .cfg file: event names in the "pmuEventConfig" knob must be changed according to the target machine PMU

- Copy the .cfg file to the target machine and use a path to the file in the command line.

To check which PMU events are available in the CPU installed on the system run the command:

>amplxe-runsa -event-list

There is a simple way to remotely collect the most commonly used EBS data without creating a .cfg file:

>amplxe-cl -collect lightweight-hotspots my_app

>amplxe-runsa -d 10 --event-config "CPU_CLK_UNHALTED.CORE":sa=2000000, "SIMD_INST_RETIRED.ANY" --result-dir r001lh –- my_app

>amplxe-cl -finalize r001lh

In these commands the run-tool runs EBS collection with the selected events for the my_app application during 10 seconds, and then stores the raw results in directory ‘r001lh.’ For resolving symbols the finalization command of data collector is used.

Download Article

Clean Manufacturing

• Lead
• Mercury
• Cadmium
• Hexavalent chromium
• Polybrominated biphenyls
• Polybrominated diphenyl ether

• Dioxin and dioxin-like compounds are persistent organic pollutants (POPs), which means that they don't readily degrade through chemical, biologic, or photolytic processes.
• Because they are such durable compounds, they are readily transported over long distances by movement in air and water.
• They bioaccumulate in human and animal tissue.
• They biomagnify in food chains.
• Dioxin and dioxin-like compounds are not intentionally manufactured for any purpose. The dominant environmental input is open burning of trash and in particular, e-trash.

Facing the E-trash Issue

You Can't Talk Green Without Talking Energy

• The waste can be present as excess capacity for an IT operation that has overprovisioned to ensure that it will have the necessary resources when computing demand peaks.
• The computer can be left on when it isn't actually in use, so that it will be rapidly available for ad hoc use.

• More than 50 times less at processor idle
• More than 20 times less for audio
• More than two times less for video playback and connected browsing

Ultramobility Is the New Normal

About the Author

Tip 1: Don't Overlook an Opportunity to Reintroduce Legacy Inventory

• They require little modification in terms of graphics.
• Netbook users tend toward intermittent usage patterns, so short-duration, arcade-style play nicely fits the needs, preferences, and usage patterns of the audience.
• Netbook versions of earlier games have an extremely low barrier to entry and low cost of sales because expenditures associated with development, documentation, and marketing have already been retired. Most of each revenue dollar is profit, making it easy to compete on price in this space.
• Perhaps best of all, arcade-type games are easy to internationalize, which dramatically broadens the potential audience. European and Asian consumers have enthusiastically embraced netbooks.

Tip 2: Join the Intel® Atom™ Developer Program

• A digital distribution center for applications that target netbooks
• A validation process to ensure that applications play well on netbooks
• A software development kit (SDK) to connect your game with the Intel AppUp^SM center
• The opportunity to sell games or game components on the Intel AppUp^SM center, where developers receive up to 70% of the revenue

Tip 3: For Newer Generations of Games, Start by Evaluating Visuals

Tip 4: Netbook Users Rely on the Keyboard and Touch Pad to Interact

Tip 5: Make "Gaming on the Go" a Strength and a Selling Point

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