=Paper=
{{Paper
|id=Vol-3867/paper4
|storemode=property
|title=On the Impact of PowerCap in Haskell, Java, and Python
|pdfUrl=https://ceur-ws.org/Vol-3867/paper4.pdf
|volume=Vol-3867
|authors=Luís Maia,Marta Sá,Inês Ferreira,Simão Cunha,Luís Silva,Paulo Azevedo,João Saraiva
|dblpUrl=https://dblp.org/rec/conf/raw2/MaiaSFCSAS24
}}
==On the Impact of PowerCap in Haskell, Java, and Python==
https://ceur-ws.org/Vol-3867/paper4.pdf
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.