Pith. sign in

REVIEW 3 major objections 5 minor 43 references

For cloud-based image retrieval, tar-packed archives offer the best latency-to-cost balance, while Parquet wins only on very large retrievals at a steep data-transfer price.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

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

T0 review · deepseek-v4-flash

2026-08-03 01:22 UTC pith:LN3P4SD2

load-bearing objection Solid latency benchmark for a real gap, but the headline cost claim rests on an unstated and probably wrong AWS pricing assumption. the 3 major comments →

arxiv 2607.28880 v1 pith:LN3P4SD2 submitted 2026-07-30 cs.DC cs.DBcs.LG

LayoutBench: Performance Benchmarking of Cloud Storage Layouts for Multimedia Data

Debopam Sanyal , Hongjie Chen , Alexey Tumanov , Joshua Kimball This is my paper
classification cs.DC cs.DBcs.LG
keywords storage layoutscloud object storagemultimedia retrievalbenchmarktar archivesParquetconnection reusedata transfer cost
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

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

This paper introduces the first benchmark built specifically to compare how different physical storage layouts affect the speed, data volume, and cost of retrieving multimedia samples from cloud object storage. Using three layouts—one object per image, images packed into tar archives, and images stored as blobs in Parquet—it runs 11 realistic retrieval queries over ImageNet on AWS. The central finding is that tar archives (L2) deliver the lowest latency and lowest total cost for most retrieval sizes, thanks to reuse of TCP connections across byte-range requests. Parquet (L3) is fastest only for the very largest retrievals, but transfers far more data and costs about an order of magnitude more. The paper concludes that data-transfer cost, not compute, dominates the bill, so storage layout is an economic as well as a performance decision.

Core claim

LayoutBench measures three storage layouts for multimedia data in S3: L1 (each sample its own object), L2 (samples packed sequentially into tar archives), and L3 (samples as a BLOB column in Parquet queried through DuckDB). Across 11 queries, three dataset scales, and six EC2 instance types, it finds that L2 generally has lower latency than L1 and L3 because RANGE GET requests to a small number of tar files reuse TCP connections, but this advantage fades for very large result sets; L3 becomes fastest at the largest retrieval sizes because it pushes predicates into columnar scans, yet it transfers several times to an order of magnitude more bytes due to row-group granularity and fixed Parquet

What carries the argument

The central mechanism is the storage layout itself: how metadata (class, size, dimensions) is co-located with raw sample bytes and how retrieval requests hit S3. L1 issues one GET per sample; L2 issues byte-range RANGE GETs into large tar files, enabling TCP connection reuse; L3 stores samples as a Parquet BLOB column and uses a single DuckDB SQL query for predicate evaluation and fetching, which reads whole row groups. The benchmark's contribution is isolating the effect of this layout choice under identical queries, datasets, and instance types.

Load-bearing premise

The conclusion depends on the assumption that the three tested layouts—and the specific Parquet/DuckDB engine used for the columnar layout—are representative of the broader design space of cloud storage layouts for multimedia data.

What would settle it

Run the same 11 queries with a different columnar engine or with Parquet row groups resized to match tar shard boundaries; if L3's data transfer drops to near L1/L2 levels, the claim that columnar layouts inherently over-fetch is refuted. Alternatively, repeat on video or audio data; if tar's latency advantage reverses when per-sample files are much larger, the guidance would not generalize.

Watch this falsifier. Get emailed when new claim-graph text bears on it.

Share X Bluesky LinkedIn Reddit HN

If this is right

  • Practitioners storing image datasets in S3 get concrete guidance: tar-packed archives (WebDataset-style shards) are the default choice for latency and cost, especially for retrieval sizes from dozens to tens of thousands of samples.
  • For workloads dominated by very large scans (more than ~100k samples), columnar layouts like Parquet deserve consideration despite their transfer cost, because their retrieval speed wins when per-request overhead dominates.
  • Cost models for ML data pipelines should account for egress bytes, not just compute time; the paper's numbers imply that at $0.09/GB, a Parquet-based loader can cost an order of magnitude more per query than a tar-based one.
  • Benchmarking storage layouts is now possible: LayoutBench is extensible to new layouts, backends, datasets, and modalities, so future work can test video/audio, write paths, and hybrid layouts.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • A natural extension the paper leaves implicit is testing whether L3's overhead is intrinsic to columnar storage or an artifact of Parquet/DuckDB: a different engine with finer-grained row groups or adaptive encodings could close the transfer gap, which would weaken the economic conclusion.
  • The paper's reliance on ImageNet and 11 hand-picked queries means the ordering could shift for video or audio workloads where sample sizes are orders of magnitude larger; the same benchmark with audio clips or video segments would test whether L2's connection reuse still dominates.
  • The 98%-transfer-cost result suggests a testable rule: any layout that minimizes bytes fetched will likely win on cost regardless of latency, so cloud egress pricing (or its absence, e.g., in-region) should be a first-class variable in storage layout selection.
  • A hybrid layout that uses tar for bulk retrieval and a small columnar index for predicate pushdown could combine L2's I/O efficiency with L3's selective scans; the paper lists this as future work, but the data already hints at the payoff.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 5 minor

Summary. The paper proposes LayoutBench, a benchmark for evaluating cloud storage layouts for multimedia ML retrieval. It implements three layouts on AWS S3: individual objects (L1), tar archives with byte-range access (L2), and Parquet tables queried via DuckDB (L3). Experiments on ImageNet at three dataset scales, 11 predicate queries, and six EC2 instance types measure retrieval time, data transferred, and monetary cost. The central claims are that L2 offers the best latency-cost balance through connection reuse, L3 is fastest only for very large retrievals but transfers far more data and requires more memory, and that data transfer cost dominates total cost, with L3 costing an order of magnitude more than L1 or L2.

Significance. If the results hold, the paper provides practical, actionable guidance for storage layout selection in multimedia ML pipelines, an area lacking systematic benchmarks. The benchmark framework is extensible and the experimental methodology is clearly described. The study is purely empirical with no fitted parameters, which is appropriate for a benchmark paper. However, the generalizability is limited by the use of a single cloud provider, a single columnar engine (DuckDB/Parquet), and the image modality; several of these limitations are acknowledged in §5. The main load-bearing concern is the cost model's S3 transfer pricing assumption, which is not supported as stated.

major comments (3)
  1. [§4.5, Table 5, abstract] The cost model sets C_network = $0.09 × D, and the abstract/Takeaway #9 conclude that data transfer dominates total cost and L3 costs an order of magnitude more. However, the client is an EC2 instance. AWS charges $0.00/GB for S3-to-EC2 transfer within the same region; $0.09/GB applies to internet/cross-region egress. The paper never states the region or egress type. If the standard same-region deployment was used, C_network = 0, and Table 5's L3 total would drop from $9.202 to about $0.019, L1 to about $0.010, and L2 to about $0.005 — making L3 only a few times more expensive and invalidating the 'data transfer dominates' claim. This is load-bearing; the authors must either specify and justify a cross-region/internet egress scenario or recompute the cost analysis for same-region transfer.
  2. [§4, first paragraph; Appendix D] The full dataset was run only once, so no error bars are available for the largest-scale results. More importantly, for L3 on the full dataset, the number of threads is adjusted per query (8 for Q6/Q9, 4 for Q7, 2 for Q4) to avoid OOM. This means L3's configuration is not held constant across the very queries that support Takeaway #2 ('L3 is the fastest for very large retrievals'). The observed Q8/full advantage could be partially an artifact of this ad hoc tuning. Please report the exact thread counts per query, state whether the comparisons hold under a fixed configuration, and ideally provide repeated runs or a sensitivity analysis.
  3. [§2.3, §5, Takeaway #5] The paper attributes L3's data-transfer overhead to 'row-group granularity' and frames it as a general property of columnar storage (e.g., 'L3 transfers substantially more data due to row group granularity'). However, only Parquet/DuckDB is tested. Other columnar engines (e.g., Lance, Pixels) or different row-group sizes could reduce over-fetching significantly. Since this overhead drives the cost conclusion, the claims should either be scoped to the specific L3 implementation or be supported by benchmarking at least one alternative columnar engine. The limitation statement in §5 acknowledges the single-engine issue, but the abstract and takeaways still overgeneralize.
minor comments (5)
  1. [Figure 1 caption] Typo: 'A WS S3' should be 'AWS S3'.
  2. [§3.2, Q4] The SQL predicate is written as 'LIKE % snake' with a space; presumably the intended pattern is '%snake' (no leading space after the placeholder). Please correct the SQL listings in §A–C.
  3. [§4.5] The compute-cost component is negligible partly because each query is a single run with short duration. A persistent or repeated-query workload would make the compute-vs-transfer comparison more representative; consider noting this as a limitation or adding a simple sensitivity analysis.
  4. [§4.1] The abstract says 'L2 achieves lower latency than L1 and L3 through connection reuse, but loses this advantage as retrieval sizes become very large.' The body also shows L1 slightly outperforming L2 for Q1–Q3, Q10, Q11 on the medium and full datasets. The abstract's wording is a coarse summary; consider qualifying it to avoid overstatement.
  5. [Table 2 / Table 3] The instance type 'c8gb.large' is unusual; verify the AWS API name (e.g., c8g.large or c8gd.large). The network speeds given as 'Up to 5 Gigabit' etc. should clarify whether these are burstable or sustained rates, as this affects bandwidth-bound interpretations.

Circularity Check

0 steps flagged

No circularity: the paper is an empirical benchmark whose claims are supported by measured data, not by definitions or self-citations.

full rationale

LayoutBench is a measurement study, not a derivation. The central claims (L2 connection-reuse latency advantage, L3 row-group over-fetching, data-transfer cost dominance) are supported by directly measured retrieval times, transferred byte counts, and an explicit cost formula C = C_network + C_compute with C_network = $0.09 × D and C_compute = r × T. There are no fitted parameters being renamed as predictions, no uniqueness theorems imported from the authors' prior work, and no ansatz smuggled in via citation. The cost conclusion is arithmetic applied to measured D and T under a stated egress price assumption; whether that price is appropriate for same-region S3-to-EC2 traffic is a question of factual correctness or external validity, not circularity. The paper's self-citations ([26], [27]) appear only as general support for the claim that multimedia ML datasets are common and are not load-bearing for any result. The stated limitations (image modality only, read-only retrieval, single cloud provider and query engine) further confirm that the authors present the findings as bounded empirical observations rather than as consequences of their own assumptions. No circular step can be exhibited, so the circularity score is 0.

Axiom & Free-Parameter Ledger

3 free parameters · 3 axioms · 0 invented entities

The central claims rest on empirically measured configurations of AWS S3, EC2 instances, DuckDB, and ImageNet. There are no fitted parameters in the sense of a mathematical derivation; the listed free parameters are hand-chosen configuration values that could affect the quantitative results but are not directly fitted to the target claims. The main axioms are the accuracy of AWS pricing and instance specs, the correctness of ImageNet metadata, and the representativeness of DuckDB for columnar storage.

free parameters (3)
  • L2/L3 file size limits = 64 MB for mini, 512 MB for medium/full
    Chosen by hand, not derived from data. These limits affect the number of tar/Parquet files and thus connection reuse and row-group sizes, but the paper does not sweep or justify this choice.
  • Thread counts = L1/L2: 64 for t3, 128 for c5, 256 for c8gb; L3: 32 default, reduced to 8/4/2 on full dataset
    Configuration choices made to utilize resources or avoid OOM. They are not swept and could bias the relative performance of layouts, especially L3's adjusted thread counts on full-scale runs.
  • EC2 storage provisioning = 8 GB for mini, 32 GB for medium/full, up to 64 GB for large queries
    Chosen to accommodate downloaded data; not justified beyond sufficiency, and could affect caching or disk behavior.
axioms (3)
  • domain assumption AWS S3 pricing and EC2 instance specifications in Table 3 are accurate and current as of the experiments
    The cost model relies entirely on AWS's published rates; if pricing changes, absolute costs change, though the relative ordering likely persists.
  • domain assumption ImageNet labels and metadata (class, size, width, height) are correct for all samples
    The queries filter on these attributes; any errors in metadata would change result-set sizes and measured performance. The paper does not validate metadata accuracy.
  • domain assumption DuckDB's Parquet reader and its row-group granularity are representative of columnar storage engines for multimedia retrieval
    L3 is implemented solely with DuckDB reading Parquet. The paper generalizes L3's behavior to 'columnar storage' (e.g., in takedowns #5 and #9), but does not test alternative columnar engines or formats (ORC, Lance, Pixels) that might have different row-group fetching behavior.

pith-pipeline@v1.3.0-alltime-deepseek · 16287 in / 6045 out tokens · 68588 ms · 2026-08-03T01:22:57.894331+00:00 · methodology

0 comments
Cite this review

Pith. "Pith review of LayoutBench: Performance Benchmarking of Cloud Storage Layouts for Multimedia Data." pith.science (2026). https://pith.science/paper/LN3P4SD2

@misc{pith2026260728880,
  author       = {Pith},
  title        = {Pith review of: LayoutBench: Performance Benchmarking of Cloud Storage Layouts for Multimedia Data},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/LN3P4SD2}},
  note         = {Machine review of arXiv:2607.28880}
}
Share X Bluesky LinkedIn Reddit HN
read the original abstract

Modern multimedia machine learning workloads increasingly store large-scale datasets in cloud object storage services such as AWS S3. How these samples are physically organized in storage (i.e.,storage layout) directly affects how quickly and cheaply they can be retrieved. Yet the benchmarks used to guide storage decisions today focus on database engines and query processing, and none systematically evaluates how different storage layouts perform for multimedia data retrieval. We present LayoutBench, the first benchmark designed to fill this gap. It evaluates three representative layout strategies: storing each sample as an individual object (L1), sequentially packing samples into tar archives (L2), and organizing samples as columns in Parquet files (L3). We measure retrieval time, data transferred, and monetary cost using 11 queries of varying result-set sizes on ImageNet across six AWS EC2 instance configurations that span different network bandwidth and memory tiers. Our experiments reveal that L2 achieves lower latency than L1 and L3 through connection reuse, but loses this advantage as retrieval sizes become very large. L3 is the fastest for very large retrievals but transfers substantially more data across all query sizes due to row-group granularity, and requires significantly more memory. Across all layouts, data transfer cost dominates total expenditure, with L3 costing an order of magnitude more than L1 or L2.

Figures

Figures reproduced from arXiv: 2607.28880 by Alexey Tumanov, Debopam Sanyal, Hongjie Chen, Joshua Kimball.

Figure 1
Figure 1. Figure 1: illustrates the overall architecture. In all layouts, data resides in AWS S3 buckets and a local client EC2 instance runs a query engine that operates in two phases: ➀ a predicate search that consults metadata to identify which samples satisfy a query’s conditions, and ➁ a retrieval step that issues requests to S3 to fetch the matching samples. L1 and L2 perform these two phases sepa￾rately: the predicate … view at source ↗
Figure 2
Figure 2. Figure 2: End-to-end retrieval time in seconds of three layouts [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Data transferred in (a) megabytes and (b) gigabytes [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: examines how each layout scales across different EC2 instance configurations. Unlike [PITH_FULL_IMAGE:figures/full_fig_p005_4.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

43 extracted references · 4 linked inside Pith

  1. [1]

    Petastorm Documentation

    2022. Petastorm Documentation. https://petastorm.readthedocs.io/en/latest/ index.html. Accessed: 2026-02-23

    2022

  2. [2]

    Alex Aizman, Gavin Maltby, and Thomas Breuel. 2019. High performance I/O for large scale deep learning. In2019 IEEE International Conference on Big Data (Big Data). IEEE, 5965–5967

    2019

  3. [3]

    Amazon Web Services, Inc. 2026. Amazon EC2 On-Demand Pricing. https: //aws.amazon.com/ec2/pricing/on-demand/. Accessed: 2026-02-22

    2026

  4. [4]

    Panagiotis Antonopoulos, Alex Budovski, Cristian Diaconu, Alejandro Hernan- dez Saenz, Jack Hu, Hanuma Kodavalla, Donald Kossmann, Sandeep Lingam, Umar Farooq Minhas, Naveen Prakash, et al. 2019. Socrates: The new sql server in the cloud. InProceedings of the 2019 International Conference on Management of Data. 1743–1756

    2019

  5. [5]

    Michael Armbrust, Tathagata Das, Liwen Sun, Burak Yavuz, Shixiong Zhu, Mukul Murthy, Joseph Torres, Herman Van Hovell, Adrian Ionescu, Alicja Łuszczak, et al. 2020. Delta lake: high-performance ACID table storage over cloud object stores.Proceedings of the VLDB Endowment13, 12 (2020), 3411–3424

    2020

  6. [6]

    2025.Applying Data Load- ing Best Practices for ML Training with Amazon S3 Clients

    Alexander Arzhanov, Ilya Isaev, and Roy Allela. 2025.Applying Data Load- ing Best Practices for ML Training with Amazon S3 Clients. Amazon Web Ser- vices. https://aws.amazon.com/blogs/machine-learning/applying-data-loading- best-practices-for-ml-training-with-amazon-s3-clients/ Accessed: 2026-02-22 AWS Machine Learning Blog

    2025

  7. [7]

    Haoqiong Bian and Anastasia Ailamaki. 2022. Pixels: An efficient column store for cloud data lakes. In2022 IEEE 38th International Conference on Data Engineering (ICDE). IEEE, 3078–3090

    2022

  8. [8]

    Zongzhi Chen, Xinjun Yang, Feifei Li, Xuntao Cheng, Qingda Hu, Zheyu Miao, Rongbiao Xie, Xiaofei Wu, Kang Wang, Zhao Song, et al. 2022. CloudJump: opti- mizing cloud databases for cloud storages.Proceedings of the VLDB Endowment 15, 12 (2022), 3432–3444

    2022

  9. [9]

    Jia Deng, Wei Dong, Richard Socher, Li-Jia Li, Kai Li, and Li Fei-Fei. 2009. Imagenet: A large-scale hierarchical image database. In2009 IEEE conference on computer vision and pattern recognition. Ieee, 248–255

    2009

  10. [10]

    Rihan Hai, Christos Koutras, Christoph Quix, and Matthias Jarke. 2023. Data lakes: A survey of functions and systems.IEEE Transactions on Knowledge and Data Engineering35, 12 (2023), 12571–12590

    2023

  11. [11]

    Sasun Hambardzumyan, Abhinav Tuli, Levon Ghukasyan, Fariz Rahman, Hrant Topchyan, David Isayan, Mark McQuade, Mikayel Harutyunyan, Tatevik Hakobyan, Ivo Stranic, et al . 2022. Deep lake: A lakehouse for deep learning. arXiv preprint arXiv:2209.10785(2022)

    Pith/arXiv arXiv 2022

  12. [12]

    Yuanzhe Hao, Xiongpai Qin, Yueguo Chen, Yaru Li, Xiaoguang Sun, Yu Tao, Xiao Zhang, and Xiaoyong Du. 2021. Ts-benchmark: A benchmark for time series databases. In2021 IEEE 37th International Conference on Data Engineering (ICDE). IEEE, 588–599

    2021

  13. [13]

    Zhaoxuan Ji, Zhongle Xie, Yuncheng Wu, and Meihui Zhang. 2024. Lbsc: A cost- aware caching framework for cloud databases. In2024 IEEE 40th International Conference on Data Engineering (ICDE). IEEE, 4911–4924

    2024

  14. [14]

    Abdelouahab Khelifati, Mourad Khayati, Anton Dignös, Djellel Difallah, and Philippe Cudré-Mauroux. 2023. TSM-bench: benchmarking time series database systems for monitoring applications.Proceedings of the VLDB Endowment16, 11 (2023), 3363–3376

    2023

  15. [15]

    Bogyeong Kim, Kyoseung Koo, Undraa Enkhbat, Sohyun Kim, Juhun Kim, and Bongki Moon. 2022. M2bench: a database benchmark for multi-model analytic workloads.Proceedings of the VLDB Endowment16, 4 (2022), 747–759

    2022

  16. [16]

    Justin Levandoski, Garrett Casto, Mingge Deng, Rushabh Desai, Pavan Edara, Thibaud Hottelier, Amir Hormati, Anoop Johnson, Jeff Johnson, Dawid Kurzyniec, et al. 2024. BigLake: BigQuery’s evolution toward a multi-cloud lakehouse. In Companion of the 2024 International Conference on Management of Data. 334–346

    2024

  17. [17]

    Guoliang Li, Wengang Tian, Jinyu Zhang, Ronen Grosman, Zongchao Liu, and Sihao Li. 2024. Gaussdb: A cloud-native multi-primary database with compute- memory-storage disaggregation.Proceedings of the VLDB Endowment17, 12 (2024), 3786–3798

    2024

  18. [18]

    Adrian Lutsch, Muhammad El-Hindi, Matthias Heinrich, Daniel Ritter, Zsolt IstvĂĄn, and Carsten Binnig. 2024. Benchmarking analytical query processing in intel SGXv2.arXiv preprint arXiv:2403.11874(2024)

    Pith/arXiv arXiv 2024

  19. [19]

    Yancan Mao, Ruohang Yin, Liyuan Lei, Peng Ye, Shengfu Zou, Shizheng Tang, Yunzhe Guo, Ye Yuan, Xiaochen Yu, Bo Wan, et al. 2024. Bytemq: A cloud-native streaming data layer in bytedance. InProceedings of the 2024 ACM Symposium on Cloud Computing. 774–791

    2024

  20. [20]

    2021.{CNSBench}: A cloud native storage benchmark

    Alex Merenstein, Vasily Tarasov, Ali Anwar, Deepavali Bhagwat, Julie Lee, Lukas Rupprecht, Dimitris Skourtis, Yang Yang, and Erez Zadok. 2021.{CNSBench}: A cloud native storage benchmark. In19th USENIX Conference on File and Storage Technologies (FAST 21). 263–276

    2021

  21. [21]

    Koyel Mukherjee, Raunak Shah, Shiv Saini, Karanpreet Singh, Harsh Kesarwani, Kavya Barnwal, Ayush Chauhan, et al. 2023. Towards optimizing storage costs on the cloud. In2023 IEEE 39th International Conference on Data Engineering (ICDE). IEEE, 2919–2932

    2023

  22. [22]

    Dan S Nielsen and Ryan McConville. 2022. Mumin: A large-scale multilingual multimodal fact-checked misinformation social network dataset. InProceedings of the 45th international ACM SIGIR conference on research and development in information retrieval. 3141–3153

    2022

  23. [23]

    Weston Pace, Chang She, Lei Xu, Will Jones, Albert Lockett, Jun Wang, and Raunak Shah. 2025. Lance: Efficient random access in columnar storage through adaptive structural encodings.arXiv preprint arXiv:2504.15247(2025)

    Pith/arXiv arXiv 2025

  24. [24]

    James Jie Pan, Jianguo Wang, and Guoliang Li. 2024. Survey of vector database management systems.The VLDB Journal33, 5 (2024), 1591–1615

    2024

  25. [25]

    Brian Regan, Desislava Hristova, and Mariano Beguerisse-Díaz. 2023. Semi- Automated Music Catalog Curation Using Audio and Metadata.. InISMIR. 605– 611

    2023

  26. [26]

    Debopam Sanyal, Jui-Tse Hung, Manav Agrawal, Prahlad Jasti, Shahab Nikkhoo, Somesh Jha, Tianhao Wang, Sibin Mohan, and Alexey Tumanov. 2023. Pareto- secure machine learning (PSML): Fingerprinting and securing inference serving systems.arXiv preprint arXiv:2307.01292(2023)

    Pith/arXiv arXiv 2023

  27. [27]

    Debopam Sanyal, Anantharaman S Iyer, Alind Khare, Trisha Jain, Akshay Jajoo, Myungjin Lee, James Clayton Kerce, and Alexey Tumanov. 2026. KLAS: Using Similarity to Stitch Neural Networks for Improved Accuracy-Efficiency Tradeoffs. InThe Fourteenth International Conference on Learning Representations. EuroMLSys ’26, April 27–30, 2026, Edinburgh, Scotland U...

    2026

  28. [28]

    Raymond Shiau, Hao-Yu Wu, Eric Kim, Yue Li Du, Anqi Guo, Zhiyuan Zhang, Eileen Li, Kunlong Gu, Charles Rosenberg, and Andrew Zhai. 2020. Shop the look: Building a large scale visual shopping system at pinterest. InProceedings of the 26th ACM SIGKDD International Conference on Knowledge Discovery & Data Mining. 3203–3212

    2020

  29. [29]

    The Mosaic ML Team. 2022. streaming. <https://github.com/mosaicml/streaming/ >

    2022

  30. [30]

    2021.Scaling deep learning work- loads with PyTorch / XLA and Cloud TPU VM

    Jordan Totten and Shane Hansen. 2021.Scaling deep learning work- loads with PyTorch / XLA and Cloud TPU VM. Google Cloud. https://cloud.google.com/blog/topics/developers-practitioners/scaling-deep- learning-workloads-pytorch-xla-and-cloud-tpu-vm Accessed: 2026-02-22 Google Cloud Blog, Developers & Practitioners

    2021

  31. [31]

    Hao Wang, Jiaxin Ou, Ming Zhao, Sheng Qiu, Yizheng Jiao, Yi Wang, Qizhong Mao, Zhengyu Yang, Yang Liu, Jianshun Zhang, et al . 2024. LavaStore: ByteDance’s Purpose-Built, High-Performance, Cost-Effective Local Storage En- gine for Cloud Services.Proceedings of the VLDB Endowment17, 12 (2024), 3799–3812

    2024

  32. [32]

    Yifan Wang and Kenneth P Birman. 2025. Diagnosing and resolving cloud platform instability with multi-modal rag llms. InProceedings of the 5th Workshop on Machine Learning and Systems. 139–147

    2025

  33. [33]

    Yi Wang, Yinan He, Yizhuo Li, Kunchang Li, Jiashuo Yu, Xin Ma, Xinhao Li, Guo Chen, Xinyuan Chen, Yaohui Wang, et al. [n. d.]. InternVid: A Large-scale Video-Text Dataset for Multimodal Understanding and Generation. InThe Twelfth International Conference on Learning Representations

  34. [34]

    Zhiqi Wang and Zili Shao. 2022. Timeunion: An efficient architecture with unified data model for timeseries management systems on hybrid cloud storage. InProceedings of the 2022 International Conference on Management of Data. 1418– 1432

    2022

  35. [35]

    Siyang Weng, Qingshuai Wang, Luyi Qu, Rong Zhang, Peng Cai, Weining Qian, and Aoying Zhou. 2024. Lauca: A workload duplicator for benchmarking trans- actional database performance.IEEE Transactions on Knowledge and Data Engi- neering36, 7 (2024), 3180–3194

    2024

  36. [36]

    2022.Efficient PyTorch training with Vertex AI

    Xiang Xu and Rajesh Thallam. 2022.Efficient PyTorch training with Vertex AI. Google Cloud. https://cloud.google.com/blog/products/ai-machine-learning/ efficient-pytorch-training-with-vertex-ai Accessed: Google Cloud Blog, AI & Machine Learning

    2022

  37. [37]

    Sukmin Yun, Rusiru Thushara, Mohammad Bhat, Yongxin Wang, Mingkai Deng, Jinhong Wang, Tianhua Tao, Junbo Li, Haonan Li, Preslav Nakov, et al . 2024. Web2code: A large-scale webpage-to-code dataset and evaluation framework for multimodal llms.Advances in neural information processing systems37 (2024), 112134–112157

    2024

  38. [38]

    Xinyu Zeng, Yulong Hui, Jiahong Shen, Andrew Pavlo, Wes McKinney, and Huanchen Zhang. 2023. An empirical evaluation of columnar storage formats. Proceedings of the VLDB Endowment17, 2 (2023), 148–161

    2023

  39. [39]

    Chao Zhang, Guoliang Li, Leyao Liu, Tao Lv, and Ju Fan. 2025. CloudyBench: A testbed for a comprehensive evaluation of cloud-native databases. In2025 IEEE 41st International Conference on Data Engineering (ICDE). IEEE, 1–13

    2025

  40. [40]

    Chao Zhang, Guoliang Li, and Tao Lv. 2024. HyBench: A new benchmark for HTAP databases.Proceedings of the VLDB Endowment17, 5 (2024), 939–951

    2024

  41. [41]

    Jiashu Zhang, Wen Jiang, Bo Tang, Haoxiang Ma, Lixun Cao, Zhongbin Jiang, Yuanyuan Nie, Fan Wang, Lei Zhang, and Yuming Liang. 2023. Cdsben: Bench- marking the performance of storage services in cloud-native database system at bytedance.Proceedings of the VLDB Endowment16, 12 (2023), 3584–3596

    2023

  42. [42]

    Qing Zheng, Haopeng Chen, Yaguang Wang, Jian Zhang, and Jiangang Duan

  43. [2013]

    InProceedings of the 4th ACM/SPEC International Conference on Performance Engineering

    Cosbench: Cloud object storage benchmark. InProceedings of the 4th ACM/SPEC International Conference on Performance Engineering. 199–210. LayoutBench: Performance Benchmarking of Cloud Storage Layouts for Multimedia Data EuroMLSys ’26, April 27–30, 2026, Edinburgh, Scotland Uk A SQL Statements for Retrieval in L1 The SQL statements(Q1)-(Q11)are used in L1...

    2026