Pith. sign in

REVIEW 3 major objections 4 minor 45 references

Unveiling the Energy Vampires: A Methodology for Debugging Software Energy Consumption

T0 review · 3 major / 4 minor · reviewed 2026-08-11 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read The paper claims that a four-step energy debugging methodology, demonstrated on Redis, traces Alpine's up to 20.2% higher power consumption to the musl memcpy implementation for small 4-byte copies.

desk verdict The log-alignment debugging methodology is a real contribution, but the paper's claim that musl's memcpy is the cause of Redis's energy gap is undercut by the isolation microbenchmark. read the letter →

arxiv 2412.10063 v1 pith:JPBMKDOP submitted 2024-12-13 cs.SE

Enrique Barba Roque , Luis Cruz , Thomas Durieux This is my paper · ORCID
classification cs.SE
keywords energydebuggingsoftwareconsumptionRedismuslglibcmemcpyAlpineLinuxpowermeasurement
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper offers a four-step methodology for finding why one version of a server program consumes more energy than another, and uses it to explain why Redis on Alpine Linux uses up to 20.2% more power than on Ubuntu during LRANGE operations. It claims the discrepancy comes from the memcpy implementation in Alpine's C library (musl) rather than Redis version, allocator, or compiler. The evidence combines function tracing, log-based checkpoint alignment, and microbenchmarks that mimic Redis's small 4-byte copy pattern. If true, energy debugging can be done systematically, and library-level choices matter for energy even when runtime performance says otherwise.

What carries the argument

The load-bearing mechanism is the combination of function tracing with energy measurements synchronized through checkpoint alignment: benchmark log lines are cleaned, unique lines are selected as checkpoints, and the region between checkpoints is treated as logically equivalent across traced and energy-measured runs, allowing per-region histograms of function runtime to be overlaid on the power curve. The named suspect that carries the argument is memcpy, specifically its behavior for sub-8-byte copies from cache to memory, where alignment constraints make the copy more expensive.

What would settle it

Run the same Redis workload with tracing at the full 1,000,000-iteration scale and check whether memcpy still dominates the LRANGE regions; alternatively, swap the libc implementations so Alpine runs glibc's memcpy while everything else stays the same. If the 20.2% power gap survives the swap, or disappears without it, the memcpy attribution is wrong.

Watch

Extended reading notes

Core claim

The central claim is that the energy overhead of Redis on Alpine versus Ubuntu is caused by musl's memcpy implementation for small, 4-byte copies. The authors establish this by controlling all variables: same Redis version, same allocator, glibc introduced into Alpine, and by running a microbenchmark that mimics Redis's LRANGE pattern of copying 'VKX,' strings one by one. In that cache-to-memory benchmark, Alpine uses about 1.1W more power (15.8%) and takes almost three times as long, confirming that musl's plain-C memcpy is less energy-efficient than glibc's assembly-optimized version for this access pattern.

Load-bearing premise

The attribution depends on the scaled-down tracing run having the same mix of function calls as the energy-measured runs, and on the log checkpoints dividing both streams into equivalent phases.

Editorial extensions

If this is right

  • Redis on Alpine with musl will use roughly 8.6% more total energy than on Ubuntu with glibc, and up to 20.2% more power during LRANGE-heavy regions, when Redis version, allocator, and compiler are held fixed.
  • The energy gap is a property of the libc memcpy implementation, not of Redis itself, so any server workload that makes many small copies could see a similar gap.
  • Runtime performance is not a reliable proxy for energy performance: in the cache-to-memory microbenchmark, Alpine is both slower and more power-hungry, so energy regression tests need direct power measurements.
  • The methodology can be applied without internal knowledge of the target software, which suggests it can generalize to other systems whose logs contain stable checkpoints.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If these results hold, the log-alignment technique should transfer to other runtimes and services whose logs contain stable, unique markers; PostgreSQL is the paper's own partial example, with write identified as the suspect.
  • A natural extension is to test whether other musl string routines (memmove, memset, strcpy) show the same sub-word energy overhead, since they share the same alignment constraints.
  • Large-scale data-center operators could translate the per-instance power gap into fleet-level cost estimates once the workload mix includes many small-record serialization paths, though the paper itself does not do this.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 4 minor

Summary. The paper proposes a four-step methodology for debugging software energy consumption: energy measurement, function tracing, log-based alignment of trace and energy data, and hotspot pinpointing. The methodology is demonstrated on Redis running in Alpine (musl libc) versus Ubuntu (glibc). The authors report an 8.6% total energy difference and up to 20.2% higher power in specific Redis operations, identify musl's memcpy as the main suspect, and attempt to confirm this with microbenchmarks. The paper also includes a partial PostgreSQL analysis and provides a replication package.

Significance. A systematic, repeatable methodology for localizing energy regressions is a useful contribution, especially given the openness of the replication scripts and the controlled experimental design that isolates libc by comparing alpinejem and ubuntu with fixed Redis version and allocator. If the central causal claim about memcpy were established, the finding would be of practical interest to containerized deployments. However, the load-bearing confirmation experiment has a representativeness problem: the microbenchmark that reproduces the musl penalty does not match Redis's actual data-flow pattern, and the variant that does match shows the opposite effect. This substantially weakens the paper's main conclusion.

major comments (3)
  1. [§IV-D, Table V, Figures 10 and 11] The microbenchmark intended to confirm memcpy as the cause of the Redis energy gap does not, in fact, confirm it. The paper states that Redis's LRANGE copies elements from the in-memory database to a response buffer, which is a memory-to-memory memcpy with runtime source and destination pointers. In the memory-to-memory variant (Figure 10, Table V), Alpine consumes slightly less total energy than Ubuntu (1065.34 J vs. 1075.88 J), the opposite of the Redis result. Only the cache-to-memory variant (Figure 11, Table V), where the source is a compile-time constant ('VKX,'), shows the musl penalty (2977.45 J vs. 972.76 J). The paper attributes this difference to 'the information known by the compiler,' but that is precisely the property that separates the benchmark from the real workload. As presented, the evidence supports the conclusion that the effect depends on compiler-known constants, not that it appears in Redis's actual memcpy usage; the cache-to-memory configuration appears to be selected post hoc because it matches the desired outcome.
  2. [§IV-B, Table II, Figure 6] The headline quantitative claims of 8.6% total energy difference and up to 20.2% power difference are presented without confidence intervals, error bars, or significance tests. The paper acknowledges measurement variability and uses 30 runs, yet the conclusions rely on point estimates alone. Given that the experimental protocol is designed to reduce noise, the authors should report the dispersion of the measurements (e.g., 95% confidence intervals for the differences) and, if appropriate, a statistical test comparing alpinejem and ubuntu to support the claim that the difference is not an artifact of random variation.
  3. [§III-D and §IV-C] The suspect identification in RQ2 rests on a single uftrace trace scaled down from 1,000,000 to 10,000 benchmark iterations, combined with log alignment that assumes the relative distribution of function calls is identical between traced and untraced executions. The paper acknowledges that tracing overhead is nonuniform, but it does not test whether the 100x scale-down changes which functions dominate (e.g., by inflating fixed-cost functions such as epoll_wait or write relative to steady-state work). Since the memcpy attribution in Figure 8 is the starting point for RQ3, the robustness of the trace summary to iteration count and tracing overhead should be demonstrated, for example by comparing traces at 10,000, 100,000, and 1,000,000 iterations or by using a second independent tracing method.
minor comments (4)
  1. [§VIII, Conclusion] The conclusion states 'a 13% difference in a custom benchmark,' but Section IV-D and Table V report a 15.8% power difference in the cache-to-memory experiment; these numbers should be reconciled.
  2. [§IV-A.1] The text says 'Redis does not have dependencies,' which is imprecise: Redis depends on libc and other system libraries. The intended meaning seems to be that Redis has no third-party application-level dependencies beyond libc, but the sentence should be rephrased to avoid overstatement.
  3. [§III-B] The phrase 'The median energy consumption is the area under the line' should read 'median power consumption' (or 'total energy'), since the figure shows power over time and energy is the integral of power.
  4. [§IV-C, Figure 8] The description of the log-alignment checkpoints for Redis would benefit from an explicit example of a checkpoint line in the Redis log (similar to the PostgreSQL example in Figure 4), to make the alignment procedure reproducible for readers wanting to reapply the methodology.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the derivation chain is empirical and self-contained; the RQ3 microbenchmark concern is a validity threat, not a circular reduction.

full rationale

The paper's claimed derivation chain is empirical rather than formal: measure energy (RQ1), trace to identify memcpy as a suspect (RQ2), and isolate memcpy in microbenchmarks (RQ3). No equation is reused as its own conclusion, no fitted parameter is renamed as a prediction, and no result depends on a load-bearing self-citation. The self-cited EnergiBridge tool [26] is a measurement utility whose removal would change the measurement instrument but not circularly force the conclusion. The checkpoint alignment method states an assumption that call distributions between checkpoints are equivalent across traced and untraced runs; that is a stated threat to validity, not a circular definition. The strongest concern is that RQ3's confirming result appears only in the 'cache to memory' variant (Table V: alpine 2977.45 J vs ubuntu 972.76 J), while the 'memory to memory' variant, which more closely matches Redis's LRANGE copies from an in-memory source buffer, shows the opposite (alpine 1065.34 J vs ubuntu 1075.88 J). The paper reports both results and interprets the cache-to-memory variant as the relevant one because of compiler-known information. That is a post-hoc interpretive choice and a serious external-validity threat, but it is not circular: the microbenchmark is not derived from the energy result by construction, and the paper does not hide the contradictory data. Disagreement with the interpretation belongs under correctness or validity risk, not circularity.

Assumptions & free parameters 1 free parameters · 5 assumptions · 0 invented entities

No new physical entities or fitted model parameters. The central claim rests on domain assumptions about measurement fidelity, tracing representativeness, log-alignment validity, and CPU-only energy attribution; the only hand-chosen numbers are the microbenchmark parameters selected to mimic the Redis workload.

free parameters (1)
  • Microbenchmark configuration for cache-to-memory memcpy test = 4-byte elements, 3000-byte buffer, 40,000,000 repetitions
    Chosen by hand to mimic Redis LRANGE behavior with small copies; this configuration is the one that reproduces the energy gap, while other configurations (12 GB, memory-to-memory) do not.
assumptions (5)
  • domain assumption RAPL/EnergiBridge CPU energy readings on the AMD Ryzen 9 7900X accurately reflect the energy consumption attributable to the isolated core.
    Used in all energy measurements (Section IV-A2/IV-A3); if the readings are biased, the 8.6% and 20.2% comparisons are invalid.
  • domain assumption The uftrace tracing run, performed once per version at 10,000 iterations, preserves the relative function call distribution of the 1,000,000-iteration energy runs despite nonuniform tracing overhead.
    Section III-C and IV-C rely on this to identify memcpy as the hotspot; the paper itself notes tracing changes execution time nonuniformly.
  • domain assumption Checkpoint-based log alignment treats regions between checkpoints as equivalent across energy and tracing runs, so function histograms can be superimposed on power traces.
    Section III-D; if checkpoint regions do not correspond to the same workload phases, Figure 8's memcpy attribution is unsupported.
  • domain assumption Docker containerization introduces negligible and constant energy overhead relative to bare metal for these workloads.
    Section V-C asserts this based on Santos et al.; if false, the OS comparison is confounded by container overhead.
  • domain assumption The workload is CPU-bound enough that CPU power is a representative proxy for total energy differences.
    Section VI-C acknowledges CPU-only measurement; memcpy is CPU-bound, but network/I/O could affect total energy.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Unveiling the Energy Vampires: A Methodology for Debugging Software Energy Consumption." pith.science (2026). https://pith.science/paper/JPBMKDOP

@misc{pith2026241210063,
  author       = {Pith},
  title        = {Pith review of: Unveiling the Energy Vampires: A Methodology for Debugging Software Energy Consumption},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/JPBMKDOP}},
  note         = {Machine review of arXiv:2412.10063}
}
read the original abstract

Energy consumption in software systems is becoming increasingly important, especially in large-scale deployments. However, debugging energy-related issues remains challenging due to the lack of specialized tools. This paper presents an energy debugging methodology for identifying and isolating energy consumption hotspots in software systems. We demonstrate the methodology's effectiveness through a case study of Redis, a popular in-memory database. Our analysis reveals significant energy consumption differences between Alpine and Ubuntu distributions, with Alpine consuming up to 20.2% more power in certain operations. We trace this difference to the implementation of the memcpy function in different C standard libraries (musl vs. glibc). By isolating and benchmarking memcpy, we confirm it as the primary cause of the energy discrepancy. Our findings highlight the importance of considering energy efficiency in software dependencies and demonstrate the capability to assist developers in identifying and addressing energy-related issues. This work contributes to the growing field of sustainable software engineering by providing a systematic approach to energy debugging and using it to unveil unexpected energy behaviors in Alpine.

Figures

Figures reproduced from arXiv: 2412.10063 by the authors.

Figure 1
Figure 1. Visual representation of the energy debugging method [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Energy Consumption of PostgreSQL on Alpine vs. [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. uftrace report of top used functions [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (4 more)
Figure 6
Figure 6. Figure 6: Energy consumption of Redis for the different configu [PITH_FULL_IMAGE:figures/full_fig_p006_6.png]
Figure 8
Figure 8. Figure 8: Power usage of Redis for Ubuntu and Alpine and [PITH_FULL_IMAGE:figures/full_fig_p007_8.png]
Figure 10
Figure 10. Figure 10: Power usage against time of the memcpy benchmark from memory to memory. TABLE V: Average completion time and energy consumption for the memcpy benchmark from memory to memory and cache to memory Image Memory to Memory Cache to Memory Time (s) Energy (J) Time (s) Energ…
Figure 11
Figure 11. Figure 11: Power usage against of the memcpy benchmark from cached to memory. These benchmarks show that the behavior of memcpy can vary wildly depending on what information is available in compile time. We also notice how some of the benchmarks move in different power usage ran…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

45 extracted references · 37 canonical work pages

  1. [1]

    Suparna Bhattacharya, Kanchi Gopinath, Karthick Ra- jamani, and Manish Gupta. 2011. Software bloat and wasted joules: Is modularity a hurdle to green software? Computer 44, 09 (2011), 97–101

    work page 2011

  2. [2]

    Bryant and David R

    Randal E. Bryant and David R. O’Hallaron. 2015. Com- puter Systems: A Programmer’s Perspective (3rd ed.). Pearson

    work page 2015

  3. [3]

    Rajkumar Buyya, Shashikant Ilager, and Patricia Arroba

    work page

  4. [4]

    Luís Cruz. 2021. Green Software Engineering Done Right: a Scientific Guide to Set Up Energy Effi- ciency Experiments . http://luiscruz.github.io/2021/10/ 10/scientific-guide.html

    work page 2021

  5. [5]

    Luis Cruz and Rui Abreu. 2017. Performance-Based Guidelines for Energy Efficient Mobile Applications. In 2017 IEEE/ACM 4th International Conference on Mobile Software Engineering and Systems (MOBILESoft) . 46–57. https://doi.org/10.1109/MOBILESoft.2017.19

    work page doi:10.1109/mobilesoft.2017.19 2017

  6. [6]

    Luis Cruz and Rui Abreu. 2019. Catalog of Energy Patterns for Mobile Applications. CoRR abs/1901.03302 (2019). arXiv:1901.03302 http://arxiv.org/abs/1901.03302

    work page Pith review arXiv 2019

  7. [7]

    Luis Cruz, Rui Abreu, John Grundy, Li Li, and Xin Xia. 2019. Do Energy-Oriented Changes Hinder Main- tainability?. In 2019 IEEE International Conference on Software Maintenance and Evolution (ICSME) . 29–40. https://doi.org/10.1109/ICSME.2019.00013

    arXiv 2019

  8. [8]

    Benedikt Dornauer and Michael Felderer. 2023. Energy- saving strategies for mobile web apps and their mea- surement: Results from a decade of research. In 2023 IEEE/ACM 10th International Conference on Mobile Software Engineering and Systems (MOBILESoft) . IEEE, 75–86

    work page 2023

Show all 45 references
  1. [9]

    T. Durieux. 2024. Empirical Study of the Docker Smells Impact on the Image Size. In 2024 IEEE/ACM 46th International Conference on Software Engineering (ICSE). IEEE Computer Society, Los Alamitos, CA, USA, 2568– 2579

    2024

  2. [10]

    Lieven Eeckhout. 2017. Is moore’s law slowing down? what’s next? IEEE Micro 37, 04 (2017), 4–5

    2017

  3. [11]

    glibc team. 2024. memcpy code from glibc. https: //github.com/lattera/glibc/blob/master/string/memcpy.c

    2024

  4. [12]

    Nurminen, and Zhonghong Ou

    Kashif Nizam Khan, Mikael Hirki, Tapio Niemi, Jukka K. Nurminen, and Zhonghong Ou. 2018. RAPL in Action: Experiences in Using RAPL for Power Measurements. ACM Trans. Model. Perform. Eval. Comput. Syst. 3, 2, Article 9 (mar 2018), 26 pages. https://doi.org/10.1145/ 3177754

    2018

  5. [13]

    Namhyung Kim. 2023. uftrace. https://github.com/ namhyung/uftrace

    2023

  6. [14]

    Colin Ian King. 2023. Powerstat. https://github.com/ ColinIanKing/powerstat

    2023

  7. [15]

    Roberto Morabito. 2015. Power Consumption of Vir- tualization Technologies: An Empirical Investigation. In 2015 IEEE/ACM 8th International Conference on Utility and Cloud Computing (UCC) . 522–527. https: //doi.org/10.1109/UCC.2015.93

    2015 doi

  8. [16]

    musl. [n. d.]. musl homepage. https://musl.libc.org/

  9. [17]

    musl team. 2024. memcpy code from musl. https: //github.com/esmil/musl/blob/master/src/string/memcpy.c

    2024

  10. [18]

    Adel Noureddine, Romain Rouvoy, and Lionel Seinturier

  11. [19]

    James Pallister, Simon J Hollis, and Jeremy Bennett

  12. [20]

    Rui Pereira, Marco Couto, Francisco Ribeiro, Rui Rua, Jácome Cunha, João Paulo Fernandes, and João Saraiva

  13. [21]

    Redis. 2022. Redis Docker image. https://hub.docker. com/_/redis

    2022

  14. [22]

    Redis. 2024. LRANGE Docs. https://redis.io/docs/latest/ commands/lrange

    2024

  15. [23]

    Redis. 2024. Redis Benchmark Docs. https://redis.io/docs/latest/operate/oss_and_stack/ management/optimization/benchmarks/

    2024

  16. [24]

    Luigi Rodorigo. 2020. Memcpy Bench- mark. https://gist.github.com/lrodorigo/ 280bd4db453210cee6e1610648d937a9

    2020

  17. [25]

    Giovanni Rosa, Simone Scalabrino, and Rocco Oliveto

  18. [26]

    June Sallou, Luís Cruz, and Thomas Durieux. 2023. EnergiBridge: Empowering Software Sustainability through Cross-Platform Energy Measurement. arXiv:2312.13897 [cs.SE]

    2023 arXiv

  19. [27]

    Eddie Antonio Santos, Carson McLean, Christopher Solinas, and Abram Hindle. 2018. How does Docker affect energy consumption? Evaluating workloads in and out of Docker containers. Journal of Systems and Software 146 (2018), 14–25

    2018

  20. [28]

    Robert Schone, Thomas Ilsche, Mario Bielert, Markus Velten, Markus Schmidl, and Daniel Hackenberg. 2021. Energy Efficiency Aspects of the AMD Zen 2 Architec- ture. In 2021 IEEE International Conference on Cluster Computing (CLUSTER). IEEE. https://doi.org/10.1109/ cluster48925...

    2021

  21. [29]

    Simon Schubert, Dejan Kostic, Willy Zwaenepoel, and Kang G. Shin. 2012. Profiling Software for Energy Consumption. In 2012 IEEE International Conference on Green Computing and Communications . 515–522. https://doi.org/10.1109/GreenCom.2012.86

    2012 doi

  22. [30]

    Senay Semu Tadesse, Carla Fabiana Chiasserini, and Francesco Malandrino. 2018. Characterizing the power cost of virtualization environments. Transactions on Emerging Telecommunications Technologies 29, 8 (2018), e3462

    2018

  23. [31]

    Bailey Tjiong. 2023. The impact of base image selection on the energy efficiency of containerized applications in Docker. Available at http://resolver.tudelft.nl/uuid: 1166da2a-a62d-4b53-baa3-08e6e107053b

    2023

  24. [32]

    Linus Torvalds. [n. d.]. glibc mailing list: Wish for

  25. [33]

    Turner-Trauring

    I. Turner-Trauring. 2023. Using Alpine can make Python Docker builds 50 × slower. https://pythonspeed.com/ articles/alpine-docker-python

    2023

  26. [34]

    Arjan van de Ven. 2022. PowerTOP. https://github.com/ fenrus75/powertop

    2022

  27. [35]

    Perf Wiki. 2021. perf: Linux profiling with performance counters. https://perf.wiki.kernel.org/index.php/Main_ Page

    2021

  28. [36]

    Guoqing Xu, Nick Mitchell, Matthew Arnold, Atanas Rountev, and Gary Sevitsky. 2010. Software bloat analysis: finding, removing, and preventing performance problems in modern large-scale object-oriented applications. In Proceedings of the FSE/SDP Workshop on Future of Software ...

    2010

  29. [37]

    Joseph Zambreno, Mahmut Taylan Kandemir, and Alok Choudhary. 2002. Enhancing compiler techniques for memory energy optimizations. In Embedded Software: Second International Conference, EMSOFT 2002 Greno- ble, France, October 7–9, 2002 Proceedings 2 . Springer, 364–381

    2002

  30. [38]

    Yang Zhang, Gang Yin, Tao Wang, Yue Yu, and Huaimin Wang. 2018. An Insight Into the Impact of Dockerfile Evolutionary Trajectories on Quality and Latency. In 2018 IEEE 42nd Annual Computer Software and Applications Conference (COMPSAC), V ol. 01. 138–143. https://doi. org/10.1...

    2018

  31. [39]

    Yinyuan Zhang, Yang Zhang, Xinjun Mao, Yiwen Wu, Bo Lin, and Shangwen Wang. 2022. Recommending base image for docker containers based on deep configuration comprehension. In 2022 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER). IEEE, 449–453

    2022

  32. [2002]

    http://ecos.sourceware.org/ml/libc-alpha/2002-01/ msg00079.html

    2002

  33. [2014]

    In Proceedings of the 29th Annual ACM Sym- posium on Applied Computing (Gyeongju, Republic of Korea) (SAC ’14)

    Unit testing of energy consumption of software libraries. In Proceedings of the 29th Annual ACM Sym- posium on Applied Computing (Gyeongju, Republic of Korea) (SAC ’14). Association for Computing Machinery, New York, NY , USA, 1200–1205. https://doi.org/10. 1145/2554850.2554932

  34. [2015]

    Identifying compiler options to minimize energy consumption for embedded platforms. Comput. J. 58, 1 (2015), 95–109

    2015

  35. [2021]

    Science of Computer Programming 205 (2021), 102609

    Ranking programming languages by energy efficiency. Science of Computer Programming 205 (2021), 102609. https://doi.org/10.1016/j.scico.2021.102609

    2021

  36. [2022]

    In 2022 IEEE International Conference on Software Maintenance and Evolution (ICSME)

    Assessing and Improving the Quality of Docker Artifacts. In 2022 IEEE International Conference on Software Maintenance and Evolution (ICSME) . 592–596. https://doi.org/10.1109/ICSME55016.2022.00081

    2022

  37. [2024]

    Software: Practice and Experience 54, 1 (2024), 24–38

    Energy-efficiency and sustainability in new gen- eration cloud computing: A vision and directions for integrated management of data centre resources and workloads. Software: Practice and Experience 54, 1 (2024), 24–38

    2024

Pith tools

Reviewed August 11, 2026 · model on record in the stance chip above.