On the Impact of PowerCap in Haskell, Java, and Python Luís Maia1,2,† , Marta Sá1,† , Inês Ferreira1,† , Simão Cunha1,† , Luís Silva1,† , Paulo Azevedo1,2,† and João Saraiva1,2,† 1 Department of Informatics, University of Minho, Portugal 2 HasLab/INESC TEC Abstract Historically, programming language performance focused on fast execution times. With the advent of cloud and edge computing, and the significant energy consumption of large data centers, energy efficiency has become a critical concern both for computer manufacturers and software developers. Despite the considerable efforts of the green software community in developing techniques and tools for analysing and optimising software energy consumption, there has been limited research on how imposing hardware-level energy constraints affects software energy efficiency. Moreover, prior research has demonstrated that the choice of programming language can significantly impact a program’s energy efficiency. This paper investigates the impact of CPU power capping on the energy consumption and execution time of programs written in Haskell, Java, and Python. Our preliminary results analysing well-established benchmarks indicate that while power capping does reduce energy consumption across all benchmarks, it also substantially increases execution time. These findings highlight the trade-offs between energy efficiency and runtime performance, offering insights for optimising software under energy constraints. Keywords Energy Efficiency, Programming Languages, Benchmark, PowerCap 1. Introduction most known and used programming languages are ranked according their energy performance. This ranking shows Programming languages provide powerful mechanisms to very interesting results, namely that slower/faster software improve the productivity of their programmers. Modern lan- languages consume less/more energy. The energy efficiency guages rely on powerful module and type systems, reusable ranking, however, was produced assuming no limit on the libraries, IDE, testing frameworks, etc. Such mechanisms energy usage by the operating system nor the hardware are built on top of advanced abstraction, thus relying on the that executed the programs written in the 28 languages. language compiler to produce efficient code. However, we know that by limiting energy consumption of In the last century, good performance in programming hardware we can reduce energy consumption. For example, languages was synonymous of fast code, that is to say, fast a driver when operating a car (the hardware) can reduce execution time. In this century, this reality has changed be- its fuel consumption by defining a limit on the engine Rev- cause the cost to run software became higher than the cost olutions Per Minute (RPM). Thus, an interesting question to build that same software [1]. In our age of cloud/edge that immediately arises is whether we can reduce the en- computing and large data centers the energy consumption ergy consumption of a program by just defining a limit on of software is a key concern for big tech and computer man- the energy used by the CPU. Energy consumption does not ufacturer companies, programming language designers, and depend only on execution time, as shown in the equation programmers. Software systems are implemented using pro- 𝐸𝑛𝑒𝑟𝑔𝑦 = 𝑇𝑖𝑚𝑒 × 𝑃𝑜𝑤𝑒𝑟 . In fact, this equation shows that gramming languages. As shown in [2], the energy efficiency we can reduce energy of program by reducing its execution of program can be drastically influenced by programming time and/or the power it uses. language used to develop it. In this paper we analyse the impact of limiting the power Although the green software community has done a con- of the CPU when executing programs in three different pro- siderable work on developing techniques and tools to anal- gramming languages, namely, Haskell, Java and Python.1 yse and optimise the energy consumption of software sys- For each language we considered well established bench- tems. Such techniques already provide knowledge on the mark frameworks, namely NoFib for Haskell [17], DaCapo energy efficiency of data structures [3, 4] and android lan- for Java [18] and pyPerformance for Python. We executed guage [5], the energy impact of different programming each benchmark in two situations: with and without a limit practices both in mobile [6, 7, 8] and desktop applica- on energy consumption. In both cases we monitored and tions [9, 10], the energy efficiency of applications within analysed the performance of each benchmark considering the same scope [11, 12], or even on how to predict energy energy consumption and execution time. Our very first consumption in several software systems [13, 14], among results show that by defining a power cap we do reduce several other works. energy consumption in all benchmarks. On the contrary, There is also recent work on analysing the energy effi- the execution time of the three benchmarks increases sig- ciency of programming languages [15, 2, 16], where 28 of the nificantly. This paper is organised as follows: Section 2 presents RAW’24: 3RD WORKSHOP ON RESOURCE AWARENESS OF SYSTEMS the methodology we follow to conduct our study. It briefly AND SOCIETY, July 02–05, 2024, Maribor, SI † presents the benchmarks, the use of the Intel’s RAPL and These authors contributed equally. RAPLCap energy framework, the calibration of the power- $ pg47422@alunos.uminho.pt (L. Maia); pg54084@alunos.uminho.pt cap and how we executed and measured the benchmarks. (M. Sá); pg53879@alunos.uminho.pt (I. Ferreira); simaopscunha@outlook.pt (S. Cunha); luis.m.peixoto@gmail.com 1 We considered these three languages because this research originated (L. Silva); pja@uminho.pt (P. Azevedo); saraiva@uminho.pt (J. Saraiva) from an exercise proposed in a MSc course on green software where © 2024 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribu- tion 4.0 International (CC BY 4.0). those languages are studied. CEUR ceur-ws.org Workshop ISSN 1613-0073 Proceedings In Section 3 we present and discuss the results of the three benchmarks. In Section 4 we present our conclusions. 2. Methodology 2.1. Benchmarks In order to analyse the impact of limiting the energy con- sumption while executing Haskell, Java and Python pro- grams, we consider well-established and widely used bench- mark frameworks developed for those three programming Figure 1: Power Cap Impact on Fibonacci’s Energy Consumption. languages. The benchmarks and the compilers/interpreters used in our study are: long f i b ( i n t n ) • Haskell language (compiler ghc 9.4.8): The nofib { i f ( n <= 0 ) return 0 ; Benchmark Suite of Haskell Programs [17].2 e l s e i f ( n = = 1 ) return 1 ; • Java language (compiler: Java Openjdk 11.0.22): The e l s e return f i b ( n − 1 ) + f i b ( n − 2 ) ; DaCapo Benchmark suite [18], version 23.11-chopin.3 } • Python language (interpreter: python 3.12.0): The Python Performance Benchmark Suite, version 1.11.0.4 In order to have significant energy and runtime measure- ments we execute this function to compute Fibonacci of 50. 2.2. Energy Measurements and Cap via Furthermore, we executed (ten times) this function using specific power cap values. RAPL The processor i7-7700hq has a TDP of 45Watts. With this For measuring the energy consumption, we used Intel’s in mind, there was a first set of power cap variables that Running Average Power Limit (RAPL) tool [19], which is went from -1 to 45 with a spacing of 5 between each value. capable of providing accurate energy estimates at a very The substantially better results were when power cap took fine-grained level, as it has already been proven [20]. RAPL a value between 5 and 20. To further analyse these results, has been used in many studies on green software and was a second attempt of trying to find the best power cap value the energy measurement framework used in defining the was made, this time with values -1, 20 and all withing 5 and ranking of programming languages [2, 16]. Moreover, the 15, where -1, which is when there is no power cap, and 20 ranking of languages provides programs/scripts built on top served to compare results with the remaining power caps. of RAPL that makes very easy to execute and monitor the In order to to make the results more robust, each iteration energy consumption of a (executable) program. of a power cap was ran ten times, and were then averaged. In our study we will reuse this (C-based) infrastructure In figure 1 we confirm that the power cap that yields the to execute and monitor the benchmarks and their programs best results for our purpose is power cap 12, as it proved to written in three languages. be the lowest energy consuming. From this moment, the Finally, RAPL also support a key ingredient for our study: only two power cap values that will in the following steps the possibility of defining a power limit on the CPU while are -1 (No power cap) and 12 (with power cap). executing a program [21]. In fact, RAPLCap5 provides a C interface for managing Intel RAPL power caps. Thus, we 2.4. Program Execution have extended the ranking energy monitoring infrastructure to allow the execution of a program under a given power As we mention before, we will use the ranking of program- cap. ming languages infrastructure to execute an monitor the energy consumption of the three benchmarks. Such infras- tructure has a key feature: there is no need to add intrusive 2.3. RAPL’s PowerCap calibration code, for example calls to RAPL API, to the programs we The RAPL and RAPLCap can be configured with different would like to monitor energy consumption. This infrastruc- values to limit the PowerCap of a specific CPU. Thus, when ture includes a C program, named energy, that uses system executing a program it is possible to define the (maximum) calls to execute the unchanged programs while measuring power used by the (intel) CPU. Different values for Power- the energy and time consumption via call to RAPL (and Cap can be used. Moreover, different intel CPUs may have the time library). The overhead caused by the usage of a the lowest energy consumption by using different Power- system call is insignificant as shown in [2, 24, 25]. Cap values. In order to know the value of the PowerCap Thus, to analyse the energy consumption of the bench- that produces the lowest energy consumption in a specific marks, we just use the benchmarks original makefiles to CPU, we need to compute it. Thus, we consider a calibration call the language compilers/interpreters with the defined phase where we execute with different RAPLcap values a optimisation’s flags. Then, we use the energy C program to computation intensive program and we compute the value execute each of the executable program of each benchmark. that produce the most energy efficient execution [22, 23]. This program is called from the command line as follows: Thus, we consider the following implementation of the sudo $ { c u s t o m _ p a t h } / RAPL / e n e r g y " . / Fibonacci number in the C language: benchmark_executable " $ ( 2 https://gitlab.haskell.org/ghc/nofib. Version available on January,2024. b e n c h m a r k _ l a n g u a g e ) $ ( benchmark ) $ 3 https://www.dacapobench.org/ ( NTIMES ) $ ( PowerCap ) $ 4 https://github.com/python/pyperformance 5 https://github.com/powercap/raplcap Its first argument is the executable program (of each although Python benchmarks have outliers they are not benchmark) to be executed and monitored. The follow- relevant in terms of number or value. ing two arguments are for naming purposes in the (csv) results output. Next argument is the number of runs for 3.2. Haskell nofib Benchmark each program. The final argument is the value of the power cap (-1 or 12, as mentioned before). To evaluate the impact of power cap on the variables Package In our study each benchmark’s program was executed and Time we started by creating two datasets: one with all with and without power cap. Each program was executed the measurements of Haskell benchmarks without power a total of 10 times to grant a good starting set of results. cap and another with all the measurements of the Haskell Moreover, between each iteration, a cool down to the afore- benchmarks with a power cap of 12. Figure 2 presents the mentioned mean CPU temperature is taken place to make energy and runtime measurements for each program of the sure each benchmark execution starts at the same CPU tem- nofib benchmark.7 Thus, for each program we associate two perature. In the ranking of programming [2] it was used a 1 bars: energy (in joules) on the left and runtime (in seconds) second sleep between executions. That may not be enough on the right. Moreover, each bar uses two colours to indicate for the CPU to be at the same temperature at each execu- the use or not of power cap. tion [26]. As we can observe in figure 2, all Haskell programs con- In order to make sure every iteration of each benchmark sume less energy when executed with power cap (dark blue starts on equal grounds, the mean temperature of the CPU is bar) when compared to the same program executed without taken, and after every run of a benchmark a cooling process a power cap. We can also see that power cap has a consider- is executed until the temperature of the CPU cools down able impact on execution time: all programs increase their to the point of the mean temperature. Once the CPU is execution time when using power cap (green bar). back to the mean temperature, it is able to execute another Figure 3 shows in more detail the energy reduction ob- benchmark. As a consequence, each execution of a program tained by each benchmark program with power cap. starts with the CPU at the same temperature. To obtain the mean temperature of the CPU, the library lm-sensors6 was used in the energy C program. 3. Results All studies were conducted on a desktop with the follow- ing specifications: Linux Ubuntu 2.04.4 LTS operating sys- tem, kernel version 4.8.0-22-generic, with 32GB of RAM, a Haswell Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz. Figure 3: Reduction in energy consumption (package) with the use of power cap for Haskell benchmarks. 3.1. Treatment of the datasets The green, red and dark red lines indicate the average, The RAPL framework is supported by all recent intel CPU maximal and minimal energy gains. The precise values are: architectures. However, not all intel architectures support the four energy estimations provided by RAPL [19], namely • Average gain: 20.0% Core, DRAM, GPU and Package. In the intel architecture • Maximal gain: 25.4% we conducted our studies, only the Core and Package es- • Minimal gain: 15.4% timations were available. Because the package estimation includes the consumption of the Core, GPU and other elec- The reduction on energy consumption comes at a price: tronic devices on the chip, we will use this measurement as the increase in execution time. Indeed, figure 4 shows neg- a reliable indication of the energy consumption of the CPU. ative results for execution time, only. Thus, meaning that The energy monitoring C program developed for the en- every benchmark had a worse execution time with a power ergy ranking of languages and that we are reusing in our cap. study, however, produces three more measurements: exe- cution time, memory consumption and temperature. Time and (peak) memory consumption are provided by the linux operating system. The temperature measurement, provided by the lm-sensors C library, gives the value of the temperature of the CPU after the program execution. Thus it provides an indication of the energy dissipated as heat by the CPU. Thus, every single execution of a benchmark program produces five measurements: core, package, time, memory and temperature. In our study we execute each benchmark program 10 Figure 4: Increase in time with the use of power cap for times. In fact, we run each program 20 times: 10 times with Haskell benchmarks. power cap and 10 times without power cap. We also used The average, maximal an minimal increase in execution box plots to analyse outliers. These box plots showed that time are the following: the Java and Haskell benchmarks do not have outliers and 7 Due to scale issues which will make it difficult to see the results in figure 2, we omit here the hartel program. That program, however, is 6 https://github.com/lm-sensors/lm-sensors included in the figure 17 available in appendix. Figure 2: Energy consumption (left bar/legend) and execution time (right bar/legend) for each nofib benchmark program executed with and without power cap. • Average loss: 53.7% positive correlation are Core and Package followed by Time • Maximal loss: 60.3% and Package and Time and Core. This means that if the • Minimal loss: 38.0% values of a column presented in the pair increase, the values on the other column of the pair increase too. Is also relevant Besides analysing the impact of the power cap in execu- to mention that the columns Temperature and PowerLimit tion time and energy consumption and the gain in this two are negatively correlated which, in this case, means that aspects, we decided that it would be interesting to analyse if the values of a column present in the pair increase the how the values of one column influence the values of other values on the other column of the pair decrease. columns. To do so we used a correlation matrix. A correla- Another aspect that we considered interesting to explore tion matrix is a statistical tool that shows how strong and was how the power cap affects the relation between execu- in what direction two or more variables are related. The tion time and energy consumption. To do so we used the correlation coefficient ranges from -1 to +1, where -1 means scatter plot presented in figure 6: a perfect negative correlation, +1 means a perfect positive correlation, and 0 means there is no correlation between the variables. Figure 6: Correlation between Package and Time with and without power cap. In figure 6 we observe that we have less energy consump- tion per time unit when using the power cap. Besides, we can once again confirm that the energy consumption and the execution time are positively correlated. Figure 5: Correlation matrix for Haskell 3.3. Java DaCapo Benchmark By analysing the correlation matrix presented in figure 5, The DaCapo benchmark, in its version 23.11-chopin, consists we can conclude that the two columns that present higher of 20 real-world, open-source client-side Java benchmarks. Figure 7: Energy consumption (left bar/legend) and execution time (right bar/legend) for each DaCapo benchmark program executed with and without power cap. We executed each of this benchmarks with and without power cap. Figure 7 shows the energy and runtime of each DaCapo program. As we did for nofib, for each DaCapo program we associate two bars: energy (in joules) on the left and runtime (in seconds) on the right. Moreover, each bar uses two colours to indicate the use or not of power cap. Figure 8 clearly shows that the use of power cap does decreases energy consumption, on average a 23.4% while Figure 9: Increase in Time with the use of power cap for increasing runtime, on average 101.1%, as shown in figure 9. Java benchmarks. This is the case for each of the 20 DaCapo programs, very much like in the nofib benchmark. In average the runtime in DaCapo increases 100%. To have a better understanding on the impact that power cap has on energy consumption, we calculated the gain in • Average loss: 101.1% percentage for each benchmark. The results are presented • Maximal loss: 186.4% in figure 8. • Minimal loss: 14.6% In order to analyse the correlation between our five mea- surements, we use the correlation matrix presented in fig- ure 10. Figure 8: Reduction in energy consumption (package) with the use of power cap for Java benchmarks. where the average, maximal and minimal values of energy consumption reduction are: • Average gain: 23.4% • Maximal gain: 37.0% • Minimal gain: 11.9% The execution time of DaCapo benchmarks increases when using a power cap, as detailed in figure 9. Figure 10: Correlation matrix for Java benchmarks. By looking at figure 10 we can conclude that Package and Core are the most positively correlated columns followed by Time and Package. Moreover, the attributes Temperature and PowerLimit are the most negatively correlated features. Lastly we analyse the relation between Package and Time with and without power cap using a scatter plot and the results are displayed in figure 11, Figure 14: Increase in Time with the use of power cap Python benchmarks. • Average loss: 21.5% • Maximal gain: 22.6% • Maximal loss: 54.8% Once we studied the impact of power cap on energy con- sumption and execution time, we opt to analyse the relations between different columns values. And we did so using a Figure 11: Correlation between Package and Time with and correlation matrix presented in figure 15 without power cap for Java DaCapo benchmarks. By taking a look at figure 11 we can conclude that there is less energy consumption per time unit with the use of power cap. Moreover, with the use of power cap the columns present a stronger correlation. 3.4. Python pyPerformance Benchmark The pyPerformance benchmark consists of 75 programs, which we executed with and without power cap by our energy framework. Of these 75 programs, only 57 were used due to some benchmarks requiring a python version above the executed one. This was the case when running python 3.8 on benchmarks that required python 3.10 or above. To be able to compare each compiler with each other, these benchmarks results in other version were discarded. Figure 12 shows the energy consumption and runtime for Figure 15: Correlation matrix for Python benchmarks ver- each python program. sion 3.12. As we can see in figure 12 with the use of power cap there is a decrease in the energy consumption of all programs. By analysing the correlation matrix presented above we This is shown in more detailed in figure 13. can conclude that the two columns that present higher posi- tive correlation are Core and Package followed by Time and Package and Time and Core. Is also relevant to mention that the columns Temperature and PowerLimit are negatively re- lated once this relation in the correlation matrix presents such a small number. Lastly we analysed the relation between energy consump- tion and execution time, and the results are presented in figure 16 Figure 13: Reduction in energy consumption (package) with the use of power cap for Python benchmarks. In fact, in average the use of power cap reduces energy consumption in 35%! • Average gain: 35.3% • Maximal gain: 60.4% • Minimal gain: 17.9% In terms of runtime, however, the results are different. The red colour shown in several programs of figure 12 do Figure 16: Correlation between Package and Time with and indicate that some python programs execute faster when a without power cap for Python benchmarks ver- power cap is defined! sion 3.12. Figure 12: Energy consumption (left bar/legend) and execution time (right bar/legend) for each pyPerformance program executed with and without power cap. Gain And Loss Haskell Java Python minimal energy gain, Python has the highest (17.9%) com- average energy gain 20.0% 23.4 % 35.3% pared to Haskell (15.4%) and Java (11.9%). maximal energy gain 25.4% 37.0 % 60.4% The impact on the runtime, Java shows a significant av- minimal energy gain 15.4% 11.9 % 17.9% erage runtime loss (101.1%), indicating that the programs average runtime loss 53.7% 101.1% 21.5% are running much slower, on average, when comparing to maximal runtime loss 60.3% 186.4% 54.8% Haskell (53.7%) and Python (21.5%). In fact, the maximum minimal runtime loss 38.0% 14.6 % - runtime loss is higher in Java (186.4%), followed by Haskell maximal runtime gain - - 22.6% (60.3%) and Python (54.8%). In terms of minimal runtime loss, no. programs that 0 0 0 Haskell has the highest (38.0%) compared to Java (14.6%) increased energy and Python, which had a gain of 22.6%. no. programs that 0 0 22 decreased runtime In contrast to the majority of the benchmarks, when a power cap is set, certain python benchmarks’ runtime de- Table 1 creased, along with their energy consumption. The most Overall Results notorious are bm_concurrent_imap, a concurrent model com- munication benchmark, which uses the Pool that handles CPU bound job and ThreadPool that handles IO bound jobs, After analysing figure 16 we can conclude that we have from the multiprocessing.pool library. Also,bm_logging is less energy consumption per time unit when using the a simple message logging benchmark, that utilises the in- power cap. Besides that, once again we can confirm that memory text stream function StringIO from the io library. energy consumption and execution time are positively cor- As a final example, we have bm_gc_collect benchmark, a related. node connected to another node traversal benchmark that is ran with n cycles, resembling a linked list collection traver- 3.5. Discussion sal. The first two mentioned benchmarks handle IO related jobs. Thus, one could argue that execution of these type When comparing the correlation between Package and Time of jobs are more sensible to a power cap when compared in Java and Haskell benchmarks, considering both correla- to all the benchmarks. Hence, further testing and analy- tion matrices, one can conclude that correlation is stronger sis is required to fully understand the reason behind these in the Haskell benchmarks. unexpected results. From table 1 we can observe that in terms of energy In summary, Python shows the most balance performance consumption, regardless the implementation language, ev- with substantial energy gains and the potential for runtime ery program improved their energy consumption. In fact, reductions. However, Java programs tend to have a higher Python demonstrates the highest average energy gain runtime loss, indicating a trade-off where energy savings (35.3%), followed by Java (23.4%) and Haskell (20.0%). Python may come at the cost of significantly increasing execution also demonstrates a higher maximum energy gain (60.4%), time. Also, Haskell shows a moderate performance in both followed by Java (37.0%) and Haskell (25.4%). In terms of energy gains and runtime losses, making it a middle ground between Python and Java in this analysis. on design pattern energy usage, in: Green and Sus- tainable Software (GREENS), 2012 1st Int. Workshop on, IEEE, 2012, pp. 55–61. 4. Conclusions [8] M. Linares-Vásquez, G. Bavota, C. Bernal-Cárdenas, R. Oliveto, M. Di Penta, D. Poshyvanyk, Mining This paper presented a study on the impact of defining a energy-greedy api usage patterns in android apps: an power cap in three well-established benchmarks: nofib in empirical study, in: Proc. of the 11th Working Conf. on Haskell, DaCapo in Java, and pyPerformance in Python. We Mining Software Repositories, ACM, 2014, pp. 2–11. executed all programs in these three benchmarks with and [9] C. Sahin, L. Pollock, J. Clause, How do code refactor- without defining a power cap. ings affect energy usage?, in: Proc. of 8th ACM/IEEE Our first results show that power cap consistently de- Int. Symposium on Empirical Software Engineering crease the energy consumption of programs written in all and Measurement, ACM, 2014, p. 36. three languages. In average we obtained energy reductions [10] R. Pereira, T. Carção, M. Couto, J. Cunha, J. P. Fer- of 20% in Haskell, 23% in Java, and 35% in Python. This nandes, J. Saraiva, Helping programmers improve the energy reduction comes at a price: in all languages the ex- energy efficiency of source code, in: Proceedings of ecution times increases: 22% in Python, 54% in Haskell, the 39th International Conference on Software Engi- and 101% in Java! Although Python seems to profit more neering Companion, ICSE-C ’17, IEEE Press, 2017, p. from power cap it is worth to notice that Python is known 238–240. doi:10.1109/ICSE-C.2017.80. for having poor runtime and energy consumption perfor- [11] S. A. Chowdhury, A. Hindle, Greenoracle: estimating mances [2], and the speedup/greenup that achieves with software energy consumption with energy measure- power cap does not directly translate to speed/greenness. ment corpora, in: Proceedings of the 13th Interna- tional Conference on Mining Software Repositories, Acknowledgements MSR, 2016, 2016, pp. 49–60. [12] R. Jabbarvand, A. Sadeghi, J. Garcia, S. Malek, P. Am- This work is partially supported by CERCIRAS - Connecting mann, Ecodroid: An approach for energy-based rank- Education and Research Communities for an Innovative ing of android apps, in: Proc. of 4th Int. Workshop on Resource Aware Society - COST Action CA19135 funded by Green and Sustainable Software, GREENS ’15, IEEE COST Association. Press, 2015, pp. 8–14. [13] S. Hao, D. Li, W. G. J. Halfond, R. Govindan, Esti- mating mobile application energy consumption using References program analysis, in: Proc. of the 2013 Int. Conf. on Software Engineering, ICSE ’13, IEEE Press, 2013, pp. [1] W. Voegels, Keynote at AWS re:Invent 2023, 2023. URL: 92–101. https://youtu.be/UTRBVPvzt9w?t=3718, accessed: [14] M. Couto, P. Borba, J. Cunha, J. P. Fernandes, R. Pereira, 2024-05-19. J. Saraiva, Products go green: Worst-case energy con- [2] R. Pereira, M. Couto, F. Ribeiro, R. Rua, J. Cunha, sumption in software product lines, in: Proceedings of J. P. Fernandes, J. Saraiva, Energy efficiency across the 21st International Systems and Software Product programming languages: how do energy, time, and Line Conference - Volume A, SPLC ’17, Association memory relate?, in: Proceedings of the 10th ACM for Computing Machinery, New York, NY, USA, 2017, SIGPLAN International Conference on Software Lan- p. 84–93. doi:10.1145/3106195.3106214. guage Engineering, SLE 2017, Association for Comput- [15] M. Couto, R. Pereira, F. Ribeiro, R. Rua, J. Saraiva, To- ing Machinery, New York, NY, USA, 2017, p. 256–267. wards a green ranking for programming languages, in: doi:10.1145/3136014.3136031. Programming Languages: 21st Brazilian Symposium, [3] R. Pereira, M. Couto, J. a. Saraiva, J. Cunha, J. a. P. SBLP 2017, Fortaleza, Brazil, September, 2017., 2017. Fernandes, The influence of the java collection frame- [16] R. Pereira, M. Couto, F. Ribeiro, R. Rua, J. Cunha, work on overall energy consumption, in: Proc. of the J. P. Fernandes, J. Saraiva, Ranking programming lan- 5th Int. Workshop on Green and Sustainable Software, guages by energy efficiency, Science of Computer Pro- GREENS ’16, ACM, 2016, pp. 15–21. doi:10.1145/ gramming 205 (2021). doi:10.1016/j.scico.2021. 2896967.2896968. 102609. [4] S. Hasan, Z. King, M. Hafiz, M. Sayagh, B. Adams, [17] W. Partain, The nofib benchmark suite of haskell pro- A. Hindle, Energy profiles of java collections classes, grams, in: J. Launchbury, P. Sansom (Eds.), Functional in: Proc. of the 38th Int. Conf. on Software Engineering, Programming, Glasgow 1992, Springer London, Lon- ACM, 2016, pp. 225–236. don, 1993, pp. 195–202. [5] W. Oliveira, R. Oliveira, F. Castor, A study on the [18] S. M. Blackburn, R. Garner, C. Hoffman, A. M. Khan, energy consumption of android app development ap- K. S. McKinley, R. Bentzur, A. Diwan, D. Feinberg, proaches, in: Proceedings of the 14th International D. Frampton, S. Z. Guyer, M. Hirzel, A. Hosking, Conference on Mining Software Repositories, IEEE M. Jump, H. Lee, J. E. B. Moss, A. Phansalkar, D. Ste- Press, 2017, pp. 42–52. fanović, T. VanDrunen, D. von Dincklage, B. Wieder- [6] D. Li, W. G. J. Halfond, An investigation into energy- mann, The DaCapo benchmarks: Java benchmark- saving programming practices for android smartphone ing development and analysis, in: OOPSLA ’06: Pro- app development, in: Proceedings of the 3rd Interna- ceedings of the 21st annual ACM SIGPLAN confer- tional Workshop on Green and Sustainable Software ence on Object-Oriented Programing, Systems, Lan- (GREENS), 2014. guages, and Applications, ACM Press, New York, NY, [7] C. Sahin, F. Cayci, I. L. M. Gutierrez, J. Clause, F. Ki- USA, 2006, pp. 169–190. doi:http://doi.acm.org/ amilev, L. Pollock, K. Winbladh, Initial explorations 10.1145/1167473.1167488. [19] M. Dimitrov, C. Strickland, S.-W. Kim, K. Kumar, Appendice K. Doshi, Intel® power governor, https://software.intel. com/en-us/articles/intel-power-governor, 2015. Ac- Figure 17 includes all programs of the nofib benchmark. cessed: 2015-10-12. [20] K. N. Khan, M. Hirki, T. Niemi, J. K. Nurminen, Z. Ou, Rapl in action: Experiences in using rapl for power measurements, ACM Trans. Model. Perform. Eval. Comput. Syst. 3 (2018). doi:10.1145/3177754. [21] C. Imes, H. Zhang, K. Zhao, H. Hoffmann, CoPPer: Soft real-time application performance using hard- ware power capping, in: 2019 IEEE International Con- ference on Autonomic Computing (ICAC), 2019, pp. 31–41. doi:10.1109/ICAC.2019.00015. [22] A. Krzywaniak, P. Czarnul, J. Proficz, Extended in- vestigation of performance-energy trade-offs under power capping in hpc environments, in: 2019 Interna- tional Conference on High Performance Computing & Simulation (HPCS), 2019, pp. 440–447. doi:10.1109/ HPCS48598.2019.9188149. [23] A. Krzywaniak, P. Czarnul, J. Proficz, Depo: A dynamic energy-performance optimizer tool for au- tomatic power capping for energy efficient high- performance computing, SOFTWARE-PRACTICE & EXPERIENCE 52 (2022) 2598–2634. [24] M. Hähnel, B. Döbel, M. Völp, H. Härtig, Measur- ing energy consumption for short code paths using RAPL, SIGMETRICS Performance Evaluation Review 40 (2012) 13–17. [25] D. Hackenberg, R. Schöne, T. Ilsche, D. Molka, J. Schuchart, R. Geyer, An Energy Efficiency Feature Survey of the Intel Haswell Processor, Proceedings - 2015 IEEE 29th International Parallel and Distributed Processing Symposium Workshops, IPDPSW 2015 (2015) 896–904. doi:10.1109/IPDPSW.2015.70. [26] B. Santos, M. H. Kirkeby, J. P. Fernandes, A. Pardo, Compiling Haskell for energy efficiency: Empirical analysis of individual transformations, in: Proceed- ings of the 39th ACM/SIGAPP Symposium on Applied Computing, ACM, 2024, pp. 1104–1113. doi:10.1145/ 3605098.3635915. Figure 17: Relation between Haskell’s benchmarks and the variables Package and Time with and without power cap.