Usage Case Examples for Intel Energy Checker

Usage Case Examples for Intel Energy Checker

The Intel Energy Checker SDK has been released a month. What are some of the Use Cases that have evolved from downloading and using the API? Interesting examples?

6 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

I also downloaded the SDK. And i'm very pleased with intel's initiative of Greener software. I'm thinking of pushing or start a project practicing Greener softwaredevelopment. Where can i get guidance or technical information pertaining to greener software development. Maybe intel engineers can share with us on their knowledge of green softwaredevelopment.

Did not want you to think your query was being ignored. I am looking for the appropriate people to provide an answer. Very much appreciate your interest.

so the api should be inserted in my application code , or can i develop another code for analyze the main application?

Hi J3r3mi,

An open ended question usually brings another open ended question.
Nonetheless your question is very legit. So what can you do to improve my
softwares energy efficiency?

First of all, this post wont be enough to provide detailed
answers. Keep in mind that software energy-efficiency is a virgin territory, so
we do not have all the answers today.

Now, to give you a big picture on the available options, I
would split the life-cycle of deployed software in two phases or cycles. This
split is of course highly dynamic and is artificially turning a color picture into
a black & white.

The first cycle is when the software is idle, or more
exactly when it is not producing useful work for the user. The second is when
it is active. Lets look quickly at the first one first. When an application is
inactive, it should always do its utmost to help the OS/HW to reach the deepest
sleep states. This way, the lowest idle power can be reached, and during the overall
run of the software your customer will save energy. There are lots of tools /
publications that you can find today on the topic. As an immediate corollary,
it turns out that performance optimization is the second action you can immediately
take. And this is great news for at least two reasons. First, performance
optimization is not orthogonal to energy efficiency improvements. Second, by
optimizing performances, you will increase the opportunities to reach deep
sleep states since you run for a shorter time. There are also lots of
techniques / publications on the topic. You will find plenty in this very forum.
So you can start by these two actions immediately but I am sure that many of
us already do. One may argue that performance optimization belongs to the
second cycle (when the software is active), but since the goal from an energy
efficiency point of view of performance optimization is to fulfill the run
fast, sleep longer motto, I am attaching it to the first one.

Lets look now at the second cycle. This is the most
interesting one and the most difficult to optimize. But before looking into details,
let me address the grey area that lies in between the two cycles (remember, the
split was artificial): the tradeoff zone. In many cases, you may provide
options to your user to trade some performance / feature vs. energy efficiency.
This is perfectly legit, and as soon as both parties are satisfied, it is a
good deal. You may for example, use a less-precise algorithms, run deliberately
slower, defer I/Os, de-activate less-relevant features, etc. Laptop users are accustomed
to this notion. If you want to save battery life, you can give up something acceptable
in exchange. There are also a lot of publications / techniques on this too.
Mobility applications are often implementing this approach. A good source of
inspiration for this class of optimization is to look into your operating
systems power saving infrastructure and APIs. There are lots of services
available that just needs to be used.

Now, lets get to core of the problem: your software is
running full steam, producing lot of useful work and you cannot give-up any
performance or feature. This is where we are looking. One of the tasks that we
are carrying out is to build a portfolio of proofs of concepts on how energy
efficiency can be optimized under this regime. The final objective is to help developers
with these POCs, so they can use them to make their applications energy
efficient. The SDK documentation has a chapter presenting two of these POCs and
few ideas. But please keep in mind that even this narrowed-down field, there is
a wide pallet of options to improve softwares energy efficiency. In our team,
we are looking first to the low hanging fruits that yield a measurable power
at the wall reduction. The paths that we have explored up to now, and showed
to be successful, are based on a better use of intrinsic and unique
knowledge of the software (hence the developer), to better use the existing HW power
saving features. You will find two examples of this in our user guides. Lets review
two other ideas that our readers could kick-off to make a difference for their
customers. Dynamic voltage and frequency positioning of the processor is essentially
driven by the operating system. Now the problem in this scenario is that the OS
doesnt have any insights on what is happening in the application, and
definitively has no clues on what the software will do in the (short) future.
This is true if you are the OS. If you stand in the application now, this is not
true anymore. Software knows exactly what it does and one can formalize this
activity easily. The idea is that the application can if not controlling it
directly (case of a dedicated system) provide such hints to a governor / management
middleware (there are business opportunities here), so it can now drive the
chip power in a more efficient way. We could image a mechanism a-la memory
prefetch, where the application could say that in the next Xms for Yms I will
be inactive. The management layer, could then, based on the aggregated information
from other similarly energy-aware applications, make a decision and change or
not the power-level of the chips. Likewise, there is a second idea I can share
with you. Cooling in servers has a big impact on the energy bill. It has been
proven by researches that it is possible to drive fans using the CPU utilization
and to save power vs. existing governors. Now, lets push the idea a bit
further. Why couldnt we use the unique and inherent knowledge of the
applications to drive the fans? An easy way would be to build-in to the
application a model of the softwares activity and derive a very basic set of
metrics such forecasted CPU utilization for the next 1, 5 and 10 seconds and feed
them into the fans marshalling system (the sharing of these counters could be
done using the Intel Energy Checker API for example).

As I said in preamble, options are numerous. They are not
easy to prove and may be deceptive. However, this is a great time and
opportunity to put the software back into the power management loop, where it
belongs. We, software developers, have a unique knowledge of our applications.
This knowledge is forbidden to the OS or the HW. My hypothesis is that we can
leverage this information and help the OS / HW to better save energy. Now a
last word on the possibilities pallet Ive mentioned earlier. It is certainly
possible to device automatic energy efficiency optimization systems, code generators
for energy-efficient, etc. These researches are more fundamentals and are
probably better done in the academia. However, nothing prevents any of you to
find the next big idea in SW energy saving. And if you want to share your
findings, ideas, you are welcome to do it in this forum.



FYI, a book will be dedicated to the topic in the future (

Hi Osvaldo,

You can use the API directly from your code or you can build a shared library and use the functions this way. Now comes probably the most interesting part of your question. What to do with the API? The API's objective is really to exchange data in a simple way between applications. We have created several tools and samples in the SDK so developers can assess their applications' energy efficiency quickly and simply. This can be done in many different ways that I will summarize quickly here.

The first option is to do - almost - nothing. Just use ESRV / and a sample logger to collect power and energy readings while you are running your code. You will obtain for example a baseline measurement. Your application (on "this" system), has burned X Wh to process Y amount of useful work. For example, you could use one of your performance benchmarks to do this measurement. Then, applying your optimization - please have a look at my answer to j3r3mi in this thread for options / ideas - and redo the measurement. Repeat the cycle until satisfied. This is very similar to the performance optimization iterative methodology.

The second step, useful to you, but also to your customers, is to make your SW energy-aware. This simply means that you can import power / energy readings from ESRV (or even from your custom tool if available). Indeed, more important than the information source, is the information itself. Here, your application will have an on-line power / energy input to measure the energy consumed by the system on which it runs. It is then immediately possible to expose from your application - and while it is running - your energy efficiency metric(s). If you write a database for example, it could be "joules / SQL transaction", if you develop a web service, it could be "joules / page", etc. This information is useful to your end users, because it will allow them to better manage their resources, and in many cases, to be able to measure / monitor their system's energy efficiency in a very meaningful way.
From your point of view, you can use this input at least in two different - but further, additional - ways. The first use of the data is to feed your application's green heuristic module. This green module could for example use this input to select between algorithms, trigger optimization, etc. The second use of this same input is to close the loop. Since as you will notice, optimization are rarely universal, you may want to check the impact of the green module's actions. The feedback data can be used to assert the validity of the decision(s), and to cancel them if necessary. These are just the basic options you have.

Another idea before concluding, your application could use a history of its energy efficiency vs. other system / application-level metrics. This data can be very valuable to the green module itself, but also to your customers.

I hope that I've answered your question, if no, I would be happy to discuss this further with you.

Leave a Comment

Please sign in to add a comment. Not a member? Join today