Instruction Level and OS Profiling for Energy Exposed Software.pdf

1044

IEEE TRANSACTIONS ON VERY LARGE SCALE INTEGRATION (VLSI) SYSTEMS, VOL. 11, NO. 6, DECEMBER 2003

Instruction Level and Operating System

Profiling for Energy Exposed Software

Amit Sinha, Nathan Ickes, and Anantha P. Chandrakasan

orders of magnitude in terms of energy consumption [4], [5].

However, dedicated implementations are not always feasible.

Application specific integrated circuits (ASICs) are getting

increasingly expensive to manufacture and are feasible only

when speed and volume constraints are overbearing. Apart

from reduction of the prohibitive cost of ASIC solutions,

software systems offer significant other advantages over hard-

wired solutions such as flexibility for changing requirements

and standards. The possibility of a field upgrade and lesser

time-to-market offered by software solutions has critical eco-

nomic consequences on the product cycle. The breaking of the

$5 threshold for 32-b processors has resulted in an explosion

in the use of general-purpose microprocessors and DSPs in

high-volume embedded applications [6].

While it is true that maximum power savings are possible

through hardware optimizations, it is the software that finally

runs on the hardware and smart software design can yield sub-

stantial power reduction. The present day software engineer has

little or no knowledge of the energy efficiency of his application

code. Just as performance tuning tools [7] and feedback com-

piler optimization techniques have been proposed and used to

improve the performance of various applications, it is possible to

envision an integrated development environment that provides

application energy consumption feedback to the software engi-

neer. We define such a framework as an “energy exposed soft-

ware” development environment and a conceptual flow within

the framework is illustrated in Fig. 1. Energy models for the

target hardware platform are embedded in the application de-

velopment environment along with the energy cost of various

operating system and library function calls. When an algorithm

is developed in a high-level language and compiled, its energy

cost is also profiled along with other standard parameters such

as code size. Runtime information is required for energy estima-

tion. Feedback from profiling tools in conjunction with energy

models could be used to identify energy intensive code sections

for the programmer. The energy efficiency of the program could

then be improved iteratively or by smart compiler optimizations.

In this paper, we have proposed energy models for software and

the operating system based on the StrongARM SA-1100 and Hi-

tachi SH-4 processors. A web based tool that implements these

models in the framework of Fig. 1 is also described.

Abstract— Energy conscious software design can significantly

improve the energy efficiency of a portable system. A software

energy estimation technique using instruction class profiling is

presented. The technique is shown to have an estimation error

of less than 3% with trivial runtime overhead, based on a set

of application programs evaluated on the StrongARM SA-1100

and Hitachi SH-4 microprocessors. A technique to isolate the

switching and leakage energy components of software is outlined.

The energy overhead of a real-time operating system is also

profiled.

The

overall

impact

system-level

software

energy

management is quantified using the MIT

AMPS system as an

application example.

Index Terms— Instruction current profiling, low power, software

energy, system-level energy management.

I. I NTRODUCTION

E NERGY efficient system design is becoming increasingly

important with the proliferation of portable, battery-op-

erated appliances such as laptops, personal digital assistants

(PDAs), cellular phones, MP3 players, etc. The energy con-

straints on portable devices are becoming increasingly tight

as complexity and performance requirements continue to be

pushed by user demand. Incredible computational power is

being packed into mobile devices these days. Moore’s law

has resulted in processor speeds being doubled approximately

every 18 mo [1]. There has also been a corresponding increase

in power consumption in processors. In fact, microprocessor

power consumption has gone up from under 1 W to over 50 W

over the last 20 years. As the demand for portable electronics

increased, several low-power processors entered the market.

Most of the power savings in these low-power processors

comes from three sources: 1) smart circuit design, (a good

overview of such techniques is present in [2]); 2) throwing

away lesser used functionality [3] i.e., architectural trimming;

and, 3) voltage scaling and clock gating [16], [25].

It has been shown in separate applications that dedicated

hardware implementations can out perform general-purpose

microprocessors/digital signal processings (DSPs) by several

Manuscript received September 18, 2003; revised February 14, 2002. This

work was supported in part by the Defense Advanced Research Project Agency

(DARPA) Power-Aware Computing/Communication Program and in part by the

Air Force Research Laboratory, Air Force Materiel Command, under Contract

F30602-00-2-0551.

A. Sinha was with the Electrical Engineering and Computer Science Depart-

ment, Massachusetts Institute of Technology, Cambridge, MA 02139 USA. He

is now with Engim, Inc., Acton, MA 01720 USA (e-mail: sinha@alum.mit.edu).

N. Ickes and A. P. Chandrakasan are with the Electrical Engineering and

Computer Science Department, Massachusetts Institute of Technology, Cam-

bridge, MA 02139 USA (e-mail: nickes@mtl.mit.edu; anantha@mtl.mit.edu).

Digital Object Identifier 10.1109/TVLSI.2003.819569

II. R ELATED W ORK

There has been significant work in the field of software

power estimation and optimization. Instruction level power

estimation tools have been proposed to compute the energy

consumption

software

[11]–[13].

The

basic

idea

Authorized licensed use limited to: Politechnika Lodzka. Downloaded on January 14, 2010 at 20:08 from IEEE Xplore. Restrictions apply.

SINHA et al. : INSTRUCTION LEVEL AND OPERATING SYSTEM PROFILING FOR ENERGY EXPOSED SOFTWARE

1045

Fig. 1.

Energy exposed application development environment.

run each instruction or short sequences of instructions in a

loop and measure the average current/power consumption.

In [15], the authors perform a microanalysis of instruction

level power consumption for a superscalar pipelined processor

using dedicated hardware to collect instruction statistics. The

primary drawback of estimation techniques based solely on

instruction level profiling is that these tools rely on exhaustive

characterization of the energy consumption of the entire in-

struction set architecture (ISA) and interinstruction effects. The

estimation model is compute intensive, requiring a complete

trace analysis of the program’s instructions and is therefore

slow. In [14], the authors propose energy estimation using

function-level macro-modeling to improve the estimation speed

over instruction-level profiling. Their results indicate one-two

orders of magnitude speedup based on characterization done

on the Fijitsu SPARCLite and SimpleScalar processors.

System level energy management policies have also been

widely researched. The authors of [17] have implemented

and compared different policies on a laptop computer. Their

experiments indicate that policy selection is a tradeoff between

power saving, performance, interactivity, and resource re-

quirements. In [26], dynamic power management in a wireless

sensor network system is studied. It is shown that fine-grained

shutdown can lead to scalable energy-performance tradeoffs.

Dynamic voltage and frequency scaling has been proposed and

demonstrated as an effective tool for system energy reduction

[25], [16].

In this paper, we have outlined a software energy estima-

tion technique that estimates the energy consumption of soft-

ware with trivial runtime overhead. The significant difference

between our technique and others published in literature is two

fold. 1) Our technique explicitly computes both switching and

leakage energy components of software. Leakage currents are

increasing exponentially in digital systems and this distinction

is important for optimum policy decisions in standby states of

software. 2) Our technique does not require elaborate instruc-

tion trace analysis. It is based on a few instruction class sta-

tistics that can be collected at runtime with almost zero over-

head while maintaining an average energy estimation error of

less than 3%. Our estimation technique is verified on the Stron-

gARM SA-1100 and Hitachi SH-4 processors and is described

in Section III. We have incorporated our techniques into a web

based tool for the research community to explore and test [8],

[9]. The tool can just as easily be a part of an integrated de-

velopment environment (IDE). This tool has been designed as

part of the ongoing MIT AMPS Project, which is developing

power-aware techniques for wireless sensor networks [10]. We

have used the AMPS sensor node as an example application.

In several embedded systems, a substantial portion of the exe-

cuting code is comprised of various operating system (OS) func-

tion calls. As such it is critical to expose the energy cost of such

calls within the IDE. In Section IV we have characterized the en-

ergy cost of a popular embedded OS used in the AMPS appli-

cation. The OS energy models in conjunction with application

code energy estimation have been used to significantly improve

the energy efficiency of the AMPS sensor node. The overall

system level energy savings for the

AMPS sensor node have

been quantified in Section V.

III. S OFTWARE E NERGY E STIMATION

Our experiments on the StrongARM SA-1100 [18] and

Hitachi SH-4 [19] microprocessors, two popular low-power

embedded processors, show that the variation in the current

consumption across instructions is quite small. A lot of

overheads are common across instructions and as a result the

overall current consumption of a program is a weak function

of the actual instruction stream and, to a first order, depends

only on the operating frequency and voltage. Second-order

variations do exist but were measured to be less than 7% for a

set of benchmark programs. Therefore, a complete instruction

level trace analysis is unnecessary and a simple cycle accurate

simulation can be used to estimate execution time and basic

statistics. We propose a simple fast technique to estimate

software energy and estimate second-order variations. Our

experiments indicate that our proposed model has accuracy

within 3% of actual measurements.

Authorized licensed use limited to: Politechnika Lodzka. Downloaded on January 14, 2010 at 20:08 from IEEE Xplore. Restrictions apply.

1046

IEEE TRANSACTIONS ON VERY LARGE SCALE INTEGRATION (VLSI) SYSTEMS, VOL. 11, NO. 6, DECEMBER 2003

Fig. 2.

StrongARM SA-1100 instruction set current consumption.

Fig. 3.

Hitachi SH-4 instruction set current consumption.

A. Instruction Energy Profiling

were performed using the ammeter built into the variable power

supply. The instruction and data caches were enabled before the

programs were executed. To measure the current that is drawn

by a subroutine, the subroutine was placed inside a loop with

multiple iterations until a stable value of current was measured.

Fig. 2 shows the current consumption of all the instructions

of the ARM instruction set on the SA-1100. Each of the 33

current values are themselves the averages of the various

addressing modes and inputs in which the instruction can be

executed accounting for a total of about 280 data points. The

important point to observe is that the current consumption is

Our experimental setup consisted of the Brutus SA-1100 De-

sign Verification Platform, which is essentially the StrongARM

SA-1100 microprocessor connected to a PC using a serial link.

It can operate from 59–206 MHz, with a corresponding core

supply voltage of 0.8–1.5 V. The power supply to the Strong-

ARM core was provided externally through a variable voltage

source with the I/O pads running at a fixed supply voltage. The

ARM project manager (APM) was used to debug, compile, and

execute software on the StrongARM. Current measurements

Authorized licensed use limited to: Politechnika Lodzka. Downloaded on January 14, 2010 at 20:08 from IEEE Xplore. Restrictions apply.

SINHA et al. : INSTRUCTION LEVEL AND OPERATING SYSTEM PROFILING FOR ENERGY EXPOSED SOFTWARE

1047

Fig. 4.

Current variations within instructions of the StrongARM.

quite uniform. On an average, arithmetic and logical instruc-

tions consume 0.178 A, multiplies 0.196 A, loads 0.196 A,

stores 0.229 A, while the other instructions consume about

0.170 A. The total variation in current consumption is 0.072 A,

which is 38% of the overall average current consumption.

Fig. 3 shows the instruction current consumption, measured

using a similar setup, for the Hitachi SH-4 processor running

at 2.0 V core power supply. The average instruction current is

0.29 A, with a variation of 0.11 A, which once again is 38%

of the average. The current variation within an instruction

(as a function of addressing modes and data) is even smaller.

Fig. 4 shows the current consumption of the StrongARM for

three different instructions as a function of various addressing

modes and data. In general, we observed that to a first order,

the instruction current consumptions are independent of the

addressing modes or operands.

Based on the previous discussion, it is reasonable to conclude

that the common overheads (such as caches, decode logic, etc.)

in contemporary microprocessors are large and overshadow any

instruction specific variations. Therefore, estimating software

energy consumption with an elaborate instruction trace and in-

terinstruction analysis may not be required for estimating the

energy consumption of software to a reasonable accuracy.

and frequency of the processor. The first-order software energy

estimation model is then simply

(1)

where

is the supply voltage and

is the program execution

time.

2) Second-Order Model: While the current variation across

programs is quite small in the StrongARM, it might be signif-

icant in datapath dominated processors. For example, the cur-

rent consumption of the multiply instruction in DSPs will be far

greater than the current consumption of other instructions. In

such cases, a simple model like (1) will have significant error.

The following second-order model is proposed.

Let denote the energy differentiated

instruction classes in a processor. Energy differentiated instruc-

tion classes are partitions of the instruction set such that the av-

erage current consumption of any class is significantly different

from that of another class and the current variation between in-

structions within the same class is small. Class partitions can

also be done on the basis of different cycles, e.g., instruction,

data access, etc. Let denote the fraction of total cycles in a

given program that can be attributed to instructions/cycles in the

class

, i.e.,

. The proposed second-order current

consumption equation is

B. Software Energy Profiling

1) First-Order Model: While the instruction level current

consumption has a variation of about 38%, the variation of the

current consumption in programs is much less. Fig. 5 shows the

current consumption of six different benchmark programs at dif-

ferent supply voltage and frequency levels in the StrongARM.

The maximum current variation is less than 8%. This implies

that to a first order, current consumption of a piece of code is in-

dependent of the code and depends only on the operating voltage

(2)

where

are a set of weights. Let

represent the vector

. Let

represent a

set of

benchmark programs,

denote the cycle fractions

vector for program

i.e.,

and

denote

Authorized licensed use limited to: Politechnika Lodzka. Downloaded on January 14, 2010 at 20:08 from IEEE Xplore. Restrictions apply.

1048

IEEE TRANSACTIONS ON VERY LARGE SCALE INTEGRATION (VLSI) SYSTEMS, VOL. 11, NO. 6, DECEMBER 2003

Fig. 5.

Program current consumption as a function of operating point.

its average current consumption. Based on (2), we can express

the current vector

TABLE I

W EIGHTING F ACTORS FOR K=4 ON THE S TRONG ARM

in the following form

(3)

where is the average current for the

programs, is a matrix with as the th row. The weights

can be solved for in a least mean square sense using the pseudo-

inverse

The weighting factors can be interpreted as follows. For

programs where instruction cycles and nonsequential memory

accesses dominate, the current consumption is higher than the

average current at that operating point. Internal cycles and

sequential memory access dominated programs will have a

lower than average current consumption. The current prediction

error with the second-order model can be reduced to less than

2%. The advantage is that this accuracy comes virtually free.

No elaborate instruction level profiling is required. Such cycle

counts as the ones shown in Table I are easily obtained using

simulators/debuggers available with standard processors. Fig. 7

shows the overall improvement of current prediction accuracy

on 66 benchmark functions. It can be seen that the current

prediction is better in every case (the maximum error of 4.7%

using a first order model is reduced to 2.3%). The effectiveness

of the current weighting scheme will become more pronounced

in processors having a wider variation in average current

consumption.

(4)

If the instruction classes are a valid energy differentiated parti-

tion, the weighting vector will reflect the energy differenti-

ation. The maximum current prediction error will also go down

considerably.

On the StrongARM SA-1100, we partitioned the cycles into 4

classes: 1) pure instruction cycles; 2) sequential memory access

(accesses which are related to previous ones); 3) nonsequential

accesses; and 4) internal cycles. The reader is referred to [29] for

mode details. Current measurements were done for six bench-

mark programs running at all possible frequency and voltage

combinations. The weighting vector is shown in Table I. The av-

erage current drawn at each operating frequency of the Strong-

ARM is shown in Fig. 6. The StrongARM operates at 11 dis-

crete frequency levels. The minimum operating voltage required

is also shown and is almost linear with frequency. In fact, the

normalized operating voltage and frequency are approximately

related as

C. Leakage Energy Modeling

With increasing trends toward low-power design, supply

voltages are constantly being lowered as an effective way

to reduce power consumption. However, to satisfy the ever

demanding performance requirements, the threshold voltage is

(5)

where

and

are normalized to their respective max-

imum values.

Authorized licensed use limited to: Politechnika Lodzka. Downloaded on January 14, 2010 at 20:08 from IEEE Xplore. Restrictions apply.

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: