Sustainable Computing: Informatics and Systems 38 (2023) 100864

Contents lists available at ScienceDirect

Sustainable Computing: Informatics and Systems

journal homepage: www.elsevier.com/locate/suscom

How sustainable is ‘‘common’’ data science in terms of power consumption?

Bjorge Meulemeester a,b ,∗, David Martens a
a
Prinsstraat 13, 2000 Antwerpen, Belgium
b
Ludwig-Eerhard-Allee 2, D-53175, Bonn, Germany

ARTICLE INFO ABSTRACT

Keywords: Continuous developments in data science have brought forth an exponential increase in complexity of
Sustainability machine learning models. Additionally, data scientists have become ubiquitous in the private market and
Carbon emission academic environments. All of these trends are on a steady rise, and are associated with an increase in
AI
power consumption and associated carbon footprint. The increasing carbon footprint of large-scale advanced
Data science
data science has already received attention, but the latter trend has not. This work aims to estimate the
Energy consumption
Carbon footprint
contribution of the increasingly popular ‘‘common’’ data science to the global carbon footprint. To this end,
Common data science the power consumption of several typical tasks in the aforementioned common data science tasks are measured
and compared to: large-scale ‘‘advanced’’ data science, common computer-related tasks, and everyday non-
computer related tasks. An automated data science project is also run on various hardware architectures.
To assess its sustainability in terms of carbon emission, the measurements are converted to gCO2 eq and an
equivalent unit of ‘‘km driven by car’’. Our main findings are: ‘‘common’’ data science consumes 2.57 more
power than regular computer usage, but less than some common everyday power-consuming tasks such as
lighting or heating; advanced data science consumes substantially more power than common data science,
and can be either on par or vastly surpass common everyday power-consuming tasks, depending on the scale
of the project. In addition to the reporting of these results, this work also aims to inspire researchers to include
power usage and estimated carbon emission as a secondary result in their work.

1. Introduction adopted [12], measures targeting other areas, such as inefficiencies in

Data science (DS) and Artificial Intelligence (AI) have become a fun-
damental aspect of our digital world; be it for marketing strategies [1],
uncovering shopping patterns of clients [2], computer-mediated lan-
guage comprehension [3], detecting cardiac arrhythmias [4] or simply
predicting the weather [5]. Deep neural networks have experienced
a steep increase in complexity, and correspondingly a steep increase
in the hardware required to train these models [6]. As the hardware
requirements have grown exponentially, so has the power consumption
attributed to these hardware requirements. Large models are commonly
trained in big datacenters, powered by various types of energy [7]. It
is estimated that these datacenters currently account for about 1% of
the worldwide electricity use [8]. Their projected energy consumption
and carbon emission for the upcoming years is subject of debate,
and estimates range between the status quo [8] up to 8% of global
carbon emission by 2030 [9]. Major takeaways from this discussion
is that datacenters are gradually shifting towards green energy [10],
are getting increasingly efficient [8], but are simultaneously being
used more and more for hyperscale data science [11] and, despite the
shift towards green energy in datacenters’ infrastructure being widely
servers, circular economy, and heat reuse, are still lagging [13].
These values represents the steep increase in data center demand
and their usages, but does not take into account the increase in ‘‘com-
mon’’ data science jobs that do not require these large data centers.
The term common data science is used in this work to denote any data
science that can be performed by one (or a team of) data scientist(s)
on their home or work computer/laptop.
Data science entails more than huge complex neural networks and
big datacenters; common data scientists are omnipresent in the pri-
vate market in various fields. Data science related jobs often end up
in the top 5 fastest growing jobs in terms of demand: according to
LinkedIn, Machine learning engineer is the 4th fastest rising job in the
U.S. [14], and the 2nd fastest rising job in The Netherlands, Italy and
the U.K. [15]. Other data science related jobs such as Data scientist
and Data engineer tend to end up high on these lists as well. Does this
increase in common ‘‘everyday’’ data science also imply an increase
in power consumption and carbon emission? Masanet et al. [8] esti-
mate that in 2020, powering digital devices (excluding smartphones)
accounted for 20% of all ICT-related greenhouse gas emissions (GHGe),

∗ Corresponding author at: Prinsstraat 13, 2000 Antwerpen, Belgium.

E-mail addresses: bjorge.meulemeester@mpinb.mpg.de (B. Meulemeester), david.martens@uantwerpen.be (D. Martens).

https://doi.org/10.1016/j.suscom.2023.100864
Received 31 May 2022; Received in revised form 6 January 2023; Accepted 20 February 2023
Available online 25 February 2023
2210-5379/© 2023 The Authors. Published by Elsevier Inc. This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-
nc-nd/4.0/).
B. Meulemeester and D. Martens
and communication networks account for 25%; the sum of which
is comparable to the estimate of data center GHGe of 45%. The
contribution to the global GHGe of household ICT devices, such as those
used by common data scientists, should not be underestimated.
This work aims to compare the previously mentioned advanced
data science, or ‘‘big datacenter data science’’ to the latter common
data science. The main question is if the latter common data science
has a substantial contribution to the global GHGe. To this end, the
carbon emissions of common data science is estimated and compared to
common computer tasks, common non-computer related everyday tasks
and the aforementioned ‘‘big datacenter’’ advanced data science. This is
done by means of performing a common data science project and other
various tasks on a laptop while measuring their power consumption,
and comparing these values to one another. Additionally, an automated
data science project is run on various hardware architectures, and an
empirical law is constructed to extrapolate these results to even more
hardware architectures. Further details of these experiments are given
in Section 2.
The goal of this work is not to report a large-scale benchmark on
the power consumption and environmental impact of common data
science; such results are only possible and accurate if these numbers are
present plentifully in the literature. This is the only way to accumulate
realistic, trustworthy data that covers a broad range of data scientists,
data science projects and different hardware architectures. This work
does aim to aid the popularization of reporting of such numbers as
secondary results in order to make this a possibility. Such reporting
is not yet standard practice, as is demonstrated by the lack of these
numbers in hyper-scale AI projects such as DALL⋅E [16] and GPT-3 [3],
but also in many other data science related works.
2. Methods
In order to assess the environmental impact of performing common
data science, two different experiments are performed:
1. Performing a real data science project on a single hardware
device and comparing it to other common computer related tasks
on the same hardware device, common non-computer related
tasks, and advanced data science.
2. Automating the previous data science project and running it on
multiple devices, comparing the outcomes.
The goal of these experiments is to assess the contribution of common
data science to the overall power consumption of one or more devices.
This contribution in power consumption is then converted to carbon
emission as explained in Section 2.6. As it is not feasible to consider
every possible combination of hardware architectures as individual
parameters, and such large-scale benchmark is not the scope of this
work, we consider instead three essential properties that an experiment
must have in order to reflect an accurate assessment of the power
consumption of common data science:
1. Hardware representativeness
2. Workflow representativeness
3. Workflow realism
How well each experiment covers these properties is shown in Table 1,
and revisited in Section 4.5. Note that this work is inherently limited
by the workflow of the authors, and no experiment in this work can
perfectly simulate or represent the workflow of other data scientists.
More details on both is provided below.
2.1. Experiment №1: Performing a real data science project and comparing
to other common tasks
This section provides a detailed overview of each task that was per-
formed in order to compare common data science (CDS) to other com-
mon computer related tasks (CR), common non-computer related tasks
2
Sustainable Computing: Informatics and Systems 38 (2023) 100864
Table 1
Overview of considered experiments showing benefits and drawbacks, showing
three criteria for each experiment: Hardware representativeness, workflow realism
(how well the considered task mirrors a real-world task), and workflow repre-
sentativeness (compared to other data scientists). The experiment indices follow
the enumeration as given in Section 2.
Experiment 1 2
Hardware Representative 1 architecture Several architectures
Workflow Realistic Real workflow Automated
Representative Singular Singular & automated
(NCR) and advanced data science (ADS). During this cross-comparison,
all computer related tasks and common data science tasks were per-
formed on the same hardware architecture. The considered hardware
architecture is described in Table 2 under index 3.
Only during this experiment is the hardware limited to a single
hardware structure. This is done in order to allow for consistent com-
parison between these tasks; the aim of this experiment is to asses an
estimate of the relative difference in power consumption of these tasks.
(CR) Baseline computer (idle). This task is done by leaving a computer
running with the screen on, and no open programs. The value of this
task varies depending on the efficiency of the hardware, background
tasks and screen brightness.
(CR) Watching a movie. This task is completed by streaming Avengers:
Age of Ultron via Disney+ on Firefox 96.0 for Ubuntu. No other tabs
or programs were running. The carbon emission of the datacenter
providing the movie is not taken into account due to lack of available
data.
(CR) Normal computer usage. Normal usage entails browsing the in-
ternet, reading a pdf and opening/closing various programs: Inkscape,
Firefox, text editor and file browser. Tasks that involve video rendering
(such as gaming, watching Youtube or viewing local video files) are
purposely avoided, as these are comparable to the task Watching a
movie.
(CR) Working in excel. This task entails making plots and performing
various column transformations on a 4, 000 × 20 dataset containing
only continuous numerical values. These column transformations aim
to reflect common data science operations such as: deleting columns,
scaling columns, and power- and log-transformations. Plots are limited
to histograms. These Excel operations are performed in LibreOffice Calc
version 1:6.4.7-0ubuntu0.20.04.2.
(CDS) Data science project. This task entails doing a common data sci-
ence project, namely a credit scoring classification problem: identifying
defaulters on a loan. This project is split into two main parts:
1. Exploration & preprocessing
2. Gridsearch & fit
Exploration & preprocessing entails constructing plots of features
and processing features according to their meaning, type and distribu-
tion. This is done by means of column transformations on a 20, 000 ×
35 dataset with mixed continuous and categorical features. All data
exploration and processing is done in Python3.8 using matplotlib,
pandas and scikit-learn. Column transformations includes: encoding
(one-hot encoding and WOE-encoding), scaling to normal distributions
with QuantileTransformer(), filling missing values with means
or modes and over- and undersampling with ADASYN and Rando-
mUnderSampler(). The exact workflow can be found in the auto-
mated version of the data science project (see Section 2.2), available
on github at [17].
Gridsearch & fit entails performing two hyperparameter gridsearches
for the machine learning models Random Forest, KNN and Logistic
Regression on the dataset as described in the previous paragraph.
B. Meulemeester and D. Martens Sustainable Computing: Informatics and Systems 38 (2023) 100864

Table 2
Overview of all hardware types considered in this work. The indices are ordered to be congruent with the graphs.
Index Name CPU Threads RAM slots RAM
Dell Inc. Intel(R) Core(TM) SODIMM DDR4 Synchronous
3 Inspiron 7570 i7-8550U CPU 8 1x Unbuffered (Unregistered)
(07EA) Notebook @ 1.80 GHz 2400 MHz (0,4 ns)
Dell Inc. Intel(R) Core(TM) SODIMM DDR4 Synchronous
2 XPS 15 9560 i7-7700HQ CPU 8 2x Unbuffered (Unregistered)
(07BE) Notebook @ 2.80 GHz 2400 MHz (0,4 ns)
Dell Inc. Intel(R) Core(TM)
SODIMM DDR4 Synchronous
1 XPS 15 9500 i9-10885H CPU 16 2x
3200 MHz (0,3 ns)
(097D) Notebook @ 2.40 GHz
11th Gen
Dell Inc. SODIMM DDR4 Synchronous
Intel(R) Core(TM) 16 1x
0 Latitude 5421 3200 MHz (0.3 ns)
i7-11850H
(0A66) Notebook
@ 2.50 GHz

Table 3
Hyperparameter grids for the two gridsearches performed during the task Gridsearch & fit.
Model Gridsearch #1 Gridsearch #2
n_estimators: [100, 500, 1000, 2000] n_estimators: [2000, 2500, 3000]
Random Forest max_depth: [10, 50, 100] max_depth: [50, 70, 90]
min_samples_split: [2, 10] min_samples_split: [2]
n_neighbors: [10, 20, 50, 100, 500, 1000] n_neighbors: [10, 20, 50]
KNN
p: [1, 2] p: [1]
penalty: [l2, l1, elasticnet] penalty: [l2]
Logistic Regression C: [0.001, 0.01, 0.1, 1, 10, 100, 1000] C: [0.1, 0.3162, 1.0, 3.162, 10.0]
max_iter: [10, 100, 500, 1000] max_iter: [1500, 2000, 3000]

Gridsearches are performed by starting with a coarse Gridsearch and re-
fining the grid intervals once with a second Gridsearch. The considered
hyperparameter grids are shown in Table 3. A 5-fold cross-validation
scheme is used.
(NCR) Burning a lightbulb for an hour. Assuming a 10 W light bulb.
(NCR) Streaming season 1 of friends. The carbon emission of this task
was calculated using the same measurement for power consumption as
the task Watching a movie and extrapolating this to the duration of the
first season of Friends (2h28′ ).
(NCR) Leaving the office lights on over the weekend. This is calculated by
assuming the office is lit by 8 10 W TL lights, burning from Friday 5pm
until Monday 9am: the lighting setup at the office of the first author.
(NCR) Heating an office for a day. This is calculated by assuming an
office with following properties:
• This value was measured using different hardware.
• The dataset was already processed; processing does not contribute
to the reported value.
• Only one training session is reported, which does not reflect a
realistic case of trial and error, with multiple training sessions.
• While computationally challenging, it is feasible to replicate this
task on a home computer. This measurement lives in the gray
zone between common and advanced data science.
(ADS) Training GPT-3 in the EU. This measurement is an estimate
taken from [6], assuming Microsoft’s average datacenter PUE (Power
Usage Effectiveness) of 2015, re-calculated with updated values for the
GHGe associated with energy production (EU28 average from 2020)
and GHGe of cars (EU28 average from 2021).
2.2. Experiment №2: Running an automated data science project on multi-
ple hardware architectures

• 50 m2 area In order to include multiple hardware architectures, and increase

• One outside wall the hardware representativeness of the results, an automated version of
• Solid and insulated cavity walls the data science project as described in Section 2.1 was created [17].
• A ceiling height of 3 m This automated version performs all the steps of the original data
• A minimum roof insulation of 75 mm science project, albeit at a hyper-efficient tempo. This experiment only
• Electrically heated at 21 ◦ C (70 ◦ F) includes measurements on successfully run code, and does not include
any overhead tasks such as (but not limited to) debugging, looking up
Data was taken from [18]. documentation or other browser-related activities, and idling device.
The considered hardware architectures are given in Table 2.
(NCR) Commercial airflight for 1 passenger (BRU → JFK NY). This The aim of this experiment is not to benchmark a vast amount of
carbon emission was calculated assuming a flight from Brussels (BRU) hardware architectures on some data science project; large-scale bench-
to New York (JFK NY), where all seats are economy seats and occupied. marks for various hardware architectures already exist (see, for exam-
Data taken from [19]. ple, [20]). The goal is rather to report and reduce the bias introduced
by considering only one hardware type.
(ADS) Training a CNN on images. This measurement was taken from [6],
The automated data science project can be defined by the following
where more details can be found. This advanced data science task was
step-by-step plan:
performed by training the CNN U-NET for 100 epochs on the LIDC
medical image dataset. This required 1.25 ± 0.25 kWh, as is visible in 1. Loading data and transforming to dataframe.
Figure 1 of Anthony et al. [6]. Note that: 2. Plotting distributions of all features.

3
B. Meulemeester and D. Martens
3. Performing basic processing on the data to allow for training.
4. Training a logistic regression model on unprocessed data.
5. Iteratively:
(a) Improved processing on all features.
(b) Checking effect of previous processing by re-training the
logistic regression model.
(c) Plotting distributions of processed features.
6. Performing a coarse gridsearch.
7. Performing a finer gridsearch.
The code for this automated workflow is available on github at [17].
While the code allows for multiple iterations of improving data pro-
cessing and testing the effect of these improved processing steps on the
resulting AUC score with a logistic regression model, only one iteration
is actually performed. Multiple iterations are not included in this work,
since any choice of number for the amount of iterations would be
arbitrary, and would not increase the realism of the automated data
science project by any measurable metric. Additionally, the authors
argue that a singular iteration of data processing improvement is not
too unrealistic for a data science project, albeit a minimum. However,
this argument is subject to the specificity of the author’s workflow, as
mentioned before at the end of Section 2 and Table 1, and is open to
adversity.
2.3. Assumptions
Inevitably, assumptions need to be made in order to compare the
measurements in a comprehensive manner. The measurements in this
work are only as truthful as the truth value of these assumptions. These
will also be revisited in Section 4.5.
1. It suffices to measure the power consumption of the CPU to gain
insight in the total power consumption of performing various
computer tasks, as we can estimate the total power consumption
by assuming a CPU to RAM power consumption of 3 ∶ 2, as
estimated by Anthony et al. [6].
2. Differences in power consumption of the automated data science
project across the measured hardware architectures are repre-
sentative for differences in power consumption of data science
projects for other hardware architectures.
3. The energy consumption of common data science on other hard-
ware structures can, to some extent, be estimated based using
the Thermal Design Power (TDP) as a proxy for the power
consumption of the entire machine, and assuming an inverse
relationship between the total consumed energy for a single
automated data science task 𝐸𝐴𝑢𝑡𝑜𝐷𝑆 and TDP of the nature:
𝐸𝐴𝑢𝑡𝑜𝐷𝑆 = 𝑎∕𝑇 𝐷𝑃 + 𝑏, where 𝑎 and 𝑏, the dropoff rate and
intercept respectively, are parameters that are to be estimated.
4. A car emits as much gCO2 eq as the EU average from 2019.
5. Energy production emits as much CO2 eq as the EU average from
2020.
2.4. Measuring the power: Measurement tools
The previous sections expanded on the details of the different
experiments. Both experiments require measurements of the power
consumption of the considered hardware device. This section expands
upon the methods used to measure this power consumption.
Measuring the real-time power consumption and/or energy con-
sumption of a task performed on the computer is done by using
Ubuntu’s powerstat package to sample the intel RAPL interface. This
can be done by sudo apt install powerstat and consequently
running the shell command
𝚜𝚞𝚍𝚘 𝚙𝚘𝚠𝚎𝚛𝚜𝚝𝚊𝚝 − 𝙳𝚁𝚐𝚏 − 𝚍 = ⟨𝑠⟩ 𝛥𝑡
4
Sustainable Computing: Informatics and Systems 38 (2023) 100864
𝙽 > 𝚘𝚞𝚝𝚙𝚞𝚝.𝚝𝚡𝚝 (1)
where -D enables the -R option, -R denotes sampling should be done
on the RAPL interface, -f enables showing the average CPU frequency,
-d denotes a delay before starting the measurement (in seconds), 𝛥𝑡
denotes the time interval between samples (in seconds), N denotes
the amount of samples and -g enables measuring the GPU power
consumption as well. GPU power consumption and GPU programming
are not explored in this work, as the authors consider this advanced
data science, rather than common data science. The sampling interval
should be sufficiently small compared to the duration of the task in
order to accurately measure the distribution of its power usage.
Where possible, CarbonTracker [6] is also used to measure energy
consumption. CarbonTracker is designed to track and predict the en-
ergy consumption of training AIs, but can be used for any piece of code.
It must be noted that CarbonTracker was designed for measuring the
power consumption of training an AI during one or more epochs, and
not shorter code snippets prevalent in common data science. Due to
this, its accuracy may deviate, especially if the runtime of the code is
short. For this reason, interpreting the data will be based on the RAPL
measurements, and the CarbonTracker measurements are only shown
for completeness, and as a benchmark to check if it produces similar
results. Deviating results are also discussed in Section 4.
2.5. A note on the measurement tools
As mentioned before, both sampling the RAPL interface directly,
as well as CarbonTracker [6] is used to measure the power/energy
consumption. The resulting values should be interpreted differently.
The RAPL interface. This method measures by directly sampling the
power consumption of the CPU every other time interval. This mea-
surement is code-independent. Whether or not your code is running,
this method measures the power consumption. This method gives a
good overview of the entire power consumption of some task, including
the non-code related parts, e.g. looking up documentation and articles,
debugging, running code that finishes with an error, etc. This mea-
surement gives the most accurate measurement of a certain task, but
will include variability depending on the efficiency, experience and
knowledge of the data scientist performing the task. Note that only
the power consumption of the CPU is considered. This may deviate
from the true power consumption, especially when running code that
relies heavily on RAM. This drawback is discussed in Section 4.5, when
revisiting the assumptions made earlier (see Section 2.3).
CarbonTracker. This method measures the energy consumption of a
single piece of code. This measurement gives a good overview of how
much energy was consumed by running the code, and nothing but the
code. If a script finishes on an error, no measurement is written out.
This measurement has a higher repeatability, but lacks information
on the overhead of the tasks: the non-code related parts and running
bugged code that finishes with an error.
RAPL vs CarbonTracker. Note that the samples for the Carbontracker
measurements are not the same kind of samples as those fore the
RAPL measurements. Carbontracker reports aggregate values at the end
of every successful exit of a piece of code, independent of how long
it took, while RAPL measurements produce a real-time measurement
every other time interval, independent of what the computer is doing.
The variance of the Carbontracker measurements is thus a variance be-
tween the total power consumptions of different successfully run code
snippets. The variance of the RAPL measurements, on the other hand,
is the variance on the real-time power consumption. This difference in
sample types should be kept in mind when interpreting the results.
B. Meulemeester and D. Martens Sustainable Computing: Informatics and Systems 38 (2023) 100864

Fig. 1. Power consumption distributions of working on common computer tasks and
data science, measured by CarbonTracker (dark blue) and sampling the RAPL interface
(light teal). RAPL samples are taken every 10 s, while CarbonTracker samples are taken
every successful run of a piece of code. (For interpretation of the references to color
in this figure legend, the reader is referred to the web version of this article.)
Fig. 2. Energy consumption and carbon emission (in km driven by car equivalent) of
working on common computer tasks and data science related activities. Only RAPL
measurements are shown.

2.6. Converting

While energy usage and carbon emission are inherently linked by

the fact that energy production produces greenhouse gas emissions,
their exact relation depends on the method that is used to produce
energy, and how green these methods are. Varying countries employ
various methods to produce energy. In order to link energy consump-
tion to carbon emission, the EU-28 (28 countries of the European
Union) average greenhouse gas emission associated with electricity
generation during 2020 [21] is used, yielding an average emission per
energy unit of:

CO2 eq∕𝑒𝑛𝑒𝑟𝑔𝑦 = 230.7 g∕kWh (2)

where CO2 eq denotes the amounts of gram CO2 that would yield a
greenhouse effect of equal magnitude as the considered greenhouse
gases, i.e. the seven greenhouse gases considered by the Kyoto Proto-
col [22]: carbon dioxide (CO2 ), methane (NH4 ), nitrous oxide (N2 O),
hydrofluorocarbons (HFCs), perfluorocarbons (PFCs), sulphur hexaflu-
oride (SF6 ) and nitrogen trifluoride (NF3 ).
In order to increase the interpretability of the gCO2 eq quantity,
they are converted to the quantity ‘‘km driven by car’’, as suggested
by Anthony et al. [6]. To do so, we use the average GHGe of every
registered car in the EU up until 2019 [23], yielding a distance per
equivalent carbon emission of:

8.17661488144 m∕gCO2 eq (3)

3. Results
Fig. 3. Carbon emission of common non-computer related tasks and data science
3.1. Experiment №1: Performing a real data science project and comparing (common and large-scale) on a logarithmic scale, expressed in units of km driven by car.
to other common tasks Values for common data science and computer-related tasks are reported for hardware
type 3 (see Table 2).

Fig. 1 shows the power consumption distribution per computer-

related task.
Fig. 2 shows the energy consumption of working on a certain task. These are compared to large-scale data science and other everyday
For tasks with an unspecified end time, a duration of 8 h is used to tasks in terms of carbon emission in Fig. 3. The total energy con-
reflect a day worth of work. sumption (and consequently associated carbon emission) for common

5
B. Meulemeester and D. Martens Sustainable Computing: Informatics and Systems 38 (2023) 100864

Fig. 4. Power distributions for running an automated data science project on different Fig. 5. Total energy used for running an automated data science project on different
hardware structures as described in Section 2.2. The experiment index and CPU are hardware structures as described in Section 2.2. The experiment index and CPU are
given as axis labels, where the indices are congruent with the hardware as shown in given as axis labels, where the indices are congruent with the hardware as shown in
Table 2. Table 2.

data science (i.e. running GridSearchCV() for an hour and doing a

common data science project) are calculated as
5
𝐸𝑡𝑜𝑡𝑎𝑙 = × 𝐸𝐶𝑃 𝑈 (4)
3
to be consistent with a 3 ∶ 2 CPU to RAM power consumption ratio, as
described in Section 2.3.

3.2. Experiment №2: Running an automated data science project on multi-

ple hardware architectures

The power consumption distributions of running an automated data

science experiment on multiple hardwares are shown in Fig. 4. Their
energy consumptions are shown in Fig. 5.

3.3. Estimated extrapolation of energy consumption in function of TDP

Fig. 6 shows an estimated extrapolation of the total energy con-

sumed by a piece of hardware using the TDP as input parameter, where
Fig. 6. Estimated projection of the consumption of common data science depending
we have assumed an inverse relationship between the two variables of on the TDP of the machine. Note that using TDP as sole proxy for power consumption
the shape has caveats (see Section 4.5), and that the error only includes variance on the
measurements, which does not contain all variance mentioned in Section 2.3.
𝑎
𝐸𝐴𝑢𝑡𝑜𝐷𝑆 = +𝑏 (5)
𝑇 𝐷𝑃
and the best fit yielded parameter values of:
4. Discussion
𝑎 = 17.175 ± 5.415
(6) 4.1. Experiment №1: Performing a real data science project and comparing
𝑏 = −0.055 ± 0.208
to other common tasks

3.4. Comparison of considered CPUs to other CPUs
The Thermal Design Power (TDP) of all CPUs recorded by Passmark
[20] are shown in Fig. 7. The TDP of the CPU considered in Experiment
№1 is denoted with a blue line, while all additional CPUs considered by
Experiment №2 have a TDP equal to 45 W, as denoted by a gold line.
Power consumption. We can see in Fig. 1 how CarbonTracker yields
similar results on power consumption as directly sampling the RAPL
interface for Gridsearch & fit, but there is a notable difference between
the two measurements for the task Exploration & preprocessing. This can
be explained by the fact that the latter task includes a lot of overhead,
such as looking up documentation, scaling columns one by one, pro-
gramming, debugging and running faulty code. All of the previously

6
B. Meulemeester and D. Martens
Fig. 7. Thermal Design Power of all CPUs as recorded by Passmark [20]. The TDP of
the CPU considered in experiment №1 is denoted by a vertical blue line, the additional
CPUs considered in experiment №2 by a gold ones (all exactly at 45 W), and the
median TDP by a black one. (For interpretation of the references to color in this figure
legend, the reader is referred to the web version of this article.)
mentioned overhead is not captured by CarbonTracker measurements;
only code that runs without error is measured by CarbonTracker. Car-
bonTracker can be interpreted as the hypothetical power consumption
of a hyper-efficient data scientist that does not make any mistakes,
knows the sklearn library by heart and writes their code instanta-
neously. Gridsearch & fit, on the other hand, is defined by few to no
programming, but simply leaving a script running. This explains the
similarity of the measurements of CarbonTracker and directly sampling
the RAPL interface.
Energy consumption. Fig. 2 reports the energy consumption of the same
tasks as shown in Fig. 1, sorted from low to high. If no duration is
reported in the label, a duration of an 8 hour working day is considered.
It is notable how streaming a 1.5 h movie requires less energy than
sitting through a 1 hour Teams call, despite both entailing similar tasks:
real-time video rendering. This is possibly due to the fact that online
meetings cannot make use of the same video compression methods as
streaming a movie, since the video data of the former is produced in
real-time. Processing less compressed data would then require more
computational power and put the CPU under heavier load, requiring
more energy. It must be noted that the carbon emission of the data-
center providing the movie is not taken into consideration. This would
increase the associated carbon emission.
It is also notable how the 2 gridsearches make up about 1∕3 of the
total energy consumption of the data science project, despite making
up only 14% of the time (1h17′ out of 9h04′ ). This makes sense, as
performing a gridsearch makes a CPU run in parallel under heavy load,
yielding a high power throughput. This was already visible in Fig. 1.
Carbon emission. Fig. 3 shows a log-scale of the carbon emission of
various everyday tasks, common data science tasks, and advanced data
science tasks. The carbon emission is expressed in units km driven by car
as described in Section 2.6. It is visible how all considered common
data science tasks emit less CO2 eq than e.g. leaving the office lights
on over the weekend. Even an advanced data science task such as
training a CNN on images emits less CO2 eq, when performed under the
same conditions as described by Anthony et al. [6] does not emit as
much gCO2eq as common heating or lighting. Note that the relationship
7
Sustainable Computing: Informatics and Systems 38 (2023) 100864
between energy consumption and carbon emission is specific to each
country, and impose great variance. For example, training your model
in Estonia will yield about 64 times more CO2 eq emission than training
it in Iceland, and training some model for twice as many epochs will
yield an emission about twice as big. The measurements are supposed
to reflect a representative training session.
4.2. Experiment №2: Running an automated data science project on multi-
ple hardware architectures
Figs. 4 and 5 are ordered and indexed to be consistent to each other,
and to Table 2. It is visible how Fig. 4 has an ascending trend from top
to bottom, while Fig. 5 has a descending trend from top to bottom. This
indicates that the CPUs that are capable of drawing the most power end
up consuming the least amount of energy for the same task at the end.
Fig. 5 shows similar results for both the RAPL measurements and
CarbonTracker measurements, except for the case for hardware №3.
Nonetheless, a couple of things stand out.
As a first observation, an 8th generation Intel i7-8550 consumes
more energy than a 7th generation Intel i7-7700. Likely, the fact that
the latter clocks in at 2.80 GHz, a full 1.00 GHz more than the former,
is responsible for this difference.
Secondly, the rest of the CPUs (indices 2, 1 and 0) show a declin-
ing trend for energy consumption for the same tasks for augmenting
generations (7, 10 and 11 respectively). This indicates that, while a
big jump in CPU frequency will improve performance and energy
consumption (as described above), more recent CPU generations and/or
more threads also benefit these metrics, even if the clock speed drops.
Lastly, the overall power consumption varies for the most part
between 25 W and 75 W, which is not entirely inconsistent with [24],
but appear to be on the higher end. This is likely due to the fact
that more modern machines are generally capable of higher power
throughput. A trend already visible in Fig. 4. The most consistent value
is hardware structure №3, which was released in 2017, closer to the
publication date of [24] than the other hardware architectures (2017,
2020 and 2021 for hardware indices 2, 1 and 0 respectively).
4.3. Projection
Fig. 6 shows an estimated projection of the total amount of energy
some hardware structure would consume while performing an auto-
mated data science task (𝐸𝐴𝑢𝑡𝑜𝐷𝑆 ) using the TDP as an input parameter.
Using the TDP as a proxy for power consumption has caveats, as
explained further in Section 4.5. The 𝑦-axis is in log-scale, to make
the relative error apparent, rather than an absolute error. The 𝑥-axis
is in log-scale to better show the relationship for lower values of TDP,
which are more common (see Fig. 7). Also note that this Figure does not
include any estimations on the error due to variance between different
data scientists or different workflows. It is clear that any estimation on
the power consumption of common data science cannot be truthfully
extrapolated to machines with a TDP larger than the ones considered
in this manuscript. For values equal or lower to the ones considered in
this manuscript, the relative error on the estimated 𝐸𝐴𝑢𝑡𝑜𝐷𝑆 remains
steady around 100%, supporting the belief that these extrapolation
are very crude estimates at best. Given the low amount of datapoints
and relatively high variance even for these sparse datapoints, this is
unsurprising. If a better extrapolation is to be made, more data needs
to be gathered for various hardware structures. This would also open
up the possibility of assessing the accuracy of using TDP as an input
variable for total energy consumption of some hardware structure.
B. Meulemeester and D. Martens
4.4. Hardware comparison
Fig. 7 shows a distribution of the Thermal Design Power (TDP) of all
CPUs recorded by Passmark [20]. The distribution does not represent
the relative frequency of these CPUs; each CPU is a single datapoint,
independent of its popularity in modern hardware. It shows how the
CPU used in Experiment №1 yields a TDP of 15.0 W compared to the
median TDP of 51.0 W. The additional CPUs considered in Experiment
№2 yield TDP values of 45.0 W. Measurements of the tasks as described
in Sections 2.1 and 2.2 may yield different values when performed on
other hardware. Previous results indicate that CPUs with a higher TDP
are less energy-consuming for the same task, and the results in this
work are conservative, likely reporting higher numbers than the results
on a CPU with a median TDP of 51 W.
4.5. Assumptions revisited
Let us revisit the assumptions made in Section 2.3 and verify if they
hold true, or in which way they should be adapted. They are numbered
in the same way as in Section 2.3
1. The exact contribution of RAM is not measured in this work,
and the estimated power consumption ratio of CPU to RAM
3 ∶ 2 remains an estimated value, adding additional uncertainty
to the reported values. The power consumption of the screen
is also not reported. However, when considering the power
consumption of the task ‘‘Baseline (idle)’’ in Fig. 1, it is visible
how screen use does not contribute substantially to the overall
power consumption of some task, contributing about 2 W in
total.
2. The differences of energy consumption and associated carbon
emission of the automated data science project across the consid-
ered hardware architectures (see Fig. 5) could be extrapolated to
other hardware architectures by considering the TDP as relevant
parameter (see Fig. 7). However, there is insufficient data to as-
sess the exact nature of this relationship, be it linear, exponential
or a power-law for example. In addition, there are some caveats
when using the TDP as a metric for power consumption of a CPU:
• The TDP values from the manufacturers are often incor-
rect [25]. The authors are e.g. sceptical of the fact that 3
out of 4 considered CPUs are reported to have a TDP of
exactly 45.0 W.
• They only apply when the CPU is under full load on all
cores, which is rare in most cases, but not uncommon
during some stages of data science (e.g. performing a
gridsearch).
• Actual power usage can be altered when the computer is
running via power plans (e.g. switching to battery power).
• They do not take into account the electrical usage of other
components, such as the screen, hard drive, RAM, etc.
For these reasons, our comparison between common data science
to other tasks, as visible in Fig. 3 reports the most conservative
measured value for performing common data science (i.e. on the
least energy efficient hardware structure).
3. We have assumed an inverse relationship between the 𝑇 𝐷𝑃 and
𝐸𝐴𝑢𝑡𝑜𝐷𝑆 of the shape 𝐸𝐴𝑢𝑡𝑜𝐷𝑆 = 𝑎∕𝑇 𝐷𝑃 + 𝑏. While this inverse
relationship is apparent in Fig. 5, and it is sensible to assume that
more powerful CPUs are also more efficient, despite drawing
more power for a short amount of time, the exact nature of this
relationship is an educated guess. Apart from the large range of
possible fits, as seen in Fig. 6, the relationship may well be not
perfectly inverse. The fact that multiple points have the same
TDP and different values for 𝐸𝐴𝑢𝑡𝑜𝐷𝑆 already suggests that TDP
is not a perfect predictor, as already discussed in Section 4.3. A
trend is not yet visible, due to the low variance in measured TDP
values.
8
Sustainable Computing: Informatics and Systems 38 (2023) 100864
4. The conversion of gCO2 eq to km driven by car is based on
the EU average from 2019. European Environment Agency EEA
[23] shows a clear declining trend in car emission. The values
expressed in the latter unit in this paper will become increasingly
outdated every year. Of course, due to the variance in carbon
emission for each car, the values also vastly differ depending on
which car you consider.
5. As already mentioned at the end of Section 4.1, the conversion
from energy to gCO2 eq depends heavily on which country you
consider. Outsourcing heavy computational work to countries
with a greener energy production can substantially decrease the
carbon footprint.
To estimate the additional contribution of common data science to
the global GHGe, let us use the results and the revisited assumptions to
compare common data science to regular computer usage. When using
the RAPL measurements, scaling everything to the same duration, and
under the assumptions that the relative difference in energy usage be-
tween a data science project and normal computer usage in Experiment
№1 is representative for other computer users, data scientists and data
science in general.
The extra load in global GHGe of common data science when
compared to normal computer usage for a single device (hardware
index 3) is equal to
𝐸𝐷𝑎𝑡𝑎𝑠𝑐𝑖𝑒𝑛𝑐𝑒𝑃 𝑟𝑜𝑗𝑒𝑐𝑡 8 hr 100.00 Wh
=
𝐸𝑁𝑜𝑟𝑚𝑎𝑙𝑈 𝑠𝑎𝑔𝑒 9.1 hr 34.72 Wh (7)
= 2.57
This value can only be extrapolated to other hardware architectures
under the condition that any change in hardware architecture has
an equal effect on both measurements. It is not improbable that one
measurement would benefit more from e.g. a more efficient processor
than the other. This makes this result unsuitable for extrapolation to
other hardware types, as an error on such an extrapolation cannot be
assessed a priori.
In order to estimate the additional load in GHGe due to common
data science on a global scale, rather than for a single device, one would
have to link this value to the relative global GHGe of household ICT
devices of 45% [10]. To do so, one would need a value for how many
of these devices are used for data science (and how often), which is
very hard to obtain.
5. Conclusion
The results made clear that common data science (i.e. any form of
data science that can be performed on your laptop at home) requires
substantially more power than other common computer tasks, yielding
an associated carbon footprint that is about 2.57 times higher than
normal computer usage. Keeping in mind that data science jobs have
been on a steady popularity increase over the last few years, this implies
a higher global GHGe associated with common data science.
When comparing common data science to advanced data science, it
is clear how the power consumption increases exponentially along with
the complexity of the data science. While advanced data science tasks,
such as training GPT-3, require a substantial amount of power, this is
not the case for common data science.
CPUs with a higher power profile appear to use their power more
efficiently, ultimately leading to a lower total energy consumption, and
thus a lower associated carbon footprint.
The reported results in this manuscript are not suitable to be extrap-
olated to other hardware architectures. More data is needed to open up
the possibility for such an estimate.
The results and discussion considered a very conservative estimate
of the carbon footprint of common data science. Even with this value in
mind, common data science does not appear to contribute substantially
to the global carbon emissions compared to other everyday tasks.
B. Meulemeester and D. Martens
While the uprising in data science jobs can indeed be associated with
an increased carbon footprint, it will prove much more substantial
to be mindful about the power consumption and associated carbon
emission of some everyday tasks. Efficient heaters and lighting, insu-
lation, green energy production and green travel methods will always
beat, by a landslide, preferring e.g. a RandomsearchCV() over a
GridsearchCV() when doing common data science.
That does not mean, however, that efforts to reduce the carbon
footprint of common data science are in vain. Mindfulness of the
environmental impact of data science remains important, whether it
is applied to common or large-scale data science. The methods de-
scribed in this work can be used for both. Such mindfulness has not
been reached, given the absence of such numbers in hyper-scale data
science projects such as GPT-3 and DALL⋅E, but also in most other
data science related works. If the reporting of the carbon footprint
of data science becomes ubiquitous, independent of the scale of the
data science project, it would unlock the possibility of assessing the
contribution of common and advanced data science to global GHGe to
a much more precise and realistic degree.
CRediT authorship contribution statement
Bjorge Meulemeester: Conceptualization, Data curation, Formal
analysis, Investigation, Methodology, Resources, Software, Validation,
Visualization, Roles/Writing – original draft, Writing – review & edit-
ing. David Martens: Conceptualization, Funding acquisition, Investiga-
tion, Methodology, Project administration, Supervision, Roles/Writing
– original draft, Writing – review & editing.
Declaration of competing interest
The authors declare that they have no known competing finan-
cial interests or personal relationships that could have appeared to
influence the work reported in this paper.
Data availability
How the data on energy usage is obtained is described in de-
tail. We encourage readers to report the same numbers on their own
architecture and data science project.
References
[1] M. Hiransha, E.A. Gopalakrishnan, V.K. Menon, K. Soman, NSE stock mar-
ket prediction using deep-learning models, Procedia Comput. Sci. 132 (2018)
1351–1362.
[2] A. Toth, L. Tan, G. Di Fabbrizio, A. Datta, Predicting shopping behavior with
mixture of RNNs, 2017, ecom@ sigir.
[3] T.B. Brown, B. Mann, N. Ryder, M. Subbiah, J. Kaplan, P. Dhariwal, A.
Neelakantan, P. Shyam, G. Sastry, A. Askell, S. Agarwal, A. Herbert-Voss, G.
Krueger, T. Henighan, R. Child, A. Ramesh, D.M. Ziegler, J. Wu, C. Winter, C.
Hesse, M. Chen, E. Sigler, M. Litwin, S. Gray, B. Chess, J. Clark, C. Berner,
S. McCandlish, A. Radford, I. Sutskever, D. Amodei, Language models are few-
shot learners, 2020, http://dx.doi.org/10.48550/ARXIV.2005.14165, URL: https:
//arxiv.org/abs/2005.14165.
Sustainable Computing: Informatics and Systems 38 (2023) 100864
[4] A. Rizwan, A. Zoha, I.B. Mabrouk, H.M. Sabbour, A.S. Al-Sumaiti, A. Alomainy,
M.A. Imran, Q.H. Abbasi, A review on the state of the art in atrial fibrillation
detection enabled by machine learning, IEEE Rev. Biomed. Eng. 14 (2020)
219–239.
[5] M. Holmstrom, D. Liu, C. Vo, Machine learning applied to weather forecasting,
Meteorol. Appl. 10 (2016) 1–5.
[6] L.F.W. Anthony, B. Kanding, R. Selvan, Carbontracker: Tracking and predicting
the carbon footprint of training deep learning models, 2020, arXiv:2007.03051.
[7] G. Cook, J. Lee, T. Tsai, A. Kongn, J. Deans, B. Johnson, E. Jardim, B. Johnson,
Clicking Clean: Who Is Winning the Race to Build a Green Internet? Technical
report, Greenpeace, 2017.
[8] E. Masanet, A. Shehabi, N. Lei, S. Smith, J. Koomey, Recalibrating global
data center energy-use estimates, Science 367 (6481) (2020) 984–986, http:
//dx.doi.org/10.1126/science.aba3758.
[9] Z. Cao, X. Zhou, H. Hu, Z. Wang, Y. Wen, Towards a systematic survey for
carbon neutral data centers, 2022, arXiv:2110.09284.
[10] L. Belkhir, A. Elmeligi, Assessing ICT global emissions footprint: Trends
to 2040 & recommendations, J. Clean. Prod. 177 (2018) 448–463, http://
dx.doi.org/10.1016/j.jclepro.2017.12.239, URL: https://www.sciencedirect.com/
science/article/pii/S095965261733233X.
[11] IEA, Global data centre energy demand by data centre type, 2010–2022,
2021, https://www.iea.org/data-and-statistics/charts/global-data-centre-energy-
demand-by-data-centre-type-2010-2022. (Last accessed 08 March 2022).
[12] R. Bashroush, A. Lawrence, Beyond PUE: Tackling IT’s Wasted Terawatts, Uptime
Institute, 2020, Available from: https://uptimeinstitute.com/beyond-puetackling-
it’s-wasted-terawatts. (Accessed 11 June 2020).
[13] N. Rteil, R. Bashroush, R. Kenny, A. Wynne, Interact: IT infrastructure energy
and cost analyzer tool for data centers, Sustain. Comput. Inform. Syst. 33
(2022) 100618, http://dx.doi.org/10.1016/j.suscom.2021.100618, URL: https:
//www.sciencedirect.com/science/article/pii/S2210537921001062.
[14] News LinkedIn, LinkedIn jobs on the rise 2022: The 25 U.S. roles that are
growing in demand, 2022, https://www.linkedin.com/pulse/linkedin-jobs-rise-
2022-25-us-roles-growing-demand-linkedin-news. (Last accessed 28 February
2022).
[15] News LinkedIn, LinkedIn jobs on the rise 2022: The roles that are grow-
ing in demand, 2022, https://www.linkedin.com/pulse/linkedin-jobs-rise-2022-
roles-growing-demand-linkedin-news-europe/. (Last accessed 28 February 2022).
[16] A. Ramesh, M. Pavlov, G. Goh, S. Gray, C. Voss, A. Radford, M. Chen, I.
Sutskever, Zero-shot text-to-image generation, 2021, http://dx.doi.org/10.48550/
ARXIV.2102.12092, URL: https://arxiv.org/abs/2102.12092.
[17] B. Meulemeester, D. Martens, How sustainable is ‘‘common’’ data science
in terms of power consumption? 2022, URL: https://github.com/bgmeulem/
EmissionCommonDS.
[18] electricpoint, Electric heating room size calculator, 2022, https://www.
electricpoint.com/heating/electric-heating/how-to-calculate-kw-required-to-
heat-a-room. (Last accessed 01 March 2022).
[19] ICAO, ICAO carbon emissions calculator, 2016, https://www.icao.int/
environmental-protection/CarbonOffset/Pages/default.aspx. (Last accessed
01 March 2022).
[20] Passmark, CPU mega list, 2022, https://www.cpubenchmark.net/CPU_mega_
page.html. (Last accessed 01 March 2022).
[21] European Environment Agency EEA, Greenhouse gas emission intensity of
electricity generation by country, 2021, https://www.eea.europa.eu/data-and-
maps/daviz/co2-emission-intensity-9. (Last accessed 04 February 2022).
[22] K. Protocol, Kyoto Protocol, UNFCCC Website, 1997, Available Online: http:
//unfccc.int/kyoto_protocol/items/2830.php. (Accessed 1 January 2011).
[23] European Environment Agency EEA, CO2 performance of new passenger
cars in Europe, 2021, https://www.eea.europa.eu/ims/co2-performance-of-new-
passenger. (Last accessed 04 February 2022).
[24] A. Menezes, A. Cripps, R. Buswell, J. Wright, D. Bouchlaghem, Estimating
the energy consumption and power demand of small power equipment in
office buildings, Energy Build. 75 (2014) 199–209, http://dx.doi.org/10.1016/
j.enbuild.2014.02.011, URL: https://www.sciencedirect.com/science/article/pii/
S0378778814001224.
[25] I. Cutress, Why intel processors draw more power than expected: TDP
and turbo explained, 2018, https://www.anandtech.com/show/13544/why-intel-
processors-draw-more-power-than-expected-tdp-turbo. (Last accessed 08 March
2022).