Pith. sign in

REVIEW 4 major objections 5 minor 3 cited by

Vortex: Overcoming Memory Capacity Limitations in GPU-Accelerated Large-Scale Data Analytics

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

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

Pith's one-line read This paper shows that a single GPU can run analytical queries over datasets larger than its own memory by pooling the idle PCIe I/O capacity of all GPUs in a multi-GPU server, reporting a 5.7x speedup over the state-of-the-art GPU…

desk verdict Solid IO-engineering work with a clean primitive, but the headline 5.7x speedup over Proteus is not hardware-controlled and needs a same-platform baseline. read the letter →

arxiv 2502.09541 v1 pith:6OBD4BBN submitted 2025-02-13 cs.DB cs.DC

Yichao Yuan , Advait Iyer , Lin Ma , Nishil Talati This is my paper · ORCID
classification cs.DBcs.DC
keywords GPU-accelerateddatabasesout-of-corequeryprocessingPCIebandwidthaggregationmulti-GPUsystemsI/OschedulingdataanalyticslatematerializationGPUmemorycapacity
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 claims that the memory-capacity bottleneck that keeps GPUs from accelerating large analytical workloads can be broken in software: a single GPU can process queries over datasets far larger than its own memory by borrowing the idle data-transfer capacity of the other GPUs in a multi-GPU server. No data is cached on the GPU before execution; all rows stream from CPU main memory through all available PCIe links, concentrated on the one GPU doing the computation. If the claim holds, the standard solutions for datasets that exceed GPU memory, such as buying more GPUs to hold the data or splitting work between CPU and GPU, are no longer the only options. A commodity four-GPU server could run warehouse-scale analytical queries with a reported 5.7x speedup over the state-of-the-art GPU baseline, a 3.4x speedup over a CPU-only analytical engine, and roughly 2.5x better price-performance.

What carries the argument

The load-bearing piece is the Exchange primitive, an asynchronous, packetized data-movement operation (with packet size around 20MB) that pools the PCIe links and the SDMA copy engines of all GPUs in the server for the benefit of one target GPU. Exchange is supported by a global scheduler with a flow-control policy, because simultaneous bidirectional traffic competes for CPU memory-controller bandwidth and makes some PCIe paths much faster than others; the policy prevents the device-to-host queue from draining faster than the host-to-device queue. Around Exchange, the programming model introduces ExKernel, which lets programmers write ordinary single-GPU kernels and declare how a large logical array maps into chunks, and a Pipelined Executor that overlaps kernel execution on one buffer with Exchange transfers on the other. The third mechanism is a late-materialization decision rule, threshold $T_H = E/(C_{l2} \times N_{exchange})$, where $E$ is the accessed element size, $C_{l2}$ is the GPU cache-line size, and $N_{exchange}$ is the number of links; below the threshold the executor reads a column on demand via zero-copy access rather than transferring it with SDMA.

What would settle it

Run the same 600GB Star Schema Benchmark on a four-GPU server whose GPUs are attached through a shared PCIe switch (the topology the paper contrasts with its own) while keeping all data in CPU DRAM. If the average speedup over the state-of-the-art GPU baseline collapses toward the single-GPU-I/O numbers (roughly 1.7x on sort and below 3x on joins) rather than staying near the reported 5.7x, the direct per-GPU link topology is the load-bearing premise; if the speedup survives the switch, the mechanism generalizes beyond the paper's hardware assumption.

Watch

Extended reading notes

Core claim

The central discovery is that modern multi-GPU systems already have enough aggregate PCIe bandwidth to feed a single GPU from CPU DRAM at full memory speed, provided the bandwidth of all GPUs is pooled rather than used one-link-per-GPU. Vortex implements this with an I/O primitive that treats neighboring GPUs' copy engines as forwarders: each neighbor receives a small packet from CPU DRAM into a double buffer and immediately forwards it to the target GPU, while the target GPU's own link is used directly, and a global scheduler applies flow control so the host-to-device and device-to-host directions stay balanced. On a four-GPU system this reaches about 140GB/s, matching CPU DRAM bandwidth, and the paper shows that sort, hash join, and Star Schema Benchmark queries over a 600GB database can be executed on one GPU with all input fetched from CPU memory on demand. The result is an out-of-core GPU database that treats I/O as a pooled, schedulable resource rather than a per-device limit.

Load-bearing premise

The headline speedups assume a server where each GPU has its own direct data link to the CPU and the entire working data set already sits in CPU main memory; if the GPUs share a PCIe switch or the data must be read from disk, the pooled bandwidth and the reported gains do not apply.

Editorial extensions

If this is right

  • On servers with dedicated per-GPU PCIe links, analytical queries over datasets several times larger than GPU memory can be executed by a single GPU without any GPU-side data cache, with transfer bandwidth matching CPU DRAM bandwidth.
  • Existing single-GPU kernels written for in-memory data can be reused for out-of-core data by wrapping them as ExKernels and declaring chunk mappings, so vendor-tuned sort and merge primitives carry over unchanged.
  • Co-locating compute-bound AI workloads on the forwarding GPUs costs those workloads about 6.8% average slowdown, so a four-GPU server can serve both analytics and AI without dedicating all GPUs to either.
  • The selectivity threshold formula gives an automatic way to decide column-by-column whether to transfer a column via pooled DMA or read it selectively with zero-copy access, cutting data movement for low-selectivity predicates.
  • For I/O-bound operators such as hash join, every additional unit of pooled PCIe bandwidth translates almost directly into query throughput, so the benefit grows as servers gain more GPUs or faster interconnects.

Reading between the lines

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

  • Beyond the paper, the same bandwidth-pooling idea should apply to other directions and fabrics, such as aggregating NVLink or Infinity Fabric paths or pooling I/O for multiple analytics GPUs at once; the paper only evaluates one target GPU at a time.
  • Beyond the paper, the threshold formula is architecture-dependent but provides a reusable decision rule: any GPU with known cache-line size and link count can derive its own crossover selectivity, which is testable on NVIDIA hardware with NVLink.
  • Beyond the paper, if the PCIe pool saturates CPU DRAM bandwidth as claimed, then on an eight-GPU two-socket server the I/O-bound join throughput should continue scaling with the number of forwarding links until DRAM bandwidth is exhausted, a prediction that a direct bandwidth measurement could confirm.
  • Beyond the paper, the cold-start scenario the paper evaluates is conservative because no data is reused between queries, so a production server that keeps small dimension tables or hot partitions resident could improve on the reported numbers without changing the framework.
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

4 major / 5 minor

Summary. Vortex is a GPU-accelerated data analytics framework for datasets larger than GPU memory. It assumes a multi-GPU server in which each GPU has a direct PCIe link to the CPU and all data initially resides in CPU DRAM. The core idea is to use the idle IO resources of neighboring GPUs to forward data to a single target GPU through a pipelined SDMA-based primitive called Exchange, thereby aggregating PCIe bandwidth for one IO-intensive analytics workload while the other GPUs run compute-bound AI tasks. The paper also contributes an IO-decoupled programming model (ExKernel and Pipelined Executor), operator case studies for sort and hash join, and a late-materialization optimization based on zero-copy access. The evaluation measures Exchange throughput, sort and join throughput, SSB at scale factor 1000, interference with AI workloads, and price-performance, reporting a 5.7x average speedup over Proteus and 2.5x price-performance over DuckDB.

Significance. The high-level idea is timely and practically relevant: modern servers increasingly mix analytics and AI workloads, and co-locating them so that analytics consumes idle IO bandwidth is a compelling system design. The paper's internal same-machine ablations, especially the comparison of Exchange against a runtime-based baseline and Vortex against a single-GPU IO configuration, are clean and support the value of the IO primitive. The derived late-materialization threshold is also a useful, simple design rule that is validated by a microbenchmark. If the headline comparisons are made properly controlled, this would be a strong systems contribution with a released artifact and clear scope.

major comments (4)
  1. [§8.1, Figure 13; §7.3] The headline 5.7x speedup over Proteus is not a controlled hardware comparison: Proteus runs on an NVIDIA A40 (approximately 0.7 TB/s GDDR6 bandwidth) on a separate machine, while Vortex runs on AMD MI100 GPUs (approximately 1.2 TB/s HBM2 bandwidth) using the Crystal engine. The paper itself attributes the larger speedups on Q2.*, Q3.*, and Q4.* to higher memory-throughput demands, so the platform difference can account for a substantial fraction of the reported 5.7x. To make the central claim load-bearing, the authors should either provide a same-hardware baseline (e.g., a single-GPU SDMA or zero-copy out-of-core execution using Crystal on the same MI100 system) and report the speedup over that baseline, or clearly mark the Proteus comparison as cross-platform and remove it from the abstract.
  2. [§7.1; abstract] The abstract states that Vortex achieves its results 'without caching any data in GPU memory,' but the SSB setup in §7.1 explicitly loads the dimension tables into GPU memory and keeps them there for the duration of query processing. This contradicts the cold-start definition given in §7.1 and means the end-to-end SSB results do not actually exercise the no-GPU-caching scenario for the dimension tables. The authors should either revise the claim to 'without caching the large fact data' and justify caching small dimension tables, or rerun the SSB experiments with all data transferred in every query.
  3. [§2.3–2.4, Figure 1] The central performance result relies on the topology in Figure 1(c), in which each GPU has its own PCIe x16 link to the CPU, and on the assumption that all data already resides in CPU DRAM. On shared-switch topologies (Figure 1(b)) or when data must be read from disk, the aggregated 140 GB/s IO throughput and the derived speedups cannot be expected to hold. While §2.4 states the cold-start assumption, the abstract and conclusion present the claims without this qualifier. The scope should be made explicit in the abstract and conclusion, and ideally the paper should include a brief analytical or experimental treatment of the shared-switch case.
  4. [§6.2, §8.1; Figure 12] The claim that Vortex outperforms Triton Join on GPU (1.3x) is based on published numbers from [38] obtained on a different machine equipped with CPU-GPU NVLink, not on a same-hardware baseline. This is the same class of confound as the Proteus comparison and weakens the specific assertion that standard PCIe can beat NVLink. The authors should either run the Triton join implementation on the Vortex machine or present the comparison as a cross-system reference and explicitly discuss the hardware differences.
minor comments (5)
  1. [§8.2] The system-efficiency equation appears typographically wrong: it should read speedupsys = (speedup_t * (1 - slowdown_t) + 3 * (1 - slowdown_f)) / 4, and the term 'slowdown' is used both as a percentage and as a fraction in the same discussion.
  2. [Figure 10] Figure 10 has no axis labels or legend; the x-axis should be defined as a selectivity or inverse-selectivity measure, and the two curves should be labeled directly in the figure.
  3. [§6.1.3, §6.2.2] Important algorithm details, including the binary-search-based merge partition computation and the binary-search-based group partition for hash join, are deferred to the technical report; the paper should include at least a concise pseudocode or formal description so the operator designs are self-contained.
  4. [§8.1] There is a typo in the sentence 'By comparing the bars of navie and Proteus-GPU': 'navie' should be 'naive'.
  5. [Figure 13] The legend mixes baselines running on different hardware; the figure caption should state explicitly which bars run on the MI100 system, which on the A40, and which on the Intel server, so readers are not misled into treating all bars as same-machine measurements.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: Vortex's central claims are grounded in measured system evaluations and an analytically derived threshold validated by a separate microbenchmark.

full rationale

I walked the derivation chain from the Exchange primitive (§4), the IO-decoupled programming model (§5), the sort/join case studies (§6.1–6.2), the late materialization threshold (§6.3), and the SSB/price-performance results (§8–9). The late-materialization threshold TH = E/(Cl2 × N_exchange) is derived from architectural parameters (cache line size, element size, exchange GPU count) and is then checked against a microbenchmark that was not used to fit the formula; the benchmark crossover at SEL > 64 agrees with the independently derived 1/64 threshold, so the validation is not circular. The Exchange primitive's 140 GB/s throughput is an experimental measurement against an in-house runtime baseline, and the sort/join/SSB speedups are measured against external baselines (TBB, PARADIS, DuckDB, Triton Join, Proteus). The only self-citations in the paper point to the authors' technical report for implementation details (e.g., MergeExKernel's binary-search partitioning, the customized join kernel, and the 25%-slice resource-partitioning comparison); these are not load-bearing to the paper's central claims and are not invoked as a uniqueness theorem or as a substitute for evidence. The headline 5.7x-vs-Proteus comparison is not hardware-controlled, since Proteus runs on an NVIDIA A40 while Vortex runs on an AMD MI100, and the SSB speedups may partly reflect GPU memory bandwidth and the Crystal engine rather than the Exchange primitive alone. That is a measurement-validity concern, not a circularity: the number is not equal by construction to any fitted parameter or self-citation. I therefore find no circular step meeting the evidence bar.

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

The central claim rests on three domain assumptions about hardware topology, cold data placement, and idle IO on forwarding GPUs; these are stated in the paper. The only hand-tuned numeric parameters are the Exchange packet size, the stall wait, and the buffer split. No invented physical entities are introduced.

free parameters (3)
  • Exchange packet granularity = 20 MB
    Chosen empirically to balance pipeline prologue/epilogue overhead and per-copy runtime overhead; used in all end-to-end evaluations (Section 8.1).
  • Flow-control stall wait = 10 microseconds
    Empirically set waiting period for link workers when flow control rejects a pop; a few percent of packet transfer time (Section 4.3).
  • Executor buffer split (mem A / mem B) = 16 GB each
    Allocates two 16 GB buffers from 32 GB MI100 for double-buffered pipelining (Section 5.3); affects pipeline depth and chunk size.
assumptions (4)
  • domain assumption Each GPU is connected to the CPU through a dedicated PCIe link with full bandwidth (Figure 1(c)).
    Invoked in Section 2.3 to motivate the design and in Section 7.3 for the testbed. If topology uses PCIe switches, aggregate H2D bandwidth is much lower and the Exchange speedup is not achievable.
  • domain assumption All data to be processed resides in CPU DRAM before execution (cold-start), with no GPU-side caching.
    Stated in Section 2.4 and Section 7.1. If data is disk-resident or exceeds CPU DRAM, Vortex's IO path is not the limiting factor and the design does not apply.
  • domain assumption Forwarding GPUs run compute-bound workloads that underutilize SDMA engines and PCIe links.
    Stated in Section 2.4 and evaluated in Section 8.2. If co-tenant workloads are IO- or memory-bound, interference can be significant (measured up to 16.9% for LLM decode), shrinking the co-location benefit.
  • domain assumption Operators can be decomposed into chunk-wise data-parallel steps with no access jumps exceeding GPU memory.
    Explicitly stated as a limitation in Section 5.1. This scopes Vortex to data analytics operators, excluding algorithms with large random access patterns.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Vortex: Overcoming Memory Capacity Limitations in GPU-Accelerated Large-Scale Data Analytics." pith.science (2026). https://pith.science/paper/6OBD4BBN

@misc{pith2026250209541,
  author       = {Pith},
  title        = {Pith review of: Vortex: Overcoming Memory Capacity Limitations in GPU-Accelerated Large-Scale Data Analytics},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/6OBD4BBN}},
  note         = {Machine review of arXiv:2502.09541}
}
abstract

Despite the high computational throughput of GPUs, limited memory capacity and bandwidth-limited CPU-GPU communication via PCIe links remain significant bottlenecks for accelerating large-scale data analytics workloads. This paper introduces Vortex, a GPU-accelerated framework designed for data analytics workloads that exceed GPU memory capacity. A key aspect of our framework is an optimized IO primitive that leverages all available PCIe links in multi-GPU systems for the IO demand of a single target GPU. It routes data through other GPUs to such target GPU that handles IO-intensive analytics tasks. This approach is advantageous when other GPUs are occupied with compute-bound workloads, such as popular AI applications that typically underutilize IO resources. We also introduce a novel programming model that separates GPU kernel development from IO scheduling, reducing programmer burden and enabling GPU code reuse. Additionally, we present the design of certain important query operators and discuss a late materialization technique based on GPU's zero-copy memory access. Without caching any data in GPU memory, Vortex improves the performance of the state-of-the-art GPU baseline, Proteus, by 5.7$\times$ on average and enhances price performance by 2.5$\times$ compared to a CPU-based DuckDB baseline.

Figures

Figures reproduced from arXiv: 2502.09541 by the authors.

Figure 1
Figure 1. Evolution of GPU system topology. understanding. In this configuration, the GPU is connected to the CPU via a single PCIe link, while the CPU connects to its mem￾ory through DDR channels. Considering the common standards of PCIe 4.0 and DDR4-3200, which are prevalent in contemporary systems, the CPU typically has eight memory channels. The PCIe link provides approximately 28GB/s bandwidth in one direction and up to … view at source ↗
Figure 2
Figure 2. Multi￾ple paths between GPU0 and CPU. device 0 device 3 CPU -> GPU 0 GPU 0 -> CPU... CPU -> GPU 3 GPU 0 -> GPU 3 GPU 3 -> GPU 0 GPU 3 -> CPU (a) H2D D2H D2D Time device 0 device 3 ... } } forward CPU data to GPU 0 forward GPU 0 data to CPU (b) [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 4
Figure 4. The interface of Exchange operation. GPU0 and 2 is only around 8GB/s, and around 20GB/s on GPU1. This is significantly less than the 28GB/s bandwidth when there is no D2H traffic. In our test machine with 4 AMD MI100s, data traffic in the D2H direction consistently outperforms H2D traffic when competing for bandwidth, making H2D links more susceptible to interference from other data transfers. This issue causes load… view at source ↗
Figures from the paper (5 more)
Figure 7
Figure 7. Figure 7: Implementation details of ExKernel execution. outputs() methods, while size() indicates the total number of chunks to process. During this process, data in DRAM remains stationary; only a mapping table is created to associate data with its respective chunk. A chunk can…
Figure 8
Figure 8. Figure 8: The implementation details of sort operation upon [PITH_FULL_IMAGE:figures/full_fig_p007_8.png]
Figure 10
Figure 10. Figure 10: Zero copy vs GPU IO. partitioning phase, the data is divided into 16.8 million groups that can be processed independently. Even with a dataset of 16 billion rows, each group contains approximately 1000 tuples and occupies around 16KB, which fits comfortably within the…
Figure 11
Figure 11. Figure 11: Data transfer throughput achieved by the IO-primitives with different transfer granularity. [PITH_FULL_IMAGE:figures/full_fig_p010_11.png]
Figure 13
Figure 13. Figure 13: Star Schema Benchmark execution time and speedup. [PITH_FULL_IMAGE:figures/full_fig_p011_13.png]

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 3 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. ThunderAgent: A Simple, Fast and Program-Aware Agentic Inference System

    cs.OS 2026-02 conditional novelty 6.0 of 10

    A program-aware scheduler and tool-lifecycle manager for LLM agent workflows raises serving throughput by 1.5–3.6x and RL rollout throughput by 1.8–3.9x over vLLM/Continuum baselines.

  2. GPU Acceleration of SQL Analytics on Compressed Data

    cs.DB 2025-06 conditional novelty 6.0 of 10

    SQL operators execute directly on RLE, index, and dictionary-compressed columns on GPUs, with order-of-magnitude speedups for pre-sorted production workloads but only 2x mean gains on general public datasets.

  3. Terabyte-Scale Analytics in the Blink of an Eye

    cs.DB 2025-06 conditional novelty 6.0 of 10

    Distributed TQP, a GPU-accelerated SQL engine using NCCL and RCCL collectives, runs the full TPC-H 1TB workload in 0.53s on 40 H100 GPUs, more than 60x faster than a high-end CPU server.

Reference graph

Works this paper leans on

65 extracted references · 33 canonical work pages · cited by 3 Pith papers

  1. [38]

    Clemens Lutz, Sebastian Breß, Steffen Zeuch, Tilmann Rabl, and Volker Markl

  2. [1]

    Daniel J Abadi, Daniel S Myers, David J DeWitt, and Samuel R Madden. 2006. Materialization strategies in a column-oriented DBMS. In 2007 IEEE 23rd Interna- tional Conference on Data Engineering . IEEE, 466–475

    work page 2006

  3. [2]

    Andy Adinets and Duane Merrill. 2022. Onesweep: A Faster Least Significant Digit Radix Sort for GPUs. arXiv:2206.01784 [cs.DC] https://arxiv.org/abs/2206. 01784

    arXiv 2022

  4. [3]

    Stability AI. 2024. Stable Diffusion 3 Medium Model. https://huggingface.co/ stabilityai/stable-diffusion-3-medium Accessed: 07/25/2024

    work page 2024

  5. [4]

    AI@Meta. 2024. Llama 3 Model Card. https://github.com/meta-llama/llama3/ blob/main/MODEL_CARD.md Accessed: 2024-09-25

    work page 2024

  6. [5]

    AMD. 2024. 4th Generation AMD EPYC Processors. https://www.amd.com/en/ products/processors/server/epyc/4th-generation-9004-and-8004-series.htmll Accessed: 07/23/2024

    work page 2024

  7. [6]

    AMD. 2024. AMD Instinct MI300X Accelerators. https://www.amd.com/en/ products/accelerators/instinct/mi300/mi300x.html Accessed: 07/23/2024

    work page 2024

  8. [7]

    AMD. 2024. HIP documentation. https://rocm.docs.amd.com/projects/HIP/en/ latest/ Accessed: 07/04/2024

    work page 2024

Show all 65 references
  1. [8]

    AMD. 2024. rocPRIM documentation. https://rocm.docs.amd.com/projects/ rocPRIM/en/latest/ Accessed: 07/02/2024

    2024

  2. [9]

    AMD. 2024. STREAM Benchmark. https://www.amd.com/en/developer/ zen-software-studio/applications/spack/stream-benchmark.html Accessed: 07/31/2024

    2024

  3. [10]

    Gon- zalez, Carlos Guestrin, and Matei Zaharia

    Asim Biswal, Liana Patel, Siddarth Jha, Amog Kamsetty, Shu Liu, Joseph E. Gon- zalez, Carlos Guestrin, and Matei Zaharia. 2024. Text2SQL is Not Enough: Unifying AI and Databases with TAG. arXiv:2408.14717 [cs.DB] https: //arxiv.org/abs/2408.14717

    2024 arXiv

  4. [11]

    Boncz, Stefan Manegold, and Martin L

    Peter A. Boncz, Stefan Manegold, and Martin L. Kersten. 1999. Database Archi- tecture Optimized for the New Bottleneck: Memory Access. In Proceedings of the 25th International Conference on Very Large Data Bases (VLDB ’99) . Morgan Kaufmann Publishers Inc., San Francisco, CA, ...

    1999

  5. [12]

    Sebastian Breß, Bastian Köcher, Max Heimel, Volker Markl, Michael Saecker, and Gunter Saake. 2014. Ocelot/HyPE: optimized data processing on hetero- geneous hardware. Proc. VLDB Endow. 7, 13 (Aug. 2014), 1609–1612. https: //doi.org/10.14778/2733004.2733042

    2014

  6. [13]

    Jiashen Cao, Rathijit Sen, Matteo Interlandi, Joy Arulraj, and Hyesoon Kim. 2023. GPU Database Systems Characterization and Optimization. Proc. VLDB Endow. 17, 3 (Nov. 2023), 441–454. https://doi.org/10.14778/3632093.3632107

    2023

  7. [14]

    Cen Chen, Kenli Li, Aijia Ouyang, and Keqin Li. 2018. FlinkCL: An OpenCL- Based In-Memory Computing Architecture on Heterogeneous CPU-GPU Clus- ters for Big Data. IEEE Trans. Comput. 67, 12 (Dec. 2018), 1765–1779. https: //doi.org/10.1109/TC.2018.2839719

    2018

  8. [15]

    Minsik Cho, Daniel Brand, Rajesh Bordawekar, Ulrich Finkler, Vincent Ku- landaisamy, and Ruchir Puri. 2015. PARADIS: an efficient parallel algorithm for in-place radix sort. Proc. VLDB Endow. 8, 12 (Aug. 2015), 1518–1529. https://doi.org/10.14778/2824032.2824050

    2015

  9. [16]

    Periklis Chrysogelos, Manos Karpathiotakis, Raja Appuswamy, and Anastasia Ailamaki. 2019. HetExchange: encapsulating heterogeneous CPU-GPU paral- lelism in JIT compiled engines. Proc. VLDB Endow. 12, 5 (Jan. 2019), 544–556. https://doi.org/10.14778/3303753.3303760

    2019

  10. [17]

    Andrew Crotty, Viktor Leis, and Andrew Pavlo. 2022. Are You Sure You Want to Use MMAP in Your Database Management System?. In 12th Conference on Innovative Data Systems Research, CIDR 2022, Chaminade, CA, USA, January 9-12,

    2022

  11. [18]

    Wenqi Fan, Yujuan Ding, Liangbo Ning, Shijie Wang, Hengyun Li, Dawei Yin, Tat-Seng Chua, and Qing Li. 2024. A Survey on RAG Meeting LLMs: To- wards Retrieval-Augmented Large Language Models. arXiv:2405.06211 [cs.CL] https://arxiv.org/abs/2405.06211

    2024 arXiv

  12. [19]

    Govindaraju, Qiong Luo, and Pedro V

    Rui Fang, Bingsheng He, Mian Lu, Ke Yang, Naga K. Govindaraju, Qiong Luo, and Pedro V. Sander. 2007. GPUQP: query co-processing using graphics processors. In Proceedings of the 2007 ACM SIGMOD International Conference on Management of Data (Beijing, China) (SIGMOD ’07). Associ...

    2007

  13. [20]

    Wells Fargo. 2024. Want to see where your money goes? Just ask Fargo. https://sites.wf.com/fargo/ Accessed: 2024-09-25

    2024

  14. [21]

    Forbes. 2024. JPMorgan Chase Leads AI Revolution In Finance With Launch Of LLM Suite. https://www.forbes.com/sites/janakirammsv/2024/07/30/jpmorgan- chase-leads-ai-revolution-in-finance-with-launch-of-llm-suite/ Accessed: 2024- 09-25

    2024

  15. [22]

    Henning Funke, Sebastian Breß, Stefan Noll, Volker Markl, and Jens Teubner

  16. [23]

    Aditya Golatkar, Alessandro Achille, Luca Zancato, Yu-Xiang Wang, Ashwin Swaminathan, and Stefano Soatto. 2024. CPR: Retrieval Augmented Generation for Copyright Protection. arXiv:2403.18920 [cs.CR] https://arxiv.org/abs/2403. 18920

    2024 arXiv

  17. [24]

    Alicia Golden, Samuel Hsia, Fei Sun, Bilge Acun, Basil Hosmer, Yejin Lee, Zachary DeVito, Jeff Johnson, Gu-Yeon Wei, David Brooks, and Carole-Jean Wu. 2024. Generative AI Beyond LLMs: System Implications of Multi-Modal Generation. arXiv:2312.14385 [cs.DC] https://arxiv.org/abs...

    2024 arXiv

  18. [25]

    Michael Gowanlock and Ben Karsin. 2018. Sorting Large Datasets with Heteroge- neous CPU/GPU Architectures. In 2018 IEEE International Parallel and Distributed Processing Symposium Workshops (IPDPSW). 560–569. https://doi.org/10.1109/ IPDPSW.2018.00095

    2018

  19. [26]

    Oded Green, Robert McColl, and David A. Bader. 2012. GPU merge path: a GPU merging algorithm. In Proceedings of the 26th ACM International Con- ference on Supercomputing (San Servolo Island, Venice, Italy) (ICS ’12) . As- sociation for Computing Machinery, New York, NY, USA, 3...

    2012

  20. [27]

    Govindaraju, Qiong Luo, and Pedro V

    Bingsheng He, Mian Lu, Ke Yang, Rui Fang, Naga K. Govindaraju, Qiong Luo, and Pedro V. Sander. 2009. Relational query coprocessing on graphics pro- cessors. ACM Trans. Database Syst. 34, 4, Article 21 (Dec. 2009), 39 pages. https://doi.org/10.1145/1620585.1620588

    2009

  21. [29]

    HEAVY.AI. 2024. HEAVY.AI Documentation. https://docs.heavy.ai/installation- and-configuration/system-requirements/hardware Accessed: 07/24/2024

    2024

  22. [30]

    Max Heimel, Michael Saecker, Holger Pirk, Stefan Manegold, and Volker Markl

  23. [32]

    Binyuan Hui, Xiang Shi, Ruiying Geng, Binhua Li, Yongbin Li, Jian Sun, and Xiaodan Zhu. 2021. Improving Text-to-SQL with Schema Dependency Learning. arXiv:2103.04399 [cs.CL] https://arxiv.org/abs/2103.04399

    2021 arXiv

  24. [33]

    Tomas Karnagel, Dirk Habich, and Wolfgang Lehner. 2017. Adaptive work place- ment for query processing on heterogeneous computing resources. Proc. VLDB Endow. 10, 7 (March 2017), 733–744. https://doi.org/10.14778/3067421.3067423

    2017

  25. [34]

    Donald Knuth. 1973. The Art Of Computer Programming, vol. 3: Sorting And Searching. Addison-Wesley. 391–392 pages

    1973

  26. [35]

    M. Lam. 1988. Software pipelining: an effective scheduling technique for VLIW machines. SIGPLAN Not. 23, 7 (June 1988), 318–328. https://doi.org/10.1145/ 960116.54022

    1988

  27. [36]

    Haotian Liu, Bo Tang, Jiashu Zhang, Yangshen Deng, Xiao Yan, Xinying Zheng, Qiaomu Shen, Dan Zeng, Zunyao Mao, Chaozu Zhang, Zhengxin You, Zhi- hao Wang, Runzhe Jiang, Fang Wang, Man Lung Yiu, Huan Li, Mingji Han, Qian Li, and Zhenghai Luo. 2022. GHive: accelerating analytical...

    2022

  28. [39]

    Tobias Maltenberger, Ivan Ilic, Ilin Tolovski, and Tilmann Rabl. 2022. Evaluating Multi-GPU Sorting with Modern Interconnects. In Proceedings of the 2022 Inter- national Conference on Management of Data (Philadelphia, PA, USA) (SIGMOD ’22). Association for Computing Machinery,...

    2022

  29. [40]

    NVidia. 2024. cub documentation. https://docs.nvidia.com/cuda/cub/index.html Accessed: 07/02/2024

    2024

  30. [41]

    NVidia. 2024. CUDA Programming Guide. https://docs.nvidia.com/cuda/cuda-c- programming-guide/index.html#programming-interface Accessed: 07/04/2024

    2024

  31. [42]

    NVidia. 2024. Thrust. https://developer.nvidia.com/thrust Accessed: 2024-09-30

    2024

  32. [43]

    In Proceedings of the 2022 International Conference on Management of Data (Philadelphia, PA, USA) (SIGMOD ’22)

    Triton Join: Efficiently Scaling to a Large Join State on GPUs with Fast In- terconnects. In Proceedings of the 2022 International Conference on Management of Data (Philadelphia, PA, USA) (SIGMOD ’22). Association for Computing Machin- ery, New York, NY, USA, 1017–1032. https:...

    2022

  33. [44]

    Worst Practices

    Nathan Otterness and James H. Anderson. 2021. Exploring AMD GPU Schedul- ing Details by Experimenting With “Worst Practices”. In Proceedings of the 29th International Conference on Real-Time Networks and Systems (NANTES, France) (RTNS ’21). Association for Computing Machinery,...

    2021

  34. [45]

    Johns Paul, Shengliang Lu, Bingsheng He, and Chiew Tong Lau. 2021. MG-Join: A Scalable Join for Massively Parallel Multi-GPU Architectures. In Proceed- ings of the 2021 International Conference on Management of Data (Virtual Event, China) (SIGMOD ’21). Association for Computin...

    2021

  35. [46]

    Ties Robroek, Ehsan Yousefzadeh-Asl-Miandoab, and Pınar Tözün. 2024. An Analysis of Collocation on GPUs for Deep Learning Training. In Proceedings of the 4th Workshop on Machine Learning and Systems (Athens, Greece) (Eu- roMLSys ’24). Association for Computing Machinery, New Y...

    2024

  36. [47]

    Ran Rui, Hao Li, and Yi-Cheng Tu. 2020. Efficient join algorithms for large database tables in a multi-GPU environment. Proc. VLDB Endow. 14, 4 (Dec. 2020), 708–720. https://doi.org/10.14778/3436905.3436927

    2020

  37. [48]

    Ignacio Sañudo Olmedo, Nicola Capodieci, Jorge Luis Martinez, Andrea Marongiu, and Marko Bertogna. 2020. Dissecting the CUDA scheduling hi- erarchy: a Performance and Predictability Perspective. In 2020 IEEE Real-Time and Embedded Technology and Applications Symposium (RTAS) ....

    2020

  38. [49]

    Panagiotis Sioulas, Periklis Chrysogelos, Manos Karpathiotakis, Raja Ap- puswamy, and Anastasia Ailamaki. 2019. Hardware-Conscious Hash-Joins on GPUs. In 2019 IEEE 35th International Conference on Data Engineering (ICDE) . 698–709. https://doi.org/10.1109/ICDE.2019.00068

    2019

  39. [50]

    RAPIDS Development Team. 2023. RAPIDS: Libraries for End to End GPU Data Science. https://rapids.ai Accessed: 2024-09-30

    2023

  40. [51]

    Neelay Thaker. 2020. Amazon EC2 P4d instances deep dive. https://aws.amazon. com/blogs/compute/amazon-ec2-p4d-instances-deep-dive/

    2020

  41. [52]

    Kaibo Wang, Kai Zhang, Yuan Yuan, Siyuan Ma, Rubao Lee, Xiaoning Ding, and Xiaodong Zhang. 2014. Concurrent analytical query processing with GPUs. Proc. VLDB Endow. 7, 11 (July 2014), 1011–1022. https://doi.org/10.14778/2732967. 2732976

    2014 doi

  42. [53]

    Anil Shanbhag, Samuel Madden, and Xiangyao Yu. 2020. A Study of the Funda- mental Performance Characteristics of GPUs and CPUs for Database Analytics. In Proceedings of the 2020 ACM SIGMOD International Conference on Management of Data (Portland, OR, USA) (SIGMOD ’20). Associa...

    2020

  43. [54]

    Liang Wang, Nan Yang, Xiaolong Huang, Linjun Yang, Rangan Majumder, and Furu Wei. 2024. Improving Text Embeddings with Large Language Models. arXiv:2401.00368 [cs.CL] https://arxiv.org/abs/2401.00368

    2024 arXiv

  44. [55]

    Andreas Weininger. 2002. Efficient execution of joins in a star schema. In Pro- ceedings of the 2002 ACM SIGMOD International Conference on Management of Data (Madison, Wisconsin) (SIGMOD ’02). Association for Computing Machinery, New York, NY, USA, 542–545. https://doi.org/10...

    2002

  45. [56]

    Emma White. 2019. Optimizing deep learning on P3 and P3dn with EFA. https://aws.amazon.com/blogs/compute/optimizing-deep-learning-on- p3-and-p3dn-with-efa/

    2019

  46. [57]

    wikipedia. 2024. Data parallelism. https://en.wikipedia.org/wiki/Data_ parallelism Accessed: 2024-09-25

    2024

  47. [58]

    Liang Wang, Nan Yang, Xiaolong Huang, Binxing Jiao, Linjun Yang, Daxin Jiang, Rangan Majumder, and Furu Wei. 2024. Text Embeddings by Weakly-Supervised Contrastive Pre-training. arXiv:2212.03533 [cs.CL] https://arxiv.org/abs/2212. 03533

    2024 arXiv

  48. [59]

    Yogatama, Weiwei Gong, and Xiangyao Yu

    Bobbi W. Yogatama, Weiwei Gong, and Xiangyao Yu. 2022. Orchestrating Data Placement and Query Execution in Heterogeneous CPU-GPU DBMS. Proc. VLDB Endow. 15, 11 (July 2022), 2491–2503. https://doi.org/10.14778/3551793.3551809

    2022

  49. [60]

    Yichao Yuan, Advait Iyer, Lin Ma, and Nishil Talati. 2024. Vortex: Overcoming Memory Capacity Limitations in GPU-Accelerated Large-Scale Data Analytics (Technical Report). https://figshare.com/s/550db82949fe74dfa41e

    2024

  50. [61]

    Yuan Yuan, Rubao Lee, and Xiaodong Zhang. 2013. The Yin and Yang of process- ing data warehousing queries on GPU devices. Proc. VLDB Endow. 6, 10 (Aug. 2013), 817–828. https://doi.org/10.14778/2536206.2536210

    2013

  51. [62]

    Yi Zhang, Fei Yang, Shuang Peng, Fangyu Wang, and Aimin Pan. 2024. Flat- tenQuant: Breaking Through the Inference Compute-bound for Large Lan- guage Models with Per-tensor Quantization. arXiv:2402.17985 [cs.LG] https: //arxiv.org/abs/2402.17985

    2024 arXiv

  52. [63]

    Kuan Xu, Yongbo Wang, Yongliang Wang, Zujie Wen, and Yang Dong. 2023. SeaD: End-to-end Text-to-SQL Generation with Schema-aware Denoising. arXiv:2105.07911 [cs.CL] https://arxiv.org/abs/2105.07911

    2023 arXiv

  53. [68]

    Siyan Zhao, Daniel Israel, Guy Van den Broeck, and Aditya Grover. 2024. Prepack- ing: A Simple Method for Fast Prefilling and Increased Throughput in Large Language Models. arXiv:2404.09529 [cs.LG] https://arxiv.org/abs/2404.09529

    2024 arXiv

  54. [2013]

    Hardware-oblivious parallelism for in-memory column-stores. Proc. VLDB Endow. 6, 9 (July 2013), 709–720. https://doi.org/10.14778/2536360.2536370

    2013

  55. [2018]

    In Proceed- ings of the 2018 International Conference on Management of Data (Houston, TX, USA) (SIGMOD ’18)

    Pipelined Query Processing in Coprocessor Environments. In Proceed- ings of the 2018 International Conference on Management of Data (Houston, TX, USA) (SIGMOD ’18). Association for Computing Machinery, New York, NY, USA, 1603–1618. https://doi.org/10.1145/3183713.3183734

    2018

  56. [2020]

    In Proceedings of the 2020 ACM SIGMOD International Conference on Management of Data (Portland, OR, USA) (SIGMOD ’20)

    Pump Up the Volume: Processing Large Data on GPUs with Fast Inter- connects. In Proceedings of the 2020 ACM SIGMOD International Conference on Management of Data (Portland, OR, USA) (SIGMOD ’20). Association for Comput- ing Machinery, New York, NY, USA, 1633–1649. https://doi....

    2020 doi

  57. [2022]

    https://www.cidrdb.org/cidr2022/papers/p13-crotty.pdf

    www.cidrdb.org. https://www.cidrdb.org/cidr2022/papers/p13-crotty.pdf

Pith tools

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