EMLIO: Minimizing I/O Latency and Energy Consumption for Large-Scale AI Training

Hasibul Jamil; MD S Q Zulkar Nine; Tevfik Kosar

REVIEW 4 major objections 5 minor 54 references

EMLIO: Minimizing I/O Latency and Energy Consumption for Large-Scale AI Training

T0 review · 4 major / 5 minor · reviewed 2026-08-15 · deepseek-v4-flash

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

Pith's one-line read This paper proposes EMLIO, a service-based I/O design that keeps data-loading latency and energy nearly constant across network distances by moving batch preparation into a storage-side daemon.

desk verdict EMLIO's RTT-immune data-loading design is credible and clearly evaluated, but the headline I/O-energy claim is total-epoch energy mislabeled as I/O energy, and the paper needs honest re-framing before its energy title is earned. read the letter →

arxiv 2508.11035 v1 pith:P26IKHH5 submitted 2025-08-14 cs.DC

Hasibul Jamil , MD S Q Zulkar Nine , Tevfik Kosar This is my paper · ORCID

classification cs.DC

keywords I/OlatencyenergyefficiencydeeplearningdataloadingdistributedstorageGPU-acceleratedpreprocessingTFRecordout-of-orderprefetching

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

This paper argues that the I/O stage of distributed AI training can be made nearly insensitive to network distance if the storage side, not the training process, does the batching and serialization. EMLIO places a lightweight daemon on storage servers that reads raw samples, packs them into pre-sized batches, and streams those batches over parallel TCP channels, while a client-side receiver feeds them into GPU-accelerated preprocessing. Across local disk, LAN, and WAN conditions, the authors report per-epoch time and I/O energy varying by less than five percent from 0.1 ms to 30 ms round-trip time, and up to 8.6x faster I/O and 10.9x lower energy than existing loaders. The reason to care is that geo-distributed and cloud training currently idle GPUs and waste energy waiting on remote reads; if this holds, distance stops being the dominant cost.

What carries the argument

The load-bearing mechanism is the storage-side EMLIO Daemon, which memory-maps large TFRecord shards, serializes fixed-size batches into msgpack payloads, and pushes them over multiple ZeroMQ/TCP streams with high-water-mark backpressure; the compute side runs an EMLIO Receiver that deserializes into a shared queue and feeds DALI's external_source, so GPU decoding and augmentation overlap with network transfer. Out-of-order prefetching across parallel send threads lets the pipeline exploit storage and network parallelism. The secondary machinery is the distributed EnergyMonitor: barrier-synchronized CPU/DRAM and GPU samplers at 100 ms intervals write NTP-aligned energy tuples to a time-series database, letting the authors attribute energy per epoch.

What would settle it

A single test at 1 Gbps with the same 10 GB ImageNet subset would settle it: if per-epoch time grows with RTT or exceeds the local-disk epoch by more than five percent, the claim that latency alone is masked fails.

Watch

Extended reading notes

Core claim

The central discovery is that a service-based I/O design, an EMLIO Daemon co-located with storage that memory-maps TFRecord shards, serializes groups of samples into msgpack batches, and pushes them over ZeroMQ/TCP streams with backpressure, can hide round-trip latency almost entirely. A synchronized energy monitor built from perf and NVML sampling shows the energy footprint stays flat as network distance grows. In evaluation, EMLIO's ImageNet epoch time stays near 156 s across 0.1 ms, 10 ms, and 30 ms RTT, where the standard PyTorch loader and DALI slow by 3x to 27x and consume 4x to 60x more energy. The same pattern holds for COCO and for VGG-19, and in a sharded local-plus-remote setup EMLIO reduces epoch time by up to 18.7x at 30 ms RTT. To the authors' knowledge, this is the first end-to-end measurement of I/O energy during model training and the first loader designed to minimize both latency and energy.

Load-bearing premise

The result assumes the network pipe is wide enough to carry pre-batched data faster than the GPU consumes it; only round-trip latency is varied, so the claim is not established when bandwidth is the binding constraint.

Editorial extensions

If this is right

If the central claim is right, geo-distributed AI training can place datasets on cheap remote storage without paying an epoch-time or energy penalty, as long as bandwidth is not the binding constraint.
Energy-aware provisioning becomes possible: because I/O energy is roughly constant across RTT, data-movement energy can be treated as a fixed per-epoch cost rather than a distance-dependent one.
A horizontal scaling path follows from the design: adding storage nodes with their own daemons increases aggregate throughput linearly, so the mechanism transfers to multi-node dataset sharding.
The pipeline should keep paying off as accelerators get faster, because the bottleneck is shifted from remote read latency to pre-batching and streaming concurrency on the storage side.
Wall-clock convergence improves at high latency: the paper shows ResNet-50 loss reaching the same level in about 1,000 s under 10 ms RTT where DALI takes 7,500 s.

Reading between the lines

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

The RTT-agnostic result is demonstrated only where bandwidth (10 Gbps) exceeds GPU consumption; a natural extension is to test at 1 Gbps or with larger samples, where the daemon's serialization and stream count, not latency, should become the bottleneck.
Because EMLIO amortizes per-batch setup across many samples, the optimal batch size and daemon concurrency likely need to grow with record size; the paper shows concurrency 2 recovering the lead for 2 MB records, implying a tunable knob for other record distributions.
A testable extension, which the authors themselves flag, is to combine EMLIO with gradient-synchronization scheduling so that data arrival and collective communication are co-optimized rather than treated as separate stages.
If the energy numbers are validated by independent measurement, the same synchronized-sampling methodology could become a standard energy benchmark for data loaders, not just for EMLIO.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Desk Editor's Note

read the letter

Colleague,

Short version: EMLIO's latency results are worth knowing; its energy claims, as written, do not survive contact with the measurements. The paper deserves a serious referee, but with a demand to re-frame the energy story.

What is actually new: EMLIO offloads batch construction to the storage side—mmap TFRecord shards, serialize fixed-size batches, push over parallel ZeroMQ streams with out-of-order prefetching and backpressure, then hand msgpack payloads to DALI's external_source on the compute node. The pieces are known (NoPFS-style prefetching, TFRecord sharding, DALI integration), but the storage-side pre-batching daemon and the explicit time-plus-energy objective are a fair synthesis. The evaluation is the strong part: three datasets, two models, four RTT regimes, and the central result is credible—EMLIO's epoch time stays near 156 s from local disk out to 30 ms RTT, while DALI and PyTorch degrade to 1.7–4.2k s. On a single GPU node with 10 Gbps, network distance becomes invisible. That is a useful result.

Soft spots, in order of size. The I/O-energy claim is an attribution error. EnergyMonitor measures total CPU/DRAM/GPU energy over the whole epoch (Algorithm 1, Figures 5–10), and Figure 1's caption admits the numbers "contain the ideal energy"—no idle baseline is subtracted. EMLIO's flat ~36 kJ per epoch is its flat ~156 s epoch restated in joules. The sentence "I/O-related energy remains minimal" (Section 5.1.1) never isolates the Read+Preprocess stage, and the abstract's 10.9x reduction is a ratio of total epoch energies against runs that take 11–27x longer. That may be a real energy-bill saving, but it is not demonstrated I/O-energy minimization. The fix is inside the paper: Figure 1 shows they can segment stages, so a pre-staged local baseline plus stage-level subtraction would support or retire the claim.

Second, the paper's own Scenario 2 undercuts the constant-energy story: with half-local/half-remote shards, EMLIO's runtime holds at ~222 s across RTTs while CPU energy climbs from 19.7 to 52.5 to 106 kJ. That is not an energy profile that stays constant, and it suggests the energy measurements are noisier than the text admits. Smaller nits: abstract says 8.6x/10.9x while the conclusion says 13x/8x; Section 5.3's 7500 s DALI COCO epoch is out of line with Figure 6's ~1.3k s; no error bars on the main comparisons; no code or data released; and "linear horizontal scalability" is asserted but never tested—Scenario 2 is one node, not a cluster.

Who this is for: anyone building data loaders for geo-distributed training will want the RTT-masking design; the energy section is a good referee exercise in measurement honesty. I would send it to peer review and lean on revision for the energy attribution.

Referee Report

4 major / 5 minor

Summary. The manuscript presents EMLIO, a storage-side data-serving daemon that pre-batches and serializes TFRecord samples, streams them over ZeroMQ/TCP with out-of-order prefetching, and feeds them into a DALI pipeline on compute nodes. The central claims are (i) near-constant per-epoch duration and energy as network RTT grows from 0.1 ms to 30 ms, and (ii) up to 8.6x faster I/O and 10.9x lower energy compared with PyTorch DataLoader and NVIDIA DALI. Evaluation covers ResNet-50 and VGG-19 on ImageNet, COCO, and synthetic 2 MB records in Chameleon cloud, across local, LAN, emulated-LAN, and WAN regimes, with a custom synchronized perf/NVML energy monitor. The latency-hiding results are plausible; the energy-attribution claims are the main weakness.

Significance. If the latency claims hold, EMLIO is a useful contribution to remote and geo-distributed training I/O: the architecture is clean, the results are reported consistently across datasets and models, and the barrier-aligned CPU/DRAM/GPU sampling harness with NTP-synchronized timestamps is a reasonable measurement infrastructure. However, the paper's stated novelty is joint latency and I/O-energy minimization, and the energy pillar currently rests on total-epoch energy measurements with no baseline subtraction or stage-level segmentation. The paper also lacks error bars for its headline comparisons and does not test the bandwidth-constrained regime, so the RTT-invariance claim is only established under abundant bandwidth.

major comments (4)

[§5.1.1, Fig. 5; Fig. 1 caption] The claim that 'I/O-related energy remains minimal' is not supported by the reported measurements. Figures 5–10 report total per-epoch CPU/DRAM/GPU energy over the entire training epoch, and the Figure 1 caption explicitly states that all reported energies 'also contain the ideal energy.' EMLIO's near-constant energy at 30 ms RTT (about 36 kJ) therefore simply tracks its near-constant runtime (about 156 s), while DALI and PyTorch consume more total energy because their epochs run 3.5–27x longer. No baseline with data pre-staged on the compute node is reported, and no stage-level segmentation is applied in Figures 5–10 even though Figure 1 demonstrates the ability to segment Read, Read+Preprocess, and Train stages. Consequently, the abstract's 10.9x lower-energy claim is a ratio of total epoch energies, not a reduction in I/O energy per byte, per I/O operation, or per Read+Preprocess stage. The authors should either (a) report energy per stage with the ideal training energy subtracted, or (b) explicitly reframe all energy claims as end-to-end epoch energy and remove the I/O-energy attribution.
[Abstract vs. §6] The headline numbers are internally inconsistent. The abstract states 'up to 8.6X faster I/O and 10.9X lower energy use,' while the conclusion states EMLIO 'cuts I/O energy by up to 8× and speeds up epochs by up to 13×' over the same baselines. Figure 5 at 30 ms RTT shows EMLIO is about 10.9x faster than DALI and about 27x faster than PyTorch, and the energy ratios there are also different from both the abstract and the conclusion. The paper should state exactly which configuration (dataset, model, RTT, baseline) produces each headline number, and the abstract and conclusion should be reconciled.
[§4.1, §5.1.1] The RTT-invariance result is established only in a bandwidth-abundant regime. All experiments use a 10 Gbps link with a 10 GB dataset on a single GPU node; the required data rate is roughly 10 GB / 156 s ≈ 64 MB/s, far below the 10 Gbps link capacity. In this regime, latency hiding via prefetching and multi-streaming is expected to work, and the result does not test the case where bandwidth, not round-trip time, is the binding constraint. The claim that EMLIO 'fully masks network delays' should be tested with a higher per-GPU data rate (e.g., larger datasets, multiple concurrent GPUs, or a lower-bandwidth link) to show that the constant-duration result is not an artifact of underutilized network capacity.
[Figs. 5–10] No error bars, confidence intervals, or run counts are reported for the central energy and duration comparisons. Figure 11 shows measurable run-to-run variability (±1 standard deviation over three runs), which suggests the headline comparisons in Figures 5–10 should include at least mean and standard deviation over multiple runs. Without this, the quantitative claims (e.g., 'less than 5% variation' in epoch time) cannot be distinguished from noise.

minor comments (5)

[Keywords] The keyword 'energy-efficency' is misspelled; it should be 'energy-efficiency.'
[Fig. 1 caption] The caption refers to 'Section III,' but the paper uses numeric section numbering; it should refer to 'Section 3.'
[Algorithm 1 explanation] The text says 'Initialize NVML, TMDS client'; 'TMDS' appears to be a typo and should likely read 'TSDB/InfluxDB client.'
[Algorithm 1, line 11] The GPU energy formula contains a corrupted summation symbol (shown as '˝') and should be typeset as ∑ᵢ Pᵢ · δ / 1000.
[Fig. 8] The two panels of Figure 8 use different y-axis scales (0.1 ms and 1 ms), which makes visual comparison difficult; consider adding shared or annotated scales.

Circularity Check

0 steps flagged · score 1.0 of 10

No significant circularity; EMLIO's claims are empirical benchmark results, with only a non-load-bearing self-citation.

full rationale

No circular derivation chain is present. EMLIO is an empirical systems paper: Algorithms 1-3 define measurement, planning, and dispatch mechanisms, but no result is obtained by fitting a parameter to a target quantity and then renaming it a prediction. The RTT-constant epoch-time and energy curves are benchmark measurements against external baselines (PyTorch DataLoader, NVIDIA DALI) on the Chameleon testbed, so the central latency and energy claims are not constructed from their own inputs. The only self-citation is [20] (Jamil et al.) in Related Work, which is presented as outside-ML energy-aware data transfer work and is not used to justify EMLIO's design or to define its metrics; it is therefore not load-bearing. A separate measurement-interpretation concern exists: Figures 5-10 report total per-epoch CPU/DRAM/GPU energy, and Figure 1's caption says 'All energy numbers reported also contain the ideal energy,' so the phrase 'I/O-related energy remains minimal' is an attribution rather than a directly measured I/O-only quantity. That is a correctness and validity issue, not circularity, and is not counted here.

Assumptions & free parameters 3 free parameters · 4 assumptions · 0 invented entities

The paper's central claims rest on the measurement framework and on the network environment. No free parameters are fitted to data, but the daemon concurrency is hand-tuned for large records, and the energy monitor's sampling interval is chosen without validation. No new physical entities are introduced; EMLIO and EnergyMonitor are software systems.

free parameters (3)

Daemon concurrency T = 2 threads for 2 MB synthetic samples; 1 for ImageNet/COCO
The paper reports increasing daemon concurrency from 1 to 2 to make EMLIO faster than DALI for large synthetic records (Section 5.1.1, Figures 7-8). The number is chosen by hand after observing serialization overhead, not derived.
ZMQ high-water mark (HWM) = 16
Set to 16 in Section 4.5 to provide backpressure; no sensitivity analysis is given.
Energy sampling interval = 100 ms
Chosen in Section 3 for energy monitoring; the paper argues it is 'fast enough' but provides no validation against higher-resolution measurements.

assumptions (4)

domain assumption NFSv4 is the representative remote-storage access path for comparing loaders
The evaluation mounts all remote data via NFSv4 (Section 5.1.1), so conclusions about RTT resilience are scoped to NFS-style synchronous reads.
domain assumption 10 Gbps network bandwidth is not a bottleneck; only RTT varies
The RTT-agnostic claim requires that the daemon can always saturate the link; bandwidth is fixed at 10 Gbps in all experiments (Table 1).
domain assumption perf events power/energy-pkg and power/energy-ram plus NVML readings at 100 ms granularity faithfully represent I/O energy
The energy monitor (Section 3) relies on these interfaces; the paper does not validate against wall power meters.
domain assumption Single-GPU ResNet-50 on a 10 GB ImageNet subset represents large-scale AI training I/O
Experiments use one GPU and one epoch; generalization to multi-GPU and multi-node training is asserted but not tested.

how reviews work

0 comments

Cite this review

Pith. "Pith review of EMLIO: Minimizing I/O Latency and Energy Consumption for Large-Scale AI Training." pith.science (2026). https://pith.science/paper/P26IKHH5

@misc{pith2026250811035,
  author       = {Pith},
  title        = {Pith review of: EMLIO: Minimizing I/O Latency and Energy Consumption for Large-Scale AI Training},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/P26IKHH5}},
  note         = {Machine review of arXiv:2508.11035}
}

read the original abstract

Large-scale deep learning workloads increasingly suffer from I/O bottlenecks as datasets grow beyond local storage capacities and GPU compute outpaces network and disk latencies. While recent systems optimize data-loading time, they overlook the energy cost of I/O - a critical factor at large scale. We introduce EMLIO, an Efficient Machine Learning I/O service that jointly minimizes end-to-end data-loading latency T and I/O energy consumption E across variable-latency networked storage. EMLIO deploys a lightweight data-serving daemon on storage nodes that serializes and batches raw samples, streams them over TCP with out-of-order prefetching, and integrates seamlessly with GPU-accelerated (NVIDIA DALI) preprocessing on the client side. In exhaustive evaluations over local disk, LAN (0.05 ms & 10 ms RTT), and WAN (30 ms RTT) environments, EMLIO delivers up to 8.6X faster I/O and 10.9X lower energy use compared to state-of-the-art loaders, while maintaining constant performance and energy profiles irrespective of network distance. EMLIO's service-based architecture offers a scalable blueprint for energy-aware I/O in next-generation AI clouds.

Review history (2 revisions) →

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

54 extracted references · 37 canonical work pages

[1]

[n. d.]. perf: Performance Analysis Tools. https://www.kernel.org/doc/html/latest/ admin-guide/perf.html. Accessed: 2025-07-23. EMLIO: Minimizing I/O Latency and Energy Consumption for Large-Scale AI Training SC2025 (Sustainable Supercomputing Workshop), November 2025, St. Louis, MO, USA

work page 2025
[2]

Martín Abadi, Ashish Agarwal, Paul Barham, Eugene Brevdo, Zhifeng Chen, Craig Citro, Greg S. Corrado, Andy Davis, Jeffrey Dean, Matthieu Devin, San- jay Ghemawat, Ian Goodfellow, Andrew Harp, Geoffrey Irving, Michael Isard, Yangqing Jia, Rafal Jozefowicz, Lukasz Kaiser, Manjunath Kudlur, Josh Leven- berg, Dandelion Mané, Rajat Monga, Sherry Moore, Derek M...

work page
[3]

Franklin Abodo, Robert Rittmuller, Brian Sumner, and Andrew Berthaume. 2018. Detecting Work Zones in SHRP 2 NDS Videos Using Deep Learning Based Com- puter Vision. In 17th IEEE International Conference on Machine Learning and Appli- cations (ICMLA)

work page 2018
[4]

Sami Abu-El-Haija, Nisarg Kothari, Joonseok Lee, Paul Natsev, George Toderici, Balakrishnan Varadarajan, and Sudheendra Vijayanarasimhan. 2016. YouTube-8M: A Large-Scale Video Classification Benchmark. arXiv preprint arXiv:1609.08675

arXiv 2016
[5]

Ammar Ahmad Awan, Khaled Hamidouche, Jahanzeb Maqbool Hashmi, and Dha- baleswar K Panda. 2017. S-Caffe: Co-designing MPI runtimes and Caffe for scalable deep learning on modern GPU clusters. In Proceedings of the 22nd ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming . 193–205

work page 2017
[6]

Ammar Ahmad Awan, Karthik Vadambacheri Manian, Ching-Hsiang Chu, Hari Subramoni, and Dhabaleswar K Panda. 2019. Optimized large-message broadcast for deep learning workloads: MPI, MPI + NCCL, or NCCL2? Parallel Comput. 85 (2019), 141–152

work page 2019
[7]

Tianqi Chen, Thierry Moreau, Ziheng Jiang, Lianmin Zheng, Eddie Yan, Haichen Shen, Meghan Cowan, Leyuan Wang, Yuwei Hu, Luis Ceze, Carlos Guestrin, and Arvind Krishnamurthy. 2018. TVM: An end-to-end optimization stack for deep learning. In 13th USENIX Symposium on Operating Systems Design and Implemen- tation (OSDI)

work page 2018
[8]

Sharan Chetlur, Cliff Woolley, Philippe Vandermersch, Jonathan Cohen, John Tran, Bryan Catanzaro, and Evan Shelhamer. 2014. cuDNN: Efficient primitives for deep learning. arXiv preprint arXiv:1410.0759

arXiv 2014

Show all 54 references

[9]

Steven W. D. Chien, Stefano Markidis, Chaitanya P. Sishtla, Luis Santos, Pawel Her- man, Sai Narasimhamurthy, and Erwin Laure. 2018. Characterizing Deep-Learning I/O Workloads in TensorFlow. InInternational Workshop on Parallel Data Storage & Data Intensive Scalable Computing ...

2018
[10]

Jia Deng, Wei Dong, Richard Socher, Li-Jia Li, Kai Li, and Li Fei-Fei. 2009. ImageNet: A Large-Scale Hierarchical Image Database. In Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition (CVPR)

2009
[11]

Nikoli Dryden, Roman Böhringer, Tal Ben-Nun, and Torsten Hoefler. 2021. Clair- voyant prefetching for distributed machine learning I/O. In Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis (St. Louis, Missouri) (SC ’21...

2021
[12]

Nikoli Dryden, Naoya Maruyama, Tim Moon, Tom Benson, Andy Yoo, Marc Snir, and Brian Van Essen. 2018. Aluminum: An Asynchronous, GPU-Aware Communi- cation Library Optimized for Large-Scale Training of Deep Neural Networks on HPC Systems. In Workshop on Machine Learning in HPC E...

2018
[14]

Google. 2020. XLA: Optimizing Compiler for Machine Learning. https://www. tensorflow.org/xla

2020
[15]

Priya Goyal, Piotr Dollár, Ross Girshick, Pieter Noordhuis, Lukasz Wesolowski, Aapo Kyrola, Andrew Tulloch, Yangqing Jia, and Kaiming He. 2017. Accurate, Large Minibatch SGD: Training ImageNet in 1 Hour. arXiv preprint arXiv:1706.02677

2017 arXiv
[16]

Kaiming He, Xiangyu Zhang, Shaoqing Ren, and Jian Sun. 2016. Deep Residual Learning for Image Recognition. In Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition (CVPR)

2016
[17]

InfluxData. [n. d.]. InfluxDB -Python Client Documentation. https://influxdb- python.readthedocs.io/. Accessed: 2025-07-23

2025
[18]

Andrei Ivanov, Nikoli Dryden, Tal Ben-Nun, Shigang Li, and Torsten Hoefler. 2021. Data Movement Is All You Need: A Case Study on Optimizing Transformers. In Proceedings of the Fourth Conference on Machine Learning and Systems (MLSys)

2021
[19]

Thiagaranjan, Shusen Liu, Peer-Timo Bremer, Jim Gaffney, and et al

Sam Ade Jacobs, Brian Van Essen, David Hysom, Jae -Seung Yeom, Tim Moon, Rushil Anirudh, Jayaraman J. Thiagaranjan, Shusen Liu, Peer-Timo Bremer, Jim Gaffney, and et al. 2019. Parallelizing Training of Deep Generative Models on Massive Scientific Datasets. In IEEE Internationa...

2019
[20]

Hasubil Jamil, Jacob Goldverg, Elvis Rodrigues, MD S Q Zulkar Nine, and Tevfik Kosar. 2025. Optimizing Data Transfer Performance and Energy Efficiency with Deep Reinforcement Learning. arXiv:2503.13662 [cs.DC] https://arxiv.org/abs/ 2503.13662

2025
[21]

Norman P Jouppi, Cliff Young, Nishant Patil, David Patterson, Gaurav Agrawal, Raminder Bajwa, Sarah Bates, Suresh Bhatia, Nan Boden, Al Borchers, et al. 2017. In-datacenter performance analysis of a tensor processing unit. In Proceedings of the 44th Annual International Sympos...

2017
[22]

Kate Keahey, Jason Anderson, Zhuo Zhen, and et al. 2020. Lessons Learned from the Chameleon Testbed. In Proceedings of USENIX ATC’20

2020
[23]

Thorsten Kurth, Sean Treichler, Joshua Romero, Mayur Mudigonda, Nathan Luehr, Everett Phillips, Ankur Mahesh, Michael Matheson, Jack Deslippe, Massimiliano Fatica, and et al. 2018. Exascale Deep Learning for Climate Analytics. In Inter- national Conference for High Performance...

2018
[24]

Guillaume Leclerc, Andrew Ilyas, Logan Engstrom, Sung Min Park, Hadi Salman, and Aleksander Madry. 2023. FFCV: Accelerating Training by Removing Data Bottlenecks. arXiv:2306.12517 [cs.LG] https://arxiv.org/abs/2306.12517

2023 arXiv
[25]

Lawrence Zitnick, and Piotr Dollár

Tsung-Yi Lin, Michael Maire, Serge Belongie, Lubomir Bourdev, Ross Girshick, James Hays, Pietro Perona, Deva Ramanan, C. Lawrence Zitnick, and Piotr Dollár
[26]

Jie Liu, Bogdan Nicolae, and Dong Li. 2023. Lobster: Load Balance-Aware I/O for Distributed DNN Training. In Proceedings of the 51st International Conference on Parallel Processing (Bordeaux, France) (ICPP ’22). Association for Computing Machinery, New York, NY, USA, Article 2...

2023
[27]

arXiv:1405.0312 [cs.CV] https://arxiv.org/abs/1405.0312

Microsoft COCO: Common Objects in Context. arXiv:1405.0312 [cs.CV] https://arxiv.org/abs/1405.0312

arXiv
[28]

Stefano Markidis, Steven Wei Der Chien, Erwin Laure, Ivy Bo Peng, and Jeffrey S Vetter. 2018. NVIDIA tensor core programmability, performance & precision. In 2018 IEEE International Parallel and Distributed Processing Symposium Workshops (IPDPSW)

2018
[29]

Dhruv Mahajan, Ross Girshick, Vignesh Ramanathan, Kaiming He, Manohar Paluri, Yixuan Li, Ashwin Bharambe, and Laurens van der Maaten. 2018. Exploring the Limits of Weakly Supervised Pretraining. InProceedings of the European Conference on Computer Vision (ECCV)

2018
[30]

Pennycook, and et al

Amrita Mathuriya, Deborah Bard, Peter Mendygral, Lawrence Meadows, James Arnemann, Lei Shao, Siyu He, Tuomas Kärnä, Diana Moise, Simon J. Pennycook, and et al. 2018. CosmoFlow: Using Deep Learning to Learn the Universe at Scale. In International Conference for High Performance...

2018
[31]

Eric Masanet, Arman Shehabi, Nuoa Lei, Sarah Smith, and Jonathan Koomey. 2020. Recalibrating Global Data Center Energy-Use Estimates. Science 367, 6481 (Feb. 2020), 984–986. doi:10.1126/science.aba3758

2020 doi
[32]

Murray, Jiri Simsa, Ana Klimovic, and Ihor Indyk

Derek G. Murray, Jiri Simsa, Ana Klimovic, and Ihor Indyk. 2021. tf.data: A Machine Learning Data Processing Framework. arXiv preprint arXiv:2101.12127

2021 arXiv
[33]

Jayashree Mohan and et al. 2021. Analyzing and Mitigating Data Stalls in DNN Training. Proceedings of the VLDB Endowment 14, 5 (2021), 771–784. doi:10.14778/ 3446095.3446100

2021
[34]

NVIDIA. 2020. NVIDIA Collective Communications Library (NCCL). https:// developer.nvidia.com/nccl

2020
[35]

NVIDIA. 2018. DALI: NVIDIA Data Loading Library. https://developer.nvidia.com/ dali

2018
[36]

Yosuke Oyama, Naoya Maruyama, Nikoli Dryden, Erin McCarthy, Peter Harrington, Jan Balewski, Satoshi Matsuoka, Peter Nugent, and Brian Van Essen. 2020. The Case for Strong Scaling in Deep Learning: Training Large 3D CNNs with Hybrid Parallelism. arXiv:2007.12856 [cs.DC] https:/...

2020 arXiv
[37]

NVIDIA Corporation. [n. d.]. NVIDIA Management Library (NVML). https:// developer.nvidia.com/nvidia-management-library-nvml. Accessed: 2025-07-23

2025
[38]

Adam Paszke, Sam Gross, Francisco Massa, Adam Lerer, James Bradbury, Gregory Chanan, Trevor Killeen, Zeming Lin, Natalia Gimelshein, Luca Antiga, and et al
[39]

Yosuke Oyama, Naoya Maruyama, Nikoli Dryden, Erin McCarthy, Peter Harrington, Jan Balewski, Satoshi Matsuoka, Peter Nugent, and Brian Van Essen. 2020. The Case for Strong Scaling in Deep Learning: Training Large 3D CNNs with Hybrid Parallelism. IEEE Transactions on Parallel an...

2020
[40]

David Patterson, Joseph Gonzalez, Quoc Le, Chen Liang, Lluis-Miquel Munguia, Daniel Rothchild, David So, Maud Texier, and Jeff Dean. 2021. Carbon Emissions and Large Neural Network Training. arXiv:2104.10350 [cs.LG] https://arxiv.org/ abs/2104.10350

2021 arXiv
[41]

Sarunya Pumma, Min Si, Wu-Chun Feng, and Pavan Balaji. 2019. Scalable Deep Learning via I/O Analysis and Optimization. ACM Transactions on Parallel Com- puting (TOPC) 6, 2 (2019)

2019
[42]

Rakesh Patel, Lei Zhang, and Rakshith Gupta. 2019. EcoCache: Energy-Efficient Caching via Disk Spin-Down Scheduling in Distributed Filesystems. In Proceedings of the 2019 ACM Symposium on Cloud Computing (SoCC ’19) . ACM, 45–57. doi:10. 1145/3300061.3345451

2019
[43]

Saurabhsingh Rajput, Tim Widmayer, Ziyuan Shang, Maria Kechagia, Federica Sarro, and Tushar Sharma. 2024. Enhancing Energy-Awareness in Deep Learning through Fine-Grained Energy Measurement. ACM Trans. Softw. Eng. Methodol. 33, 8, Article 211 (Dec. 2024), 34 pages. doi:10.1145/3680470

2024 doi
[44]

Alexander Sergeev and Mike Del Balso. 2018. Horovod: fast and easy distributed deep learning in TensorFlow. arXiv preprint arXiv:1802.05799. SC2025 (Sustainable Supercomputing Workshop), November 2025, St. Louis, MO, USA Jamil et al

2018 arXiv
[45]

Kun Qian and et al. 2024. Alibaba HPN: A Data Center Network for Large Language Model Training (ACM SIGCOMM ’24). Association for Computing Machinery, New York, NY, USA, 691–706. doi:10.1145/3651890.3672265

2024
[46]

Emma Strubell, Ananya Ganesh, and Andrew McCallum. 2019. Energy and Policy Considerations for Deep Learning in NLP. arXiv:1906.02243 [cs.CL] https://arxiv. org/abs/1906.02243

2019 arXiv
[47]

Chen Sun, Abhinav Shrivastava, Saurabh Singh, and Abhinav Gupta. 2017. Revisit- ing Unreasonable Effectiveness of Data in Deep Learning Era. In Proceedings of the IEEE International Conference on Computer Vision (ICCV)

2017
[48]

Karen Simonyan and Andrew Zisserman. 2015. Very Deep Convolutional Networks for Large-Scale Image Recognition. arXiv:1409.1556 [cs.CV] https://arxiv.org/abs/ 1409.1556

2015 arXiv
[49]

Francesco Versaci and Giovanni Busonera. 2025. Hiding Latencies in Network- Based Image Loading for Deep Learning. arXiv:2503.22643 [cs.DC] https://arxiv. org/abs/2503.22643

2025 arXiv
[50]

Xiaoyun Wang and Ian Goldberg. 2018. GreenTCP: Energy -Aware TCP with Dynamic Congestion Window Adaptation. In Proceedings of the 2018 USENIX Annual Technical Conference (ATC ’18) . USENIX Association, 213–225. https: //www.usenix.org/conference/atc18/presentation/wang

2018
[51]

TensorFlow Project. [n. d.]. TFRecord and tf.train.Example. https://www.tensorflow. org/tutorials/load_data/tfrecord. Accessed: 2025-07-23

2025
[52]

Yue Zhu, Fahim Chowdhury, Huansong Fu, Adam Moody, Kathryn Mohror, Kento Sato, and Weikuan Yu. 2018. Entropy-Aware I/O Pipelining for Large-Scale Deep Learning on HPC Systems. In International Symposium on Modeling, Analysis, and Simulation of Computer and Telecommunication Sy...

2018
[54]

Chih-Chieh Yang and Guojing Cong. 2019. Accelerating Data Loading in Deep Neu- ral Network Training. In International Conference on High Performance Computing, Data, and Analytics (HiPC)

2019
[2015]

https://www.tensorflow.org/

TensorFlow: Large-Scale Machine Learning on Heterogeneous Systems. https://www.tensorflow.org/
[2019]

In Advances in Neural Information Processing Systems (NeurIPS)

PyTorch: An Imperative Style, High-Performance Deep Learning Library. In Advances in Neural Information Processing Systems (NeurIPS)

Pith tools

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

[1] [1]

[n. d.]. perf: Performance Analysis Tools. https://www.kernel.org/doc/html/latest/ admin-guide/perf.html. Accessed: 2025-07-23. EMLIO: Minimizing I/O Latency and Energy Consumption for Large-Scale AI Training SC2025 (Sustainable Supercomputing Workshop), November 2025, St. Louis, MO, USA

work page 2025

[2] [2]

Martín Abadi, Ashish Agarwal, Paul Barham, Eugene Brevdo, Zhifeng Chen, Craig Citro, Greg S. Corrado, Andy Davis, Jeffrey Dean, Matthieu Devin, San- jay Ghemawat, Ian Goodfellow, Andrew Harp, Geoffrey Irving, Michael Isard, Yangqing Jia, Rafal Jozefowicz, Lukasz Kaiser, Manjunath Kudlur, Josh Leven- berg, Dandelion Mané, Rajat Monga, Sherry Moore, Derek M...

work page

[3] [3]

Franklin Abodo, Robert Rittmuller, Brian Sumner, and Andrew Berthaume. 2018. Detecting Work Zones in SHRP 2 NDS Videos Using Deep Learning Based Com- puter Vision. In 17th IEEE International Conference on Machine Learning and Appli- cations (ICMLA)

work page 2018

[4] [4]

Sami Abu-El-Haija, Nisarg Kothari, Joonseok Lee, Paul Natsev, George Toderici, Balakrishnan Varadarajan, and Sudheendra Vijayanarasimhan. 2016. YouTube-8M: A Large-Scale Video Classification Benchmark. arXiv preprint arXiv:1609.08675

arXiv 2016

[5] [5]

Ammar Ahmad Awan, Khaled Hamidouche, Jahanzeb Maqbool Hashmi, and Dha- baleswar K Panda. 2017. S-Caffe: Co-designing MPI runtimes and Caffe for scalable deep learning on modern GPU clusters. In Proceedings of the 22nd ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming . 193–205

work page 2017

[6] [6]

Ammar Ahmad Awan, Karthik Vadambacheri Manian, Ching-Hsiang Chu, Hari Subramoni, and Dhabaleswar K Panda. 2019. Optimized large-message broadcast for deep learning workloads: MPI, MPI + NCCL, or NCCL2? Parallel Comput. 85 (2019), 141–152

work page 2019

[7] [7]

Tianqi Chen, Thierry Moreau, Ziheng Jiang, Lianmin Zheng, Eddie Yan, Haichen Shen, Meghan Cowan, Leyuan Wang, Yuwei Hu, Luis Ceze, Carlos Guestrin, and Arvind Krishnamurthy. 2018. TVM: An end-to-end optimization stack for deep learning. In 13th USENIX Symposium on Operating Systems Design and Implemen- tation (OSDI)

work page 2018

[8] [8]

Sharan Chetlur, Cliff Woolley, Philippe Vandermersch, Jonathan Cohen, John Tran, Bryan Catanzaro, and Evan Shelhamer. 2014. cuDNN: Efficient primitives for deep learning. arXiv preprint arXiv:1410.0759

arXiv 2014