SEEP: Exploiting Symbolic Execution forEnergy-Aware Programming

Timo Hönig, Christopher Eibel, Rüdiger Kapitza, and Wolfgang Schröder-PreikschatFriedrich–Alexander University Erlangen–Nuremberg{thoenig,ceibel,rrkapitz,wosch}@cs.fau.de

ABSTRACTIn recent years, there has been a rapid evolution ofenergy-aware computing systems (e.g., mobile de-vices, wireless sensor nodes), as still rising systemcomplexity and increasing user demands make en-ergy a permanently scarce resource. While staticand dynamic optimizations for energy-aware execu-tion have been massively explored, writing energy-efficient programs in the first place has only receivedlimited attention.

This paper proposes SEEP, a framework whichexploits symbolic execution and platform-specificenergy profiles to provide the basis for energy-awareprogramming. More specifically, the framework pro-vides developers with information about the energydemand of their code at hand, even for the invoca-tion of library functions and in settings with mul-tiple possibly strongly heterogeneous target plat-forms. This equips developers with the necessaryknowledge to take energy demand into account dur-ing the task of writing programs.

1. INTRODUCTIONEnergy efficiency is an essential goal of today’s

mobile and wireless systems and demands for a tightinteraction between the system software (i.e., theoperating system) and the hardware. In order toachieve this goal, various distinct approaches suchas dynamic voltage and frequency scaling [1, 2],sleep states [3, 4], and resource accounting [5, 6]have been proposed. In contrast to these runtime-driven approaches, energy-aware compilers assist inoptimizing code prior to execution. In particular,

loop optimizations [7, 8] and architecture-specificinstruction set extensions [9, 10] have proven to beeffective to save energy. In addition to these staticand dynamic optimizations for energy-aware execu-tion there is the option of energy-aware program-ming that aids developers to implement energy-effi-cient programs in the first place. Cooperative I/O,for example, enables developers to specify deadlinesfor I/O operations in order to permit energy-efficientdata access [11]. More generic are recent proposalsfor programming languages that feature approxima-tion techniques to cut down computational costs,thereby leading to energy savings [12, 13].

In accordance with these recent works we see greatpotential in energy-aware programming. At present,however, writing energy-efficient programs is stillcomplicated as developers are not aware of the en-ergy demand of their code at hand. To estimate anapplication’s energy costs usually requires runningits code on a target platform while measuring the as-sociated power consumption. However, a single iter-ation is inconclusive as a specific control flow graphof the application is selected which might have ei-ther a high or low energy demand compared to theaverage execution costs. Accordingly, multiple testruns with diverse input sets are required. At thesame time, results of such measurement series areprone to have a high amount of jitter as unsettledbackground activities in user and kernel space havenon-deterministic impact on the results.

While it is already difficult and time consumingto determine the energy demand for a single plat-form, the ever-increasing number of different hard-ware platforms1 and the demand to implement ap-plications for a multitude of them renders it almostimpossible to carry out measurements for all plat-forms. Albeit developers might know the measuredenergy footprint for a given program on one plat-form, this knowledge often cannot be transferred

1The Linux kernel at present counts support for over 110different platforms, for example.

1

to another even if the other platform is similar,as the availability of hardware function units (e.g.,floating-point unit) can differ among them.

However, knowing the code’s impact on energycosts would allow developers to refactor applicationlogic to eliminate energy hotspots in the first place,for example, by disabling features when energy isscarce, simplifying code, or utilizing new energy-saving programming techniques [12, 13].

In sum, we consider high-level decisions in appli-cation design to be the crucial factor towards the en-ergy efficiency of software beyond its current level.

In this paper we present SEEP, a three-tier frame-work, which uses symbolic execution and platform-specific energy profiles to aid energy-aware program-ming. Our framework introduces a tool-based feed-back loop that equips developers with the energydemand of their program while developing. Thisis achieved by analyzing source code at creationtime and providing consumption profiles for arbi-trary pieces of code (e.g., libraries) that have beendetermined offline. To support heterogeneity at theplatform level after runtime analysis, energy costestimates are created using platform-specific energyprofiles. The combined results are then provided tothe developer enabling energy-aware programming.

Specifically, the key contributions presented inthis paper are threefold:• We present SEEP, a framework to enable energy-

aware programming. By exploiting symbolic execu-tion it provides developers with an early and mean-ingful insight into the expected energy consumptionof their program code.• Energy cost estimates provided by SEEP cover

diverse, heterogeneous target platforms, includingthose unavailable to developers.• Finally, we designed an easy to use hardware

which allows analog energy measurements. It is pre-sented in the evaluation section.

The paper is organized as follows. In Section 2we present the architecture of the SEEP framework.Section 3 discusses the implementation of our pro-totype, Section 4 outlines results from our evalua-tion, and Section 5 concludes and discusses futuredirections of our research.

2. ARCHITECTUREThe SEEP framework is composed of three main

components (see Figure 1) that are consecutivelyexecuted: a path explorer, a path-specific complex-ity explorer and a platform energy profile merger.

The path explorer analyzes program code by ap-plying symbolic execution techniques. It extracts allpossible code paths and their corresponding path

..

.Complexity Explorer

.

.Path Explorer

.

.Profile Merger

..Source Code

..Symbolic

Execution

..Code Paths

..Constraints.+

...Predefined Code

..Native

Trace..

Cross

Compile

..Basic Blocks

..Trace Counters.+

..Block Counter

...Energy Profile 1

.+

..Block Counter

...Energy Profile 2

.+

..Block Counter

...Energy Profile 3

.+

Figure 1: The SEEP architecture

constraints (i.e., branch conditions). This allowsus to further explore the code’s behavior at run-time as a next step. The path-specific complex-ity explorer automatically generates and executesspecially crafted binaries originating from the de-veloper’s program code, augmented with predefinedinputs as received by the path explorer component.To quantify the complexity of the code under inves-tigation, we then create execution traces. Duringthis tracing period SEEP increments a block counterfor every basic block (branchless sequence of code)each time it is executed. The final result of theblock counters unveil how often each basic block hasbeen executed during the tracing period. Finally,the profile merger component combines platform-specific energy profiles with the block counters ofthe tracing period to produce energy consumptionestimates for the analyzed code. Thereby, an esti-mate quantifies the energy demand at function leveland provides the same interface as the characterizedfunction. For concrete input parameters it thereforeestimates the expected energy demand.

To minimize the analysis time of the code underdevelopment, SEEP supports two modes of opera-tion: First, our framework analyzes the developer’sprogram code and explores its complexity and run-time behavior in terms of energy demand. Second,SEEP estimates the expected energy consumptionof library calls by means of energy consumption esti-mates. The latter have previously been determinedand are provided by the corresponding libraries.

3. IMPLEMENTATIONIn this section, we discuss the implementation of

SEEP. Our current prototype utilizes KLEE [14] asa basis for supporting symbolic execution. All tasksof the SEEP framework but the creation of energyprofiles are entirely architecture independent andplatform independent. Therefore, they can be per-formed on an arbitrary system different from thetarget platforms, which is convenient as the LLVMframework required by KLEE might not be avail-able for some of them.

2

3.1 Code Path ExplorationWith SEEP we exploit symbolic execution in two

distinct ways. First, executing code symbolicallyenables us to extract all possible code paths of theapplication under test (see Figure 2a). As sym-bolic execution is usually brought into action for un-attended discovery of defects in program code, test-ing frameworks based on symbolic execution pro-vide high code coverage by default.

Second, we extract the associated path constraints(i.e., branch conditions) which are specific for eachcode path. This information allows SEEP to createvarious predefined binaries for the extracted codepaths. It is important to note that different bina-ries of the very same code path can exhibit entirelydifferent energy costs, depending on the actual val-ues of their path constraints. That is why SEEPanalyzes multiple different predefined binaries foreach of the extracted code paths.

3.2 Crafting Path EntitiesEach code path has specific path constraints de-

fined by a set of parameter values under which it willbe executed. These path constraints in turn are acomposition of individual constraints which poten-tially have an impact on the energy costs of thegiven program code. First, at conditional branches,a constraint determines which branch of the codeis being taken. Second, path constraints have ashaping characteristic on the runtime behavior interms of energy demand, for example, depending onwhether the constraint in question is used as loopvariable or not. This information is required bySEEP to further reason about the diverging energyfootprint of two or more predefined binaries of thesame code path.

SEEP crafts predefined binaries for each code pathby exploiting the path constraints. Each predefinedbinary corresponds to exactly one code path andone predefined set of constraints, which are in effectfor the specific code path. These distinct entities arecalled path entities. The number of path entities foreach code path is determined by the amount of pathconstraints and their parameter range.

By using predefined input data for the path con-straints which are aligned to their corresponding pa-rameter range, for example, by using the upper andlower boundaries, and evenly distributed interme-diate values, SEEP crafts and analyzes a subset ofsignificant path entities. Figure 2b shows four dis-tinct path entities for code path B. The differingsize of the bottommost node denotes different run-time behavior in terms of energy demand comparedto the other entities of the same code path.

..

.

.

.

1: if i mod 2 then2: if i mod m then3: ... /* Path A */

4: else5: ... /* Path B */

6: end if7: else8: if i mod n then9: ... /* Path C */

10: else11: ... /* Path D */

12: end if13: end if

.2a..

..

.. ..

..

.. ..

.Path A

..

..

.. ..

..

.. ..

.Path B

..

..

.. ..

..

.. ..

.Path C

..

..

.. ..

..

.. ..

.Path D

.2b..

..

.. ..

..

.. ..

.Entity B1

..

..

.. ..

..

.. ..

.Entity B2

..

..

.. ..

..

.. ..

.Entity B3

..

..

.. ..

..

.. ..

.Entity B4

Figure 2: Code paths and code entities

3.3 Tracing Path EntitiesThe source code of path entities yet does not yield

any insight regarding the expected energy footprintof the binary on the target platforms. SEEP ad-dresses this during a twofold tracing phase, respect-ing the fact that target platforms indeed are likelyto be heterogeneous (e.g., different instruction sets).

At the beginning of the tracing phase, SEEP exe-cutes several distinct compilation runs. On the onehand, SEEP compiles the code of the path entitiesfor a powerful test system which is used for resource-intensive execution runs. On the other hand, thesame code is compiled for each architecture of thetarget platforms using a cross-compiler. Next, SEEPgenerates one runtime execution trace for each pathentity by executing them on the test system.

By means of execution traces SEEP can infer theruntime behavior on the target platform by exam-ining how often each basic block was executed. Forthis we have applied a similar strategy as describedin [15]. While the structure of the basic blocks islikely to differ, the number of times each basic blockis being executed is the same across all platforms.Accordingly, this information can be utilized to de-termine the energy demand for the target platformsas detailed in the next section.

3.4 Energy Profile FusionFor this step SEEP uses an energy profile specific

to each target platform. An energy profile speci-fies how much energy is being consumed for eachinstruction of the instruction set architecture. Sucha profile needs to be created only once per targetplatform and can be distributed independently.

As the structure of the basic blocks for the tar-get architectures are known as a result of the cross-compilation, each basic block’s energy consumptioncan be calculated by adding up the specified energyvalue of each instruction of the basic block utilizingthe platform’s energy profile. The expected energyconsumption is calculated by multiplying the blockcounters with the energy costs of the correspond-ing basic block. A path entity’s expected energyconsumption then is obtained by adding up theseinterim results. From the calculated energy costs

3

of the path entities SEEP interpolates the energycost for arbitrary path entities (i.e., path entitiesnot analyzed during the tracing phase). The finalresults are either passed to the developer or storedfor future reference (i.e., offline usage).

4. EVALUATIONFor carrying out the evaluation, we used two sim-

ilar hardware platforms, which—contrary to theircommon characteristics—have differing energy re-quirements. We have verified our approach witha test application consisting of three different codepaths, each of them being a unique composition ofcommonly used code fragments (e.g., loops, if-then-else, and switch statements). To obtain most accu-rate measurement results, we used a custom circuitboard allowing analog measurements.

First, we created energy profiles for each platform;second, we created energy consumption estimatesusing SEEP for each of the test application’s codepaths at different work loads. Third, we measuredseveral real execution runs and compared these withthe estimates calculated by our prototype.

4.1 Platforms under TestFor evaluation purposes we used two evaluation

boards with ARM processors of the OMAP3 micro-processor family (OMAP3530 and DM3730). Thesewidespread processors power a broad range of hand-sets, including devices built by manufacturers likeMotorola and Samsung. On our evaluation plat-forms, we intercept the main power rails of the powermanagement processor which allows us to exclu-sively measure the combined power consumption ofprocessor and main memory.

4.2 Energy Measurement SetupPower consumption is calculated from multiply-

ing the supply voltage by the drained current. Com-monly, this current is measured either directly usingan ammeter or indirectly by measuring the voltagedrop of the current flow at a shunt resistor using avoltmeter. Integrating the power consumption overtime then results in the energy usage. However,this integration step causes measurement errors asthe measurement device needs to sample. Whileoff-the-shelf multimeters only sample at a coupleof hertz, sample rates of the order of gigahertz arenot unusual for more expensive oscilloscopes. Yet,the measurement device needs to sample for provid-ing a measured value and the odds are that thereis momentary power consumption in between sam-ples, which will not be part of the result. Due tothis weakness of today’s best practices, we chose an

alternative approach initially proposed by Kostan-takos et al. [16] and designed a custom circuit boardbased on a current mirror. The unique characteris-tic of this circuit is that it allows energy measure-ments without error-prone sampling intervals. Wekept the basic concept untouched but dimensionedit for higher power drainage of our target hardware.

The measuring device works as follows. A cur-rent equivalent to the one drained by the deviceunder test is being generated and flows through acurrent mirror. Two capacitors under the control ofa flip-flop are being charged and discharged on analternating basis and the corresponding switchingevents of the flip-flop are counted. At the end of ameasurement series, the energy consumption is cal-culated under the knowledge of the duration of themeasurement series, the number of switching oper-ations, and the final potential of the last capacitorbeing charged.

In sum, our setup does not sample the measuredpower consumption, therefore enabling an analogmeasurement that leads to most accurate resultsas no power consumption goes unnoticed. Further-more, it can easily be monitored by an external sys-tem and has low acquisition costs.

4.3 Energy Profile GenerationFor each of the two evaluation platforms we have

created energy profiles stating the average energycost for each instruction. Both CPUs implement theCortex-A8 processor design and therefore share thesame instruction set (ARMv7). However, the pro-cessors have a different power consumption behav-ior as they are clocked at different speeds (720 MHzvs. 1 GHz) and their die is assembled with differentsemiconductor technology (65 nm vs. 45 nm).

In line with [17], we have measured the energyconsumption of the instructions by executing loopsof known length and recording the energy consump-tion for the total run. The average energy consump-tion of each instruction then is used for building theplatform’s energy profile. Although the DM3730 isalmost 300 MHz faster compared to the OMAP3530,its energy consumption is lower, which can be at-tributed to the enhanced semiconductor technology.

4.4 ResultsWe have executed ten path entities for each code

path of our test application. SEEP created two pathentities (see Section 3.2) using the upper and lowerbounds of the corresponding code path and eightintermediate path entities. Eventually, our frame-work interpolated the energy costs for all path en-tities of each code path.

4

..

.

.

.1 .2 .3 .4 .5 .6 .7 .8 .9 .10.0

.0.5

.1

.1.5

.2

.2.5

.3

.3.5

..Path A

..Path B..Path C

.Path Entity

.Ener

gyin

mJ

... ..SEEP. ..Measured

Figure 3: Energy Costs by Path Entity

Code path A exposes a constant energy consump-tion, as its path constraints are neither used in aloop construct nor does the code path vary its op-erations depending on the actual path constraints’values. In contrast, code path B and C show a linearand exponential energy consumption, respectively.In code path B, one of the path constraints impactsa loop construct as it is used as a loop test expres-sion for the inner-most loop. For code path C, anexponential amount of computing operations is be-ing executed depending on one of the values of theeffective path constraints.

To verify the correctness of SEEP, we measuredthe energy consumption whilst executing predefinedbinaries on the DM3730 platform. SEEP’s energyestimates and the measurement results are shownin Figure 3. Compared to the measurements, thepredicted energy consumption varies by 0.089 mJ ata max with an average deviation of 0.017 mJ.

5. CONCLUSION & FUTURE STEPSThis paper presented SEEP, a framework to aid

energy-aware programming. It exploits symbolic ex-ecution, selective run-time measurements, and plat-form-specific energy profiles to provide energy de-mand estimates during the task of programming.Despite its multi-platform support it is largely plat-form independent. In sum, we consider SEEP asa key component to make future software energy-efficient prior to deployment.

Today, SEEP provides accurate estimates for thebase energy demand of a program. We will extendthe framework regarding different aspects in orderto make it generally applicable. First, we will in-tegrate further system-specific characteristics intothe platform profiles. Especially energy consump-tion caused by I/O operations and network linksneed to be considered. Second, memory effects suchas cache misses [18], page faults, and varying mem-ory access modes [19] potentially have impact onthe energy consumption and thus need to be in-corporated. Besides, SEEP uses ongoing researchefforts targeted at expanding the scope of symbolic

execution [20]. Along with the aforementioned ex-tensions, these efforts assist us to construct real-world scenarios when executing program code sym-bolically. We envision the integration of SEEP intoexisting integrated development environments.

6. REFERENCES[1] M. Weiser, B. Welch, A. Demers, and S. Shenker. Schedul-

ing for reduced CPU energy. In Proc. of the 1st Conf. onOperating Systems Design and Implementation, 1994.

[2] A. Weissel and F. Bellosa. Process cruise control: Event-driven clock scaling for dynamic power management. InProc. of the 2002 Intl. Conference on Compilers, Archi-tecture, and Synthesis for Embedded Systems, 2002.

[3] L. A. Barroso and U. Holzle. The case for energy-proportional computing. IEEE Computer, 40(12), 2007.

[4] E. Le Sueur and G. Heiser. Slow down or sleep, that is thequestion. In Proc. of the USENIX ATC, 2011.

[5] H. Zeng, X. Fan, C. Ellis, A. Lebeck, and A. Vahdat.Ecosystem: Managing energy as a first class operating sys-tem resource. In Proc. of the 10th Conf. on ArchitecturalSupport for Prog. Lang. and Operating Systems, 2002.

[6] A. Kansal, F. Zhao, J. Liu, N. Kothari, and A. A. Bhat-tacharya. Virtual machine power metering and provisioning.In Proc. of the 1st Symp. on Cloud Computing, 2010.

[7] V. Delaluz, M. T. Kandemir, N. Vijaykrishnan, and M. J. Ir-win. Energy-oriented compiler optimizations for partitionedmemory architectures. In Proc. of the Conf. on Compilers,Architecture, and Synthesis for Embedded Systems, 2000.

[8] V. Delaluz, M. T. Kandemir, N. Vijaykrishnan, M. J. Irwin,A. Sivasubramaniam, and I. Kolcu. Compiler-directed arrayinterleaving for reducing energy in multi-bank memories. InProc. of the ASP Design Automation Conference, 2002.

[9] M. T. Kandemir, N. Vijaykrishnan, M. J. Irwin, and W. Ye.Influence of compiler optimizations on system power. InProc. of the 37th Annual Design Automation Conf., 2000.

[10] N. Vijaykrishnan, M. T. Kandemir, M. J. Irwin, H. S. Kim,and W. Ye. Energy-driven integrated hardware-software op-timizations using SimplePower. In Proc. of the 27th AnnualIntl. Symp. on Computer Architecture, 2000.

[11] A. Weissel, B. Beutel, and F. Bellosa. Cooperative I/O: Anovel I/O semantics for energy-aware applications. In Proc.of the Symp. on Operating Systems Design & Impl., 2002.

[12] A. Sampson, W. Dietl, E. Fortuna, D. Gnanapragasam,L. Ceze, and D. Grossman. EnerJ: Approximate data typesfor safe and general low-power computation. In Proc. of the2011 Conference on Prog. Lang. Design and Impl., 2011.

[13] W. Baek and T. Chilimbi. Green: A framework for support-ing energy-conscious programming using controlled approx-imation. In Proc. of the 2010 Conference on Prog. Lang.Design and Impl., 2010.

[14] C. Cadar, D. Dunbar, and D. Engler. KLEE: Unassistedand automatic generation of high-coverage tests for complexsystems programs. In Proc. of the 8th Symp. on OperatingSystems Design and Implementation, 2008.

[15] S. Penolazzi. A system-level framework for energy and per-formance estimation of system-on-chip architectures. PhDthesis, KTH, 2011.

[16] V. Konstantakos, A. Chatzigeorgiou, S. Nikolaidis, andT. Laopoulos. Energy consumption estimation in embed-ded systems. IEEE Transactions on Instrumentation andMeasurement, 57(4), 2008.

[17] V. Tiwari, S. Malik, A. Wolfe, and M. T.-C. Lee. Instructionlevel power analysis and optimization of software. Journalof VLSI Signal Processing, 13(2), 1996.

[18] B. F. Ramon, R. Doallo, and E. L. Zapata. Automatic ana-lytical modeling for the estimation of cache misses. In Intl.Conf. on Parallel Arch. & Compilation Techniques, 1999.

[19] N. D. Lane and A. T. Campbell. The influence of micropro-cessor instructions on the energy consumption of wirelesssensor networks. In Proc. of the 3rd Workshop on Embed-ded Networked Sensors, 2006.

[20] S. Bucur, V. Ureche, C. Zamfir, and G. Candea. Parallelsymbolic execution for automated real-world software test-ing. In Proc. of the EuroSys 2011 Conf., 2011.

5