A Top-to-Bottom View: Energy Analysis for Mobile Application Source Code

Transcription

1 A Top-to-Bottom View: Energy Anaysis for Mobie Appication Source Code Xueiang Li John P. Gaagher Roskide University Emai: {xueiang, arxiv: v1 [cs.oh] 14 Oct 2015 Abstract Energy efficiency significanty infuences user experience of battery-driven devices such as smartphones and tabets. The goa of an energy mode of source code is to ay a foundation for energy-saving techniques from architecture to software deveopment. The chaenge is inking hardware energy consumption to the high-eve appication source code, considering the compex run-time context, such as thread scheduing, user inputs and the abstraction of the virtua machine. Traditiona energy modeing is bottom-to-top, but this approach faces obstaces when software consists of a number of abstract ayers. In this paper, we propose a top-to-bottom view. We focus on identifying vauabe information from the source code, which resuts in the idea of utiizing an intermediate representation, energy operation, to capture the energy characteristics. The experiment resuts show that the energy mode at such a high-eve can reduce the error margin to within 10% and enabe energy breakdown at function-eve, which heps deveopers understand the energyreated features of the code. I. INTRODUCTION In February of 2015, the penetration of smartphones was about 75% in the U.S. This figure is expected to reach 85% by December 2015 [5]. With the improvement of hardware processing capabiity and software deveopment environment, the appications are becoming more heavier and PC-ike. At the same time, users are annoyed by the imited battery capacity, the parae-running appications coud easiy drain the fuy-charged battery within 24 hours. Even worse, current software deveopment is performed in an energy-obivious manner. Throughout the engineering ifecyce, deveopers are bind to the energy usage of the code written by themseves. On the other hand, it has been estimated that energy saving by a factor of as much as three to five coud be achieved soey by software optimization [7]. To reaize this, the first step is to understand the energy distribution among different parts of the source code. Energy modeing bridges the gap between source code and hardware energy consumption. However, traditiona bottomto-top modeing methodoogy [18][6][16][19] faces obstaces when the software stack of the system consists of a number of abstract ayers. On the Android patform, say, the source code is in Java and transated to Java byte-code, then further to Davik [3] (simpified Java virtua machine for Android) bytecode, native code and machine code and finay has chance to execute on the processors. Consequenty, the modeing task has to characterize the inks among a the ayers. An aternative approach is from above to beow, and aims to construct a mode directy for the source code, without any expicit ow-eve mode. Intuitivey, given a target device and power management strategy, the source code competey determines the amount of energy consumed. We thus identify the basic energy-consuming operations from the source code and find the correations to energy cost by anayzing a arge amount of execution cases. The resuting energy mode impicity incudes the effect of a the ayers of the software stack down to the hardware. The contributions of this work are as foows. The inference mode is based on energy operations instead of bocks or subroutines, which makes it versatie to the source code that differs from the target code. The specific system profie is not required, which is enabed by adequate information identified from the source code and statistica anaysis. We appy the mode to a game engine to acquire the energy breakdown that indicates the energy hotspots and energy-saving potentias in the source code. Our target patform is an Android deveopment board with two ARM quad-core CPUs, and the empoyed source code is a game engine which is for constructing games, demos and other interactive appications. The resut shows that the inference mode achieves accuracy of about 92%. Based on this mode, we are capabe of capturing energy properties of the source code, such as a profie of energy breakdown over code sections. Firsty, in Sections II-A, II-B and II-C, we propose an approach to identifying energy operations from source code. After that, the modeing framework is detaied in Section II-E. The impementation on the physica device is shown in Section III, iustrating the experimenta setup, inference accuracy and finay energy anaysis on a game engine. II. CODE TO ENERGY We buid the energy mode by anayzing a arge set of execution cases. The brief procedure of mapping the source code to energy is 1) identifying operations from the code 2) obtaining the precise execution path for each case, 3) producing the operation ist according to 1) and 2), 4) tracing the corresponding power consumption, 5) abeing ists with the energy cost and 6) empoying the abeed data to train the energy mode. Three factors pay significant roes in buiding the inference mode, which are the obtaining of execution-path, the definition of energy operation and mode training. In the foowing sections, we wi iustrate how to accuratey acquire executed

2 TABLE I: Basic Energy Operations Type Arithmetic Booean Comparison Bitwise Reference Function Contro Others Operation Addition, Subtraction, Increment Mutipication, Division, Decrement And, Or, Not Greater, Less, Equa Greater or equa, Less or equa BitAnd, BitOr, SignedBitShiftRight SignedBitShiftLeft Array reference, Fied reference Argument passing, Returning vaue Bock goto, Function Invocation Decaration, Type conversion (a) for oop (b) whie oop Fig. 1: Bock division of for and whie oops in contro fow graph. code points, which operations we identify from the source code and approaches in mode construction. A. Bock Division We design a variety of execution cases to guarantee most corners in the source code are abe to be covered. Not ony the breadth of code coverage, the user interaction is aso a significant dimension in the design space. As game appications are highy interactive, distinct input sequences resut in huge varieties. The detais of case design wi be presented in Section III-B. Definition 1: A bock is a set of gathered statements. Each node (statement) in a bock has ony one in-edge and one outedge in the contro fow graph, but the start point of the bock coud have more than one in-edge, the end point coud have more than one out-edge. A bock is a fixed execution unit. That means, aways if one part of the bock is processed, the rest certainy wi be executed. The concept is decared in Definition 1. We choose the bock as our basic tracing unit because tracing statements one by one has a vita impact on energy consuming and running time which damages the samping precision. On the other hand, functions or casses are unstabe execution unit, since we can not point out which certain parts of the function or cass wi be active during run time. For individua syntax structures, we dea with bock division case by case. For oop an whie oop are taken for exampes as shown in Figure 1. In a for oop, the header usuay has three segments which are initiaization, booean and update. According to Definition 1, the segments are divided into three different bocks. Foowing the same ogic, we set the whie header itsef as a bock. The compete set of reached code points is acquired by recording the executions of bocks. We instrument the source code with a og instruction at the beginning of each bocks. It generates a bock ID and a time stamp as one record in the og fie which wi be anayzed in ater stage to obtain the operation ist. As shown in Section II-E, one execution case produces one operation ist, which is one exampe for the mode training. Cass ArrayList GL10 Math FoatBuffer B. Basic Energy Operations TABLE II: Library Functions Fuction add, get, size, isempty, remove gbindtexture, gdisabecientstate gdraweements, genabecientstate gmutmatrixf, gtexcoordpointer gpopmatrix, gpushmatrix gtexparameterx, gvertexpointer max, pow, sqrt, random position, put It is impossibe to characterize the energy cost straighty based on individua statements because they varies argey, any pair of statements in the code are probaby distinct. An arithmetic expression, say, coud have two operators or three or more which coud be additions or mutipications or mixed. In contrast, if we go to the function eve, the mode wi be restricted to the domain of the target source code, since it s unikey to find identica functions in different appications. We empoy the energy operation as the basic modeing unit, such as arithmetic operations, comparison operations, method invocations etc. At the end, we in fact mode the energy of individua operations. The entire energy consumption is made up of the cost of a operations in the code. To carify, the operations are grouped into eight casses as shown in Tabe I. These operations can aways refer to basic virtua machine instructions. For exampe, the mutipication with integer operands is impemented by the imu instruction in Java Virtua Machine (JVM) instruction set [4]. The bock goto corresponds to the jsr instruction whose job is eading the CPU to an aimed subroutine. One machine instruction is using a certain set of hardware components, which resuts in approximatey the same energy cost. It is worth noting that the energy operation is an abstract concept, not ike the basic instructions in JVM or Davik Virtua Machine. It is an effective intermediate representation to bridge the source code to machine instructions, further to energy consumption, shown in the evauation resut. In the impementation (Section III), the operation is formaized as, for exampe, addition int int, standing for the addition operation with two int operands. So the hypothesis of this mode is that, the types of operation and operands provide sufficient information to estimate the average energy cost.

3 measuring. For the second run, we ony trace power and disabe the og instructions. The path and power obtaining are spit because the og instructions take up a proportion of the entire energy consumption that coud not be negected. C. Data Coection Fig. 2: Data coection fow. The generic view of the data coection fow is dispayed in Figure 2. We gather the active bocks from the execution path, and meanwhie create a dictionary showing the executions of operations for individua bocks. Mapping the active bocks to the dictionary, the executions of each operations are summed. As a resut, we get the operation ist for each execution case. The concrete cacuation is as foowing. We deveop a parser to extract the energy operations from the source code. Each of them is abeed with the ID of the bock where it resides. Note that, in the mode-buiding stage one exampe of training data corresponds to one execution case, a one-on-one reation. One record consists of the numbers of executions of individua ops which are figured up according to Equation (1). BLK(op i ) is the set of bocks that contain op i. N o (op i, bock j ) means the occurrence of op i in bock j. N e (bock j ) is the executions of bock j. Basicay, the executions of op i is equivaent to the sum of the products of N e (bock j ) and N o (op i, bock j ) for a the bocks containing op i. N e (op i ) = bock j BLK(op i) {Ne (bock j ) N o (op i, bock j )} where op i Energy Ops Android appications utiize a arge diversity of Android s APIs and Java ibrary casses where the fine-grained execution path is hard to capture. On the other hand, ony a sma proportion is frequenty used during run-time. We ist the highy-used ibrary functions in tabe II, which are deemed to be specia energy operations in the training stage. In particuar, the GL10 cass is the key interface for appications to impement their graphic computing. D. Power Tracing In the experimenta stage, each execution case is run twice. For the first run, we record the execution path without power (1) E = tn t 0 where power(t) dt n power(t i ) i (2) i=1 t 0 t 1 t 2 t n 1 t n The power trace is acquired by the measurement equipment, after which we approximate the energy cost (E) by cacuating the integra of power, as shown in Equation 2. p = power(t) is the power-vs-time function, so power(t i ) is the measured power vaue at time stamp t i. i equas to t i t i 1, which is the interva between two sequentia sampings. E. Mode Construction The aimed mode is formaized in Equation 3. The entire energy consumption consists of three parts. The first is the sum of W opi N e (op i ) (the weight of the operation times the execution number), where op i Energy Ops. The second is W funci N e (func i ), (the weight of the ibrary function times the execution number), where func i Lib F uncs. Notice that the ide costs of individua cases are different, since they are executed in distinct sequences of inputs, and the engths of sessions are aso varying. So we measure the ide cost for individua cases. E = op i Energy Ops Wopi N e (op i ) (3) func i Lib F uncs + Wfunci N e (func i ) + Ide Cost The mode construction is based on regression anaysis, finding out the correation between energy operations and costs from a arge amount of data. We set out the coected data in the foowing matrices. The eftmost one (N) is the execution numbers of operations (incuding energy operations and ibrary functions) in m execution cases, which is observed by ogging and cacuating, as shown in Section II. Each row indicates one execution case. The vector ( w) in the midde contains the weights of operations, which are the vaues we are aiming to obtain. The vector ( e) on the right of equation mark is the measured energy cost. So for each execution case, the energy cost is the sum of the weighted operations. It shoud be noticed that the energy cost has excuded the ide cost which is measured when no appication workoad is being processed. n (1) 1 n (1) 2... n (1) n (2) 1 n (2) 2... n (2) n (m 1) 2... n (m 1) n (m) 1 n (m) 2... n (m) n (m 1) w 1 w 2... w = e 1 e 2... e m 1 e m Inevitaby, execution tracing and power measurement are not absoutey accurate. Meanwhie, the energy mode is not

4 exacty subject to the inear property. As a resut, the equation above is unsovabe since the vector e is out of the coumn space of N. To address this probem, we empoy the weknown gradient descent agorithm [14] to approximate the vaues of w. The eements of w are randomy set initiay and then improved by the gradient descent agorithm step by step. We first introduce the error function J (Equation 4) which indicates the quaity of the mode. The smaer J is, the better the mode is. n (i) is the ith row in N, w is the midde vector above. n (i) w is the predicted energy cost for the ith execution case, e (i) is the observed energy cost. J is the sum of the squared errors of a the execution cases, which is afterwards divided by 2m to get the average vaues. The reason why 2m is appied, but not m, is that 2m is convenient for the derivative computation ater. So the smaer J is, the better w is. J(w 1, w 2,...w ) = 1 2m m ( n (i) w e (i) ) 2 (4) i=1 The idea of gradient descent is to minimize J by repeatedy updating each eement in w with Equation 5 unti convergence. The partia derivative of J function on w j gives the direction in which increasing or decreasing w j wi cut down J. This updating is appied to every eements of w in each iteration. The vaue α determines how arge the step is in each iteration. If it is too arge, the extremum vaue possiby wi be missed; if too tiny, the minimizing process wi be rather timeconsuming. It needs to be manuay tuned. Theoreticay, the gradient descent agorithm coud ony find the oca optima vaue. In practice, the initia vaues in w are randomy set severa times to ook for the goba optimization. w j := w j α J(w 1,...w j,...w ) w j (5) = w j α 1 m m ( n (i) w) n (i) i=1 j = 1, 2,... III. EXPERIMENT Our modeing framework is impemented on the physica device. We evauate the inference accuracy in a set of carefuy designed cases and demonstrate the energy-saving opportunities in the source code of a game engine. A. Target Device & Power Measurement Experiment target: Odroid-XU+E deveopment board [15]. It possesses two ARM quad-core CPUs, Cortex-A15 with 2.0Ghz cock rate and Cortex-A7 with 1.5Ghz. The eight cores are grouped into four pairs. Each pair consists of one big and one sma core. So in the view of operation system, there are four ogic cores. In our experiment, we turn off the sma cores and ony run workoad on big cores at a fixed cock frequency of 1.1Ghz. This is for removing the infuences of votage, cock rate and CPU performance on power usage. j Average Inference Error 18% 16% 14% 12% 10% 8% 6% 4% 2% 0% Training Set Test Set Correa<on Threshod Best Fit Fig. 4: The effect of correation threshod on the inference error. Power Measurement: Odroid-XU+E has a buit-in power monitor too to measure the votage and current of CPUs with a samping frequency of 30Hz and updates the readings in a og fie. We write a script to obtain the readings from the fie every 0.1 second. In the execution case, we run the script on an ide core to minimize its infuence on the appication. B. Source Code & Case Design The target source code is the Cocos2d-Android [2] game engine, a framework for buiding games, demos and other interactive appications. It aso impements a fuy-featured physics engine. The game is one of the main appications on mobie phones, which has deveoped more and more PC-gameike, requiring a high CPU performance. The energy modeing and anaysis research in this paper show the opportunities to improve the source code and guide the software deveopment towards energy efficiency. We design the Cick & move scenario, where the sprite (the character in the game) moves to the position where the tap occurs. We deveop a diversity of execution cases to simuate the game scenarios under different sequences of user inputs. We script with the Android Debug Bridge [1] (ADB), a command ine too connecting target device to the host, to automaticay feed the input sequences to the target board. 10 input sequences with distinct tap positions and intervas are inputted in the scenario. So one input sequence and one certain set of bocks form one execution case. For each case, we run it 10 times and compute the average vaues of the data for the modeing. We aso try to vary the executions of individua bocks, which is reaized by removing different sets of bocks in each execution case. The probem is that a certain amount of bocks are critica to the functionaity of the game engine, so we avoid removing them in the design stage. C. Inference Accuracy The key point of case-design is to vary the executions of individua bocks. By doing this, we are abe to enarge the coumn space of the N matrix (in Section II-E) to raise the

5 3.0E+04 Error Measured Predicted Error Measured Predicted 4.5E E+04 Energy Consump7on (w s) 2.0E E E E E+00 Energy Consump7on (w s) 3.5E E E E E+03 Training Cases - 5.0E+02 Test Cases Fig. 3: The predicted, observed energy consumption in training and test cases. The bars show the inference error. possibiities to sove a the vaues in w. We try to achieve it by commenting out different sets of bocks in each execution case. With the coected data in training cases, we obtain the approximate w. The execution cases are divided to training and test cases, which appy the same design principe, varying the executions of bocks. The data coection stage is quite time-consuming. 200 execution cases need about 70 hours, so we set the sessions of test cases shorter than those of training cases to cover more potentia corners. In the impementation, we have 190 training cases and 300 test cases. In the beginning, the mode performs much better in training cases than in test cases. We find that in most situations a set of energy operations are executed sequentiay, for exampe, the comparison operations are aways foowed by a bock goto operation, which causes redundant inputs for the mode. To sette this, we appy an feature seection procedure. According to the training data, we put the operation with strong positive inear execution correations in the same group. The cov(x,y) std(x) std(y) correation is, which is the covariance over the product of the standard deviations of two variabes (operation executions). The correation coser to 1 means stronger inear reation between two variabes. Operations above an correation threshod are grouped together and treated as one operation for the mode. In Figure 4, we can see the effect of correation threshod on the inference error in training and test sets. When the grouping condition (the threshod) is more strict (higher), ess operations are grouped, the error rate is decreasing a aong, because more inputs aways mean more information for prediction. On the other hand, the inference error in test set goes down first and incines up ater and exceeds the other ine from the threshod of 0.97 due to the reason we discussed above. We choose the grouping threshod as the crossing point (0.97) in Figure 4. Figure 3 demonstrates the inference error in training and test sets, which is within 10%. D. Energy Breakdown Depending on the functionaity, the source code is divided into eight sections: Update, Action, Frame Rate, Show Input 6% Others 12% Draw 8% Show FPS 13% Frame Rate 15% Update 31% Ac-on 15% Fig. 6: Energy breakdown of the code. FPS, Draw, Po, Input and Others. At run-time, the main job of the game engine is cacuating information such as the position, rotation of the animation, repeatedy for every frame. Each section is dedicated to one particuar job. The Update is responsibe to aunch and manage the updating for a the eements (ike the character, the scene and the text and so on) in the frame. The section of Draw adapts a the image resources to painting. The Action computes the motion parameters, such as position, rotation, scae, skew of the eements. Namey, the Frame Rate contros the showing rate of frames. The Show FPS dispays the frame rate on the screen. The Input deas with user inputs by checking the I/O devices frequenty. The Others means the rest part of the code. To iustrate the features of code sections, we can refer to the run-time executions of different energy operations in the code sections, as shown in Figure 5, in which the execution numbers are normaized to their average vaue among the code sections. Since the Update does the management work, it incurs the majority of the contro operations, ike booean, comparison, bock goto and method invocation operations. The Action computes a ot of

6 Array List Number of Execu.ons (Normaized) Ac.on Draw Input Frame Rate Update Show FPS Others Math Add Sub Mu.pica.on Division Booean BockGoto Method Inovca.on Comparison Parameter Fig. 5: Run-time executions of operations in the code sections. arithmetic operations. We aso see that Show FPS possesses the most mutipication operations, Frame Rate has the most division operations. And the Input empoys a sma amount of bock go, comparison and method invocation operations. We put the code sections into the inference mode and output the energy breakdown shown in Figure 6. The resut indicates the that Update section takes up 31% energy usage because of its huge workoad on management. A percentage of 30% goes to Action and Frame Rate which execute arithmetic operations to reaize the animation and contro the frame rate. The Show FPS consumes 13% as a resut of high division computation. And Draw uses 8% due to the arge amount of mutipication operations. The above shows that, based on the inference mode, we are abe to obtain the energy breakdown and seek out the sources of the energy usage, etting them put more efforts on the main energy consumers. IV. RELATED WORK From the hardware side, the effort of energy modeing research has been put on circuits-eve (see the survey [13]), gate-eve [12] [11] and register-transfer-eve [9]. On the other hand, the researcher s focus has been moved onto high-eve modeings, such as software and behaviora eves [10]. Energy modeing techniques on the software start with instruction-eve, which cacuates the sum of energy consumption of basic instructions and transition overheads [18] [6]. Gang et a. [16] base the mode on function-eve whie considering the effects of cache misses and pipeine stas on functions. T. K. Tan et a. [17] introduce regression anaysis to the high-eve software energy modeing. Shuai et a. [8] appy program anaysis to the appication-eve mode construction, requiring the specific energy profie of the target system. V. CONCLUSION In contrast, we expore the inverse idea which is identifying abstract energy operations from source code and correating the operations to the energy cost by case anaysis. Thus our mode does not require the profie of target system and more fexibe to various pieces and types of code. The mode is aso capabe to hep produce the energy breakdown of the code to direct the deveoper s effort on energy efficiency. REFERENCES [1] Android Debug Bridge. [2] Cocos2d-Android. [3] Davik Virtua Machine. [4] Java Virtua Machine Instruction Set. [5] Report: U.S. Smartphone Penetration Now At 75 Percent. percent , [6] C. Brandoese, W. Fomacian, F. Saice, and D. Sciuto. An instructioneve functionaity-based energy estimation mode for 32-bits microprocessors. In Design Automation Conference, Proceedings 2000, pages , [7] C. Edwards. Lack of software support marks the ow power scorecard at dac. In Eectronics Weeky., pages 15 21, June [8] S. Hao, D. Li, W. G. J. Hafond, and R. Govindan. Estimating mobie appication energy consumption using program anaysis. In Proceedings of the 2013 Internationa Conference on Software Engineering, ICSE 13, pages , Piscataway, NJ, USA, IEEE Press. [9] C.-T. Hsieh, Q. Wu, C.-S. Ding, and M. Pedram. Statistica samping and regression anaysis for rt-eve power evauation. In Computer-Aided Design, ICCAD-96. Digest of Technica Papers., 1996 IEEE/ACM Internationa Conference on, pages , Nov [10] E. Macii, M. Pedram, and F. Somenzi. High-eve power modeing, estimation, and optimization. Computer-Aided Design of Integrated Circuits and Systems, IEEE Transactions on, 17(11): , Nov [11] R. Marcuescu, D. Marcuescu, and M. Pedram. Adaptive modes for input data compaction for power simuators. In Design Automation Conference, Proceedings of the ASP-DAC 97 Asia and South Pacific, pages , Jan [12] F. Najm. Transition density: a new measure of activity in digita circuits. Computer-Aided Design of Integrated Circuits and Systems, IEEE Transactions on, 12(2): , Feb [13] F. Najm. A survey of power estimation techniques in vsi circuits. Very Large Scae Integration (VLSI) Systems, IEEE Transactions on, 2(4): , Dec [14] A. Ng. CS229 ecture notes. notes1.pdf, [15] Odroid. Odroid-XUE. [16] G. Qu, N. Kawabe, K. Usarni, and M. Potkonjak. Function-eve power estimation methodoogy for microprocessors. In Design Automation Conference, Proceedings 2000, pages , [17] T. Tan, A. Raghunathan, G. Lakshminarayana, and N. Jha. High-eve software energy macro-modeing. In Design Automation Conference, Proceedings, pages , [18] V. Tiwari, S. Maik, and A. Wofe. Power anaysis of embedded software: a first step towards software power minimization. Very Large Scae Integration (VLSI) Systems, IEEE Transactions on, 2(4): , Dec [19] T. Šimunić, L. Benini, G. De Michei, and M. Hans. Source code optimization and profiing of energy consumption in embedded systems. In Proceedings of the 13th Internationa Symposium on System Synthesis, ISSS 00, pages , Washington, DC, USA, IEEE Computer Society.