# Empirical Analysis and Estimation of the Energy Cost of Data Transfers in CPU Caches in Multi-Core Systems

Gaëtan Barret, Joël Penhoat, Roland Picard, Daniel Chillet

► To cite this version:

Gaëtan Barret, Joël Penhoat, Roland Picard, Daniel Chillet. Empirical Analysis and Estimation of the Energy Cost of Data Transfers in CPU Caches in Multi-Core Systems. MECO 2025 - 14th Mediterranean Conference on Embedded Computing, Mediterranean Embedded Computing Resources (MECO), Jun 2025, Budva, Montenegro. pp.1-4, 10.1109/MECO66322.2025.11049192. hal-05273552

HAL Id: hal-05273552

https://hal.science/hal-05273552v1

Submitted on 23 Oct 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Empirical Analysis and Estimation of the Energy Cost of Data Transfers in CPU Caches in Multi-Core Systems

Gaëtan Barret

Orange SA

Lannion, France

gaetan.barret@orange.com

Joël Penhoat

Orange SA

Lannion, France

joel.penhoat@orange.com

Roland Picard

Orange SA

Rennes, France

roland.picard@orange.com

Daniel Chillet

University of Rennes, INRIA/IRISA

Lannion, France

daniel.chillet@irisa.fr

**Abstract**—The quantity of stored data is ever-increasing and this trend is followed by a growth in the data capacity of CPU caches. Caches consume around 30% of a CPU's power, even as the CPU's Thermal Design Power (TDP) continues to rise. All factors combined, the power consumption of caches has become too significant to be overlooked as a standalone component, therefore creating the need for a dedicated power monitoring tool. To address this challenge, we analyze system parameters under memory-intensive workloads and leverage these insights to estimate the energy cost of data transfers within caches using accessible system metrics. Our methodology comprises: (i) configuring system settings and running tailored memory stress tests while collecting data on parameters such as core and uncore frequency, (ii) empirically studying the relationship between the collected energy data and the experimental parameters (iii) choosing various statistical models and validating the model's accuracy using the collected data. Our approach enables the estimation of energy costs associated with data movement across the memory hierarchy, achieving $R^2$ values above 0.95. By leveraging widely available system parameters, this experiment provides insights for a better power consumption understanding and management in power-constrained computing environments.

**Index Terms**— Energy Monitoring, CPU Caches, Data Transfers, Empirical study

## I. INTRODUCTION

The rapid growth in data generation has led to an exponential increase in storage requirements, with forecasts predicting millions of petabytes added annually starting in 2025 [1]. This surge is further accelerated by embedding Large Language Models into robots, drones, and mobile devices. Our current data processing methods, using CPUs, GPUs, FPGAs, and SRAM-based caches, are evolving alongside these storage needs. For instance, Intel's Xeon CPUs show that L3 cache capacities and average TDP are growing exponentially [2], and since about 30% of CPU power is consumed by memory-related circuits [3], cache energy demands are on the rise.

The energy behavior of DRAM and caches is influenced by various factors, including hardware design and operating conditions. For example, DDR4 operates between 1.2V and 1.5V, while DDR5 reduces the base voltage to 1.1V with integrated voltage controllers [4]. Although these advances improve performance, they also complicate energy management in high-bandwidth or variable workload scenarios. Data

movement across the memory hierarchy—from L1 to L3 caches and DRAM—is highly energy-intensive, with prefetching mechanisms further increasing energy use [5].

While tools like RAPL measure energy consumption in DRAM, packages, and cores, they lack a cache-specific domain. This work introduces a model to estimate energy costs across the memory hierarchy—focusing on caches—using accessible system metrics, representing a foundational step toward more energy-efficient computing. This article is organized as follows, in Part II, we review the related works on energy consumption in memory systems. Part III presents the experimental stress test and data generation process, while Part IV details the modeling approach and the experimental results. Finally, the article concludes with discussions on the findings and potential future work.

## II. RELATED WORKS

The energy consumption of memory systems, particularly DRAM, is a critical challenge in modern computing architectures. Over the years, researchers have devoted significant effort to understanding and managing DRAM power usage. Early work by Vogelsang [6] laid the foundation by identifying key contributors such as row activation, precharging, and data transfer. Subsequent studies, including Ghose et al.'s work with the VAMPIRE power model [7], have revealed that real-world DRAM energy consumption can differ markedly from vendor specifications. DRAM energy measurements tools are validated for each CPU generation over the past 10 years since the introduction of DRAM RAPL scope [8]–[10] showing a worsening of the measurement in the newer generations.

In contrast, while caches have received some attention, for example Mittal's reconfiguration techniques for embedded DRAM caches [11] and Babaie et al.'s Tag-enhanced DRAM for caching optimization [12], they have not been studied with the same depth as DRAM. In the case of caches innovations resides in their design, either focusing on reducing energy consumption through static power reduction [13] or focusing on increasing their quantity for memory intensive use cases [14]. None of those innovation aim to provide information to the operating system or the user. Given that caches play a major role in bridging the processor and the DRAM, similar
comprehensive research as done for DRAM are necessary. In summary, extensive research into DRAM power management has yielded valuable techniques and models for reducing energy consumption. To fully optimize modern memory hierarchies, it is imperative that the cache subsystem receives the same level of attention with the development of measurement tools for caches.

### III. EXPERIMENTAL STRESS TEST AND DATA GENERATION

Our goal being to understand and model the energy cost of transmitting a cache line through the DRAM and caches, we designed a custom Python / C / Assembly stress test aiming to manipulate cache lines while observing energy and power consumption variations through the RAPL interfaces.

A cache line is to be considered as the smallest unit we can transmit in the memory system. Each data item or instruction is stored in a 64-byte cache line, with additional system overhead handled by the operating system [15].

For the first step the system is initialized by retrieving the cache hierarchy, total RAM, page size, RAPL scopes, and DRAM specifications. Then, the test is configured by parsing command-line arguments to set stabilization time, execution duration, and frequency ranges (for both CPU and uncore), along with NUMA node and core selections. For each combination of CPU and uncore frequencies and for each NUMA node, the system sets the frequencies, generates a configuration file, and launches the memory_stressing workload while logging Core and Uncore frequencies, timestamps and RAPL measurements. The memory_stressing workload executes prefetches followed by memory operations (READ, WRITE, or no-op) over multiples iteration for each parameter combination defined. In our case, we narrowed the values of many parameters to keep in check the duration of the experiment resulting in 16465 entires of data. The prefetching operation are done number iterations times to reach a certain duration target, always to keep the stress test to not last too long while generating enough data. In this case the target was 10 seconds.

We define a typical data entry of our stress test as $X = \{D, f_c, f_u, C, \text{Operation}, \text{Prefetch}_{\text{Hint}}, n\}$ and $Y = \{y_{s,p} : s \in \{\text{CORE}, \text{PACKAGE}, \text{DRAM}\}, p \in \{\text{allocation}, \text{initialization}, \text{prefetch}, \text{clflush}, \text{freeing}\}\}$.

where

* $D$ = Data Size Bytes,

* $f_c$ = core_frequency_GHz,

* $f_u$ = uncore_frequency_GHz,

* $C$ = Num_Core,

* $n$ = number iterations.

Data transfers are modeled along two primary paths. The downstream path is: DRAM → L3 → L2 → L1 → Register, and the upstream path is: Register → L1 → L2 → L3 → DRAM. These transfers are initiated by prefetch instructions or specific memory operations and are specific to fully included caches levels.

Table ?? summarizes the operations for data transfers in both downstream and upstream directions. It specifies the

memory hierarchy access patterns for each prefetch hints (downstream) under both the "NOTHING" and "WRITE or READ" operations, as well as upstream using CLFLUSH instructions. In Table ?? some levels are put into parenthesis to highlight that those levels are active because of the operations WRITE and READ, causing data manipulation at CPU register level, implying the use of all levels of cache even after using a hint not requiring all the caches level.

<table><caption>TABLE I
MEMORY HIERARCHY ACCESS FOR EACH OPERATION: WRITE/READ DIFFERENCES VS. NOTHING</caption><thead><tr><th rowspan="2">Stream</th><th rowspan="2">Instruction</th><th colspan="2">Operation</th></tr><tr><th>No-Operation (Ø)</th><th>(Ø) + WRITE / READ</th></tr></thead><tbody><tr><td rowspan="3">DOWN</td><td>Prefetch TNA</td><td>DRAM → L3 → L2 → L1</td><td>DRAM → L3 → L2 → L1 → REG</td></tr><tr><td>Prefetch T0</td><td>DRAM → L3 → L2 → L1</td><td>DRAM → L3 → L2 → L1 → REG</td></tr><tr><td>Prefetch T1</td><td>DRAM → L3 → L2</td><td>DRAM → L3 → L2 → L1 → REG</td></tr><tr><td>Prefetch T2</td><td>DRAM → L3</td><td>DRAM → L3 → L2 → L1 → REG</td></tr><tr><td>UP</td><td>Clflush</td><td>DRAM ← L3 ← L2 ← L1</td><td>DRAM ← L3 ← L2 ← L1 → REG</td></tr></tbody></table>

The test system is an Intel Xeon 2224, which is characterized by a 4 MiB page size (default on Linux), a 64-byte cache line, and the following cache specifications: L1 caches (data and instruction) of 32 KiB with 8-way set-associativity, an L2 cache of 256 KiB with 4-way set-associativity, and an L3 cache of 8 MiB total (divided into 2 MiB slices per core with 16-way set-associativity). Additionally, the DRAM size is 16 GiB. The whole experiment is conducted with hardware_prefetcher enabled and adjacent_lines prefetcher enabled as well as both options are extremely rarely disabled on systems.

### IV. MODEL AND RESULTS

In real world applications, the current type of operation is unknown, even when using performance counters the doubt can still persist. The same applies to the cache level at which a cache line is sent. Thus, the model will need to use the most basics available data, which are typically systems data, that are provided by the entries generated using our stress test.

The RAPL counters used in the experiment are subject to overflow during the stress-test. The maximum value is retrieved from the Linux system configuration and is defined as WRAP_VALUE = 262143328850. Equation (1) shows our method to manage RAPL counter overflow using start and end, which refer to the first and last measurements for a given parameter combination.

$$ \Delta = \begin{cases} \text{end} - \text{start}, & \text{if end} \ge \text{start}, \\ (\text{end} - \text{start}) + \text{WRAP_VALUE}, & \text{if end} < \text{start.} \end{cases} \quad (1) $$

For the energy consumption computation, we have:

* **Downstream (repeated execution):**

$$ E_{\text{downstream}} = \frac{\Delta \times 10^{-6}}{n \times D} \times 64, \quad (2) $$

where Δ is the wrap-around corrected difference, n is the number of iterations, and D is the data size in bytes.

* **Upstream (one-shot execution):**

$$ E_{\text{upstream}} = \frac{\Delta \times 10^{-6}}{D} \times 64. \quad (3) $$
* **Power calculation:** The power is computed as the energy divided by the elapsed time (with time converted from nanoseconds to seconds):

$$P = \frac{E}{t \times 10^9}, \qquad (4)$$

where E is the energy consumption (in Joules) and t is the elapsed time in nanoseconds.

For modeling, we use the previously defined variables D, C, f_c, and f_u to form the 4-dimensional feature vector:

$$\mathbf{x} = [x_1, x_2, x_3, x_4]^T,$$

where each $x_i$ is the standardized version of the corresponding variable.

The target consumption metric y is defined based on the energy computation as:

$$y = \begin{cases} E_{\text{downstream}}, & (\text{for Downstream}); \\ E_{\text{upstream}}, & (\text{for Upstream}). \end{cases}$$

The goal is to learn a mapping f such that:

$$y \approx f(\mathbf{x}).$$

To estimate the cache energy consumption, we employ three regression models:

* **Linear Regression** assumes a linear relationship between the standardized inputs and the target.

* **Random Forest Regressor** aggregates predictions from multiple decision trees to capture non-linear interactions.

* **Gradient Boosting Regressor** sequentially combines weak learners to improve prediction accuracy.

The experimental results, shown in Table II, reveal that normalizing energy consumption into power (energy per unit time) significantly affects the behavior of system parameters. Both core and uncore frequencies show a positive relationship with energy and power; however, the correlation is weaker for power. This indicates that while higher frequencies increase energy usage, they also speed up operations, reducing the instantaneous power value. In contrast, data size changes from having a near-zero or slightly positive effect on energy to a moderately negative effect on power. This suggests that larger data sizes extend execution times, thereby lowering the average power even as absolute energy consumption rises.

The regression analysis further confirm the observations of non linear relationship between the parameters as depicted in Table IV. Non-linear models—specifically, Random Forest and Gradient Boosting regressors—achieve $R^2$ values often exceeding 0.95 for the CORE and PACKAGE scopes, out-performing Linear Regression. This result shows that the relationship between input parameters and energy consumption is non-linear. For the DRAM scope, model differences are less pronounced, implying that additional parameters are needed to fully capture DRAM energy behavior such as memory operations (READ, WRITE, or no-op) which are difficult to monitor in non-experimental conditions. This lack of precision for the DRAM scope highlight well the limitations of the models, mostly due to a lack of data accessibility. Our model could be improved by accessing Core and Uncore input voltages

as well, but currently, monolithic CPU (mostly Intel based) only provide input voltage for the Core and not the Uncore which led us to prefer using a common metric instead of incomparable ones. Our model, being based on existing RAPL also suffer from the error measurements of RAPL DRAM scope [8]–[10] which cannot be treated with our current setup.

Lastly, as one of our primary goal is to estimate a rough energy cost of transmitting a cache line within the whole DRAM to cache communication pipeline we established cost range across our whole dataset. Table III shows the energy cost range of passing a cache line through each RAPL scope. As expected, the PACKAGE scope's energy cost is higher than the CORE scope's energy cost as it encapsulate the CORE scope. In term of either energy and power cost of transmitting a cache line we can observe that the CORE is the most energy hungry part of the memory pipeline giving that its power consumption is included in the PACKAGE while representing 80% of the maximum PACKAGE energy consumption and 70% of its power consumption. These observations highlight the necessity for a dedicated energy and power monitoring solution specifically for caches as it would focus on the most power hungry components of memory intensive use cases.

## V. CONCLUSION

In this paper, we designed a custom memory-intensive stress test to observe energy and power variations, laying the groundwork for the development of a dedicated RAPL tool for cache monitoring. Our work demonstrates that when aiming to understand energy consumption both energy and power need to be addressed simultaneously as both capture distinct yet complementary aspects of the system behavior. Energy consumption measures total resource usage, while power (energy per unit time) reflects performance efficiency and possible bottlenecks. Our correlation analysis showed that the most important parameters for cache energy and power usage are the Core and Uncore frequencies, the quantity of data to transmit and the number of cores transmitting data in parallel. When modeling the energy consumption of a cache line transmission for all RAPL scopes the strong performance of non-linear regression models underscores the complexity of our parameters relationships while having confidence in the results $R^2 \ge 95\%$. Our work demonstrates that with the right system parameters, it is possible to develop a RAPL-like interface dedicated to cache monitoring. Future should also include the use of temporal data such as temperature known to have a deep relation on leakage currents thus impacting the power consumption. Other parameters like a transistor decay factor could also be of use in the study of power consumption as their efficiency can drop over time. For embedded systems, where energy efficiency is critical, our findings highlight the need for more power monitoring tools ranging across all functional components of the system. Such monitoring will enable dynamic energy management strategies, optimize power distribution, and ensure that even resource-constrained devices operate in respect to their available power resources.
<table><caption>TABLE II
DETAILED CORRELATION ANALYSIS BETWEEN EXPERIMENTAL PARAMETERS AND ENERGY/POWER FOR CORE, PACKAGE, AND DRAM SCOPES. EACH SCOPE IS SPLIT BY PREFETCH AND CLFLUSH OPERATIONS WITH SEPARATE ENERGY AND POWER COLUMNS.</caption><thead><tr><th rowspan="3">Parameter</th><th colspan="4">CORE</th><th colspan="4">PACKAGE</th><th colspan="4">DRAM</th></tr><tr><th colspan="2">Prefetch</th><th colspan="2">Clflush</th><th colspan="2">Prefetch</th><th colspan="2">Clflush</th><th colspan="2">Prefetch</th><th colspan="2">Clflush</th></tr><tr><th>Energy</th><th>Power</th><th>Energy</th><th>Power</th><th>Energy</th><th>Power</th><th>Energy</th><th>Power</th><th>Energy</th><th>Power</th><th>Energy</th><th>Power</th></tr></thead><tbody><tr><td><strong>Prefetch_Hint</strong></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>PREFETCH_TO</td><td>-0.0011</td><td>-0.0092</td><td>0.0006</td><td>0.0043</td><td>-0.0007</td><td>-0.0098</td><td>0.0006</td><td>0.0048</td><td>0.0182</td><td>-0.0115</td><td>0.0005</td><td>0.0066</td></tr><tr><td>PREFETCH_T1</td><td>-0.0012</td><td>0.0043</td><td>-0.0003</td><td>0.0033</td><td>-0.0013</td><td>0.0048</td><td>-0.0003</td><td>0.0036</td><td>-0.0054</td><td>0.0066</td><td>-0.0003</td><td>0.0045</td></tr><tr><td>PREFETCH_T2</td><td>0.0012</td><td>0.0030</td><td>-0.0007</td><td>0.0018</td><td>0.0011</td><td>0.0031</td><td>-0.0008</td><td>0.0020</td><td>-0.0034</td><td>0.0034</td><td>-0.0008</td><td>0.0023</td></tr><tr><td>PREFETCH_NTA</td><td>0.0011</td><td>0.0019</td><td>0.0004</td><td>0.0010</td><td>0.0009</td><td>0.0019</td><td>0.0005</td><td>0.0011</td><td>-0.0094</td><td>0.0015</td><td>0.0006</td><td>0.0013</td></tr><tr><td><strong>Operations</strong></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>OP_WRITE</td><td>0.0054</td><td>-0.0466</td><td>0.0374</td><td>-0.0328</td><td>0.0278</td><td>-0.0464</td><td>0.0405</td><td>-0.0345</td><td>0.6023</td><td>-0.0347</td><td>0.0370</td><td>-0.0398</td></tr><tr><td>OP_NOTHING</td><td>-0.0023</td><td>0.0458</td><td>-0.0469</td><td>0.0325</td><td>-0.0129</td><td>0.0467</td><td>-0.0511</td><td>0.0343</td><td>-0.2234</td><td>0.0500</td><td>-0.0469</td><td>0.0395</td></tr><tr><td>OP_READ</td><td>-0.0031</td><td>0.0008</td><td>0.0096</td><td>0.0003</td><td>-0.0149</td><td>-0.0003</td><td>0.0105</td><td>0.0002</td><td>-0.3790</td><td>-0.0153</td><td>0.0099</td><td>0.0003</td></tr><tr><td><strong>Continuous Variables</strong></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>core_frequency_GHz</td><td>0.5915</td><td>0.1555</td><td>0.2021</td><td>0.1847</td><td>0.5875</td><td>0.1505</td><td>0.1085</td><td>0.1625</td><td>0.1883</td><td>0.1154</td><td>-0.1218</td><td>0.0814</td></tr><tr><td>uncore_frequency_GHz</td><td>0.5446</td><td>0.1921</td><td>0.1680</td><td>0.24698</td><td>0.5443</td><td>0.1905</td><td>0.0492</td><td>0.22740</td><td>0.3203</td><td>0.1729</td><td>-0.2196</td><td>0.13773</td></tr><tr><td>Num_Stressed_Core</td><td>0.4825</td><td>0.0847</td><td>0.0732</td><td>0.0397</td><td>0.4899</td><td>0.0761</td><td>0.0549</td><td>0.03414</td><td>0.5276</td><td>0.0387</td><td>0.0009</td><td>0.00912</td></tr><tr><td>Data_Size_Bytes</td><td>-0.0012</td><td>-0.2384</td><td>0.8111</td><td>-0.34665</td><td>-0.0008</td><td>-0.2522</td><td>0.9162</td><td>-0.37116</td><td>0.0382</td><td>-0.3060</td><td>0.9085</td><td>-0.44746</td></tr></tbody></table>

<table><caption>TABLE III
SUMMARY OF MINIMUM AND MAXIMUM ENERGY AND POWER COSTS PER CACHE LINE FOR DIFFERENT SCOPES.</caption><thead><tr><th>Scope</th><th>Min Energy (J)</th><th>Max Energy (J)</th><th>Min Power (W)</th><th>Max Power (W)</th></tr></thead><tbody><tr><td>CORE_PREFETCH</td><td>4.0 × 10<sup>-8</sup></td><td>1.3 × 10<sup>-6</sup></td><td>1.0 × 10<sup>-8</sup></td><td>1.26 × 10<sup>-4</sup></td></tr><tr><td>CORE_CLFLUSH</td><td>3.0 × 10<sup>-8</sup></td><td>4.7 × 10<sup>-7</sup></td><td>1.0 × 10<sup>-8</sup></td><td>7.04 × 10<sup>-5</sup></td></tr><tr><td>PACKAGE_PREFETCH</td><td>1.5 × 10<sup>-7</sup></td><td>1.5 × 10<sup>-6</sup></td><td>5.0 × 10<sup>-8</sup></td><td>1.38 × 10<sup>-4</sup></td></tr><tr><td>PACKAGE_CLFLUSH</td><td>1.2 × 10<sup>-7</sup></td><td>5.8 × 10<sup>-7</sup></td><td>5.0 × 10<sup>-8</sup></td><td>9.60 × 10<sup>-5</sup></td></tr><tr><td>DRAM_PREFETCH</td><td>3.0 × 10<sup>-8</sup></td><td>1.7 × 10<sup>-7</sup></td><td>2.0 × 10<sup>-8</sup></td><td>1.22 × 10<sup>-5</sup></td></tr><tr><td>DRAM_CLFLUSH</td><td>2.0 × 10<sup>-8</sup></td><td>1.1 × 10<sup>-7</sup></td><td>2.0 × 10<sup>-8</sup></td><td>8.65 × 10<sup>-6</sup></td></tr></tbody></table>

<table><caption>TABLE IV
REGRESSION EVALUATION METRICS FOR CONSUMPTION METRICS (RMSE IN SCIENTIFIC NOTATION)</caption><thead><tr><th>Consumption Metric</th><th>Model</th><th>RMSE</th><th>R<sup>2</sup></th></tr></thead><tbody><tr><td rowspan="3">core_prefetch</td><td>Linear Regression</td><td>1.1904 × 10<sup>-7</sup></td><td>0.6339</td></tr><tr><td>Random Forest</td><td>3.9977 × 10<sup>-8</sup></td><td>0.9587</td></tr><tr><td>Gradient Boosting</td><td>4.0197 × 10<sup>-8</sup></td><td>0.9583</td></tr><tr><td rowspan="3">core_clflush</td><td>Linear Regression</td><td>6.4678 × 10<sup>-8</sup></td><td>0.4177</td></tr><tr><td>Random Forest</td><td>1.1266 × 10<sup>-8</sup></td><td>0.9823</td></tr><tr><td>Gradient Boosting</td><td>1.5586 × 10<sup>-8</sup></td><td>0.9662</td></tr><tr><td rowspan="3">package_prefetch</td><td>Linear Regression</td><td>1.3125 × 10<sup>-7</sup></td><td>0.5594</td></tr><tr><td>Random Forest</td><td>5.3895 × 10<sup>-8</sup></td><td>0.9257</td></tr><tr><td>Gradient Boosting</td><td>5.3446 × 10<sup>-8</sup></td><td>0.9269</td></tr><tr><td rowspan="3">package_clflush</td><td>Linear Regression</td><td>7.2661 × 10<sup>-8</sup></td><td>0.2002</td></tr><tr><td>Random Forest</td><td>1.0084 × 10<sup>-8</sup></td><td>0.9846</td></tr><tr><td>Gradient Boosting</td><td>1.7519 × 10<sup>-8</sup></td><td>0.9535</td></tr><tr><td rowspan="3">dram_prefetch</td><td>Linear Regression</td><td>1.5029 × 10<sup>-8</sup></td><td>0.6149</td></tr><tr><td>Random Forest</td><td>1.4210 × 10<sup>-8</sup></td><td>0.6557</td></tr><tr><td>Gradient Boosting</td><td>1.4706 × 10<sup>-8</sup></td><td>0.6312</td></tr><tr><td rowspan="3">dram_clflush</td><td>Linear Regression</td><td>7.5594 × 10<sup>-9</sup></td><td>0.8323</td></tr><tr><td>Random Forest</td><td>1.1771 × 10<sup>-8</sup></td><td>0.5934</td></tr><tr><td>Gradient Boosting</td><td>1.4097 × 10<sup>-8</sup></td><td>0.4169</td></tr></tbody></table>

ACKNOWLEDGMENTS

We acknowledge the use of generative AI tools for grammatical editing during the preparation of this manuscript.

REFERENCES

[1] R. Carlson, “The world is running out of data storage. here’s how dna can save us,” *IEEE Spectrum*, 2024.

[2] Intel, “Intel xeon list,” https://www.intel.com/content/www/us/en/ark/pr oducts/series/595/intel-xeon-processors.html, accessed: 2025-03-14.

[3] “Irjet-v6i3885,” 03 2019.

[4] JEDEC, “Ddr4 specifications,” https://www.jedec.org/sites/default/files/docs/JESD79-4.pdf, accessed: 2025-03-14.

[5] F. Cloutier, “prefetch instructions manual,” https://www.felixcloutier.co m/x86/prefetchh, accessed: 2025-03-14.

[6] T. Vogelsang, “Understanding the energy consumption of dynamic random access memories,” in *Proceedings of the 2010 43rd Annual IEEE/ACM International Symposium on Microarchitecture*. Washington, DC, USA: IEEE/ACM, 2010, pp. 363–374.

[7] S. Ghose et al., “What your dram power models are not telling you: Lessons from a detailed experimental study,” 2018, arXiv preprint arXiv:1807.05102.

[8] H. David, E. Gorbatov, U. R. Hanebutte, R. Khanna, and C. Le, “Rapl: memory power estimation and capping,” in *Proceedings of the 16th ACM/IEEE International Symposium on Low Power Electronics and Design*, ser. ISLPED ’10. New York, NY, USA: Association for Computing Machinery, 2010. [Online]. Available: https://doi.org/10.1145/1840845.1840883

[9] S. Desrochers, C. Paradis, and V. M. Weaver, “A validation of dram rapl power measurements,” in *Proceedings of the Second International Symposium on Memory Systems*, ser. MEMSYS ’16. New York, NY, USA: Association for Computing Machinery, 2016. [Online]. Available: https://doi.org/10.1145/2989081.2989088

[10] L. Alt, A. Kozhokanova, T. Ilsche, C. Terboven, and M. S. Mueller, “An experimental setup to evaluate rapl energy counters for heterogeneous memory,” in *Proceedings of the 15th ACM/SPEC International Conference on Performance Engineering*, ser. ICPE ’24. New York, NY, USA: Association for Computing Machinery, 2024. [Online]. Available: https://doi.org/10.1145/3629526.3645052

[11] S. Mittal, “A cache reconfiguration approach for saving leakage and refresh energy in embedded dram caches,” 2013, arXiv preprint arXiv:1309.7082.

[12] M. Babaie et al., “Tdram: Tag-enhanced dram for efficient caching,” 2024, arXiv preprint arXiv:2404.14617.

[13] P. Praveen and R. K. Singh, “Design of enhanced reversible 9t sram design for the reduction in sub-threshold leakage current with14nm finfet technology,” *ACM Trans. Des. Autom. Electron. Syst.*, vol. 28, no. 6, 2023. [Online]. Available: https://doi.org/10.1145/3616538

[14] J. Wuu, R. Agarwal, M. Ciraula, C. Dietz, B. Johnson, D. Johnson, R. Schreiber, R. Swaminathan, W. Walker, and S. Naffziger, “3d v-cache: the implementation of a hybrid-bonded 64mb stacked cache for a 7nm x86-64 cpu,” in *2022 IEEE International Solid-State Circuits Conference (ISSCC)*, Feb 2022.

[15] Intel, “Intel® 64 and ia-32 architectures software developer’s manuals,” https://www.intel.com/content/www/us/en/developer/articles/technical/i ntel-sdm.html, accessed: 2025-03-14.