Pith. sign in

REVIEW 5 major objections 7 minor 31 references

RTCUDB: Building Databases with RT Processors

T0 review · 5 major / 7 minor · reviewed 2026-08-11 · deepseek-v4-flash

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

Pith's one-line read RTCUDB claims that GPU ray-tracing cores can accelerate full analytical queries by mapping Scan, GroupBy, and Aggregation into a single ray-tracing job.

desk verdict RTCUDB is a genuinely novel mapping of full query pipelines onto RT cores, but the evaluation's unquantified BVH build cost and emulated baseline keep the headline speedup from being fully trustworthy. read the letter →

arxiv 2412.09337 v2 pith:BD36GO73 submitted 2024-12-12 cs.DB

Xuri Shi , Kai Zhang , X. Sean Wang , Xiaodong Zhang , Rubao Lee This is my paper · ORCID
classification cs.DB
keywords raytracingcoresGPUdatabasequeryprocessingStarSchemaBenchmarkboundingvolumehierarchyaggregationgroupbyscan
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

RTCUDB sets out to prove that the ray-tracing (RT) cores in commodity GPUs can accelerate full database queries, not just individual scans. The paper's claim is that by encoding the attributes used in Scan, GroupBy, and Aggregation as coordinates of triangles and launching rays only into the region where predicates hold, a query engine can evaluate all three operators in one ray-tracing pass. It reports that this approach outperforms Crystal, the state-of-the-art CUDA-core GPU database, by up to 18.3 times on the Star Schema Benchmark and cuts average memory-bandwidth usage from 97.4% to 36.7%. If true, this matters because CUDA-based engines have hit a memory-bandwidth wall, while RT cores offer a different path: specialized traversal hardware instead of streaming data through memory.

What carries the argument

The central mechanism is the coordinate encoding: the aggregation attribute becomes the $x$-coordinate, the grouping attribute becomes the $y$-coordinate, and the scanned attribute becomes the $z$-coordinate of each tuple's triangle, while queries become rays through a box. The load-bearing design identity is that a triangle leg length of $S_x$ or $S_y$ combined with ray spacing of half that length guarantees every triangle in the query region is hit at least once and at most three times, so the flag-bit array in the shader prevents double counting.

What would settle it

Measure end-to-end query time with BVH construction included for a workload where each query touches a different dataset; if RTCUDB is not faster than Crystal once build time is counted, the reported 18.3x speedup rests on excluding precomputation.

Watch

Extended reading notes

Core claim

The central discovery is that the three core operators of a query—filtering, grouping, and aggregation—can be fused into one hardware-accelerated ray-tracing pass. Each tuple is stored as a right triangle whose vertex coordinates carry the attribute values; a query defines a cuboid region in the same 3D space, and rays fired through that region hit exactly the triangles that satisfy the predicate. The Any Hit Shader accumulates sum and count per group, so a single traversal returns grouped aggregates without scanning the whole table. A BVH is built offline and treated as a materialized view, sidestepping per-query construction. The paper argues this is why RT cores can beat a CUDA-core engine that is already saturating memory bandwidth.

Load-bearing premise

The speedup claims assume BVH construction can be done offline and treated as a materialized view, so the 227.84 ms build time for 120 million tuples is not charged against query runtime.

Editorial extensions

If this is right

  • Selective analytical queries can run more than an order of magnitude faster than a CUDA-core engine that already saturates GPU memory bandwidth.
  • GPU database performance can stop being memory-bandwidth-bound and instead be limited by RT-core traversal throughput.
  • A single 3D coordinate can carry several columns through bijective predicate encoding, dictionary grouping encoding, and bit-packed aggregation encoding, so multi-attribute operators do not require extra memory reads.
  • Queries without one of the three core operators are handled by treating the missing operator as a no-op or as full selectivity, keeping the single-ray-job execution model.
  • Post-processing operators like Having and OrderBy can run on CUDA cores after the RT pass, extending the engine to the full SSB query set.
  • One consequence the authors leave implicit is that the 18.3x speedup is an amortized, offline-BVH figure: their own reported numbers for 120M tuples are 227.84 ms to build the BVH versus 0.75 ms to trace rays, so a single cold query would look very different.
  • A testable extension is to apply the same coordinate-encoding trick to other fixed-function traversal hardware or to geometric queries such as spatial joins, which the paper does not explore.
  • The one-access-per-tuple property suggests the engine is best suited to denormalized wide tables; for normalized schemas the join cost moves into BVH construction and maintenance.
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.

Referee Report

5 major / 7 minor

Summary. The paper presents RTCUDB, a GPU database query engine that maps Scan, GroupBy, and Aggregation into a single ray-tracing job executed on RT cores. Data tuples are represented as axis-aligned right triangles whose vertex coordinates encode the attributes used by the three operators; queries are translated into a set of rays in a three-dimensional query area, and an Any Hit Shader accumulates aggregate results per group. The authors evaluate RTCUDB on SSB flat at scale factors 1, 10, and 20, comparing against an emulated version of Crystal. They report up to 18.3x speedup over Crystal and an average memory bandwidth reduction from 97.4% to 36.7%. The method also includes a pure-CUDA version to demonstrate the role of RT cores.

Significance. The idea of composing multiple relational operators into one hardware-accelerated ray-traversal job is novel and, if properly validated, would be a significant contribution to the emerging area of RT-core data processing. The paper identifies a real bottleneck (memory-bandwidth saturation of CUDA-based engines) and proposes a mechanism that can in principle avoid it. However, the central performance claims currently rest on an offline-precomputation assumption and an unvalidated emulated baseline; the current evidence is therefore not yet sufficient to establish the advertised speedups.

major comments (5)
  1. [Section 6.2 / Section 2.4] The reported query times exclude the BVH build cost. Section 2.4 itself reports that building a BVH for 120M tuples takes 227.84 ms, while ray traversal takes 0.75 ms; at SF=20 Crystal times in Figure 11(c) are on the order of tens to hundreds of milliseconds. Charging even one BVH build per query would reverse the speedup for one-shot queries, and the paper neither reports BVH memory overhead nor an amortization analysis for repeated queries. Please report end-to-end (cold-start) execution times or a clear amortized analysis, and qualify the abstract's unqualified speedup claim.
  2. [Section 6.1] The baseline is described as 'we emulate the implementation of Crystal on SSB queries and build a version that supports SSB flat.' The paper does not validate this emulation against the original Crystal system or its published numbers, nor does it detail which optimizations (e.g., tile-based shared-memory scan) are preserved. Since the headline speedup is relative to Crystal, the baseline must be demonstrated to be faithful; otherwise the speedup numbers are not interpretable. The removal of OrderBy from the SSB queries also needs to be justified as not biasing the comparison.
  3. [Section 3.2 / Section 6.2] The right-triangle leg lengths Sx and Sy are never specified, yet they determine the ray-grid spacing (Sx/2, Sy/2), the number of rays, and therefore the runtime. Without reporting their values and a sensitivity analysis, the performance comparison is not reproducible and the claim of a parameter-free mechanism is unsupported. Please report the chosen values per experiment and the sensitivity of the results to them.
  4. [Section 6.1] The stated software configuration, CUDA 10.1 and OptiX 7.1, is not compatible with the NVIDIA GeForce RTX 4090 used for the main experiments: Ada Lovelace GPUs require CUDA 11.8 or later, and OptiX 7.1 predates Ada support. This casts doubt on the reproducibility of all measurements in Section 6.2. Please correct the version numbers or explain the available compatibility.
  5. [Section 6.3] The pure-CUDA comparison that is used to conclude that RT cores are 'crucial' is run on a different GPU (TITAN X Pascal, no RT cores, OptiX 5.1, SF=1) than the main experiments (RTX 4090, SF=20). The huge slowdown (258x-588x) may be dominated by the GPU generation and software stack rather than the absence of RT cores. A same-architecture comparison with RT cores disabled, or a direct CUDA reimplementation on the same GPU, is needed to support the architectural conclusion.
minor comments (7)
  1. [Section 4.2] The text says 'English ∈ [0,101)' but the valid integer range for a score is [0,100]; please clarify whether the bound is exclusive or if there is an off-by-one error.
  2. [Section 6.2] The phrase 'faster ... by 82.08%' is ambiguous; please state the speedup ratio (e.g., 1.82x). Also, 'at least 1.0× faster' is tautological and should be replaced with a precise statement.
  3. [Algorithm 1] Algorithm 1 uses Vsum[b] and Vcount[b] with b derived from the Y-coordinate, but for GroupBy with multiple encoded attributes the mapping from encoded Y to group index and the handling of multiple aggregate functions are not shown; the pseudocode should be extended or referenced.
  4. [Related Work / Section 6.1] There are several typos: 'Cyrstal' in Section 6.1, 'Tenser cores' in Section 7, and 'V olker' in reference [7].
  5. [Figure 13] The y-axis label 'Memory Throughput (GB/s)' and legend 'Bandwidth Crystal RTCUDB' are unclear; please state how throughput is measured and what 'Bandwidth' refers to.
  6. [Section 3.1] The claim that 'all the data attributes needed for the three operators with only one memory access' is overstated, since a triangle is stored as three vertices (three float3 values) and the BVH traversal itself reads internal nodes; please rephrase.
  7. [Section 2.4] The text '2.3 × 104 times slower' should be formatted as 2.3 × 10^4.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the encoding and evaluation are externally grounded; the BVH-build exclusion is an evaluation caveat, not a circular reduction.

full rationale

No circular derivation chain is present. RTCUDB's central claim—that mapping Scan, GroupBy, and Aggregation into a single RT job improves performance and reduces memory-bandwidth pressure—is an empirical systems claim evaluated against SSB, an external benchmark, and against Crystal, an independently developed GPU database (even though the local Crystal baseline is emulated). The encoding schemes (bijective encoding for Scan predicates, dictionary encoding for GroupBy, bit-packing for Aggregation) are deterministic data transformations whose correctness and performance are measured; none of the reported speedups (up to 18.3x) or bandwidth figures (36.7%) is used as an input to the method. The self-citation to RTScan is motivational and provides background; the paper does not rely on RTScan's published results as a load-bearing premise for the central multi-operator mapping claim, and Section 6.5 runs an in-house RTScan-based comparison rather than citing away the core result. The main evaluation caveat—BVH construction is performed offline and treated as a materialized view, while Section 2.4 reports 227.84 ms to build a BVH for 120M tuples versus 0.75 ms for ray launch—is a costing and fairness limitation, not a circular definition: the paper does not amortize build cost or report BVH memory overhead, but that does not make the reported query times equal to the inputs by construction. No equation in the paper has its output defined as its input, and no fitted parameter is renamed as a prediction. Under the stated rules, this is a non-circular systems paper, though its headline comparison would be materially affected if cold-start BVH build cost were included.

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

The system relies on standard IEEE 754 float precision, on the hardware behavior of RT cores, and on the off-line pre-computation of BVHs. The two undeclared free parameters (Sx, Sy and the attribute ordering heuristic) directly affect measured performance. No new physical or architectural entity is postulated.

free parameters (2)
  • Sx, Sy (right triangle leg lengths) = not reported
    Set in Section 3.2 as the lengths of the triangle legs used as primitives. They fix the ray-grid spacing (Sx/2, Sy/2), hence the number of rays launched and the expected number of ray-triangle intersections. Never specified in Section 6, so the measured runtimes cannot be reproduced.
  • Attribute order in bijective Scan encoding = heuristic: larger predicate ranges placed later
    Section 4.2 states the ordering tends to place attributes with larger predicate ranges later to reduce the number of disjoint query intervals. This choice changes the ray-launch plan and the performance, and no optimality result is given.
assumptions (4)
  • domain assumption Ray tracing cores perform BVH traversal and ray-triangle intersection tests in hardware for triangles.
    Invoked in Sections 2.2 and 3.2 as the hardware foundation; if RT cores did not accelerate these primitives, RTCUDB would lose its performance basis (Section 6.3 shows the software fallback is 423x slower).
  • domain assumption Data attributes used in Scan can be encoded as mixed-radix indices preserving predicate range structure, and predicate ranges map to intervals in the encoded space.
    Section 4.2 relies on this to launch rays over the query area; it holds for integer attributes with dictionary encoding but restricts queries to conjunctive predicates.
  • standard math A 32-bit float exactly represents integers up to 2^24.
    Section 4.5 states the encoding limit; used to justify that SSB attribute ranges fit in coordinates.
  • domain assumption Queries in the supported class are known in advance so appropriate BVHs can be pre-built offline.
    Sections 3.1 and 6.1 assume BVHs are materialized views; this is load-bearing for the performance comparison because BVH build time (227.84 ms per 120M tuples per Section 2.4) is excluded from query runtime.

how reviews work

0 comments
Cite this review

Pith. "Pith review of RTCUDB: Building Databases with RT Processors." pith.science (2026). https://pith.science/paper/BD36GO73

@misc{pith2026241209337,
  author       = {Pith},
  title        = {Pith review of: RTCUDB: Building Databases with RT Processors},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/BD36GO73}},
  note         = {Machine review of arXiv:2412.09337}
}
read the original abstract

A spectrum of new hardware has been studied to accelerate database systems in the past decade. Specifically, CUDA cores are known to benefit from the fast development of GPUs and make notable performance improvements. The state-of-the-art GPU-based implementation, i.e., Crystal, can achieve up to 61 times higher performance than CPU-based implementations. However, experiments show that the approach has already saturated almost all GPU memory bandwidth, which means there is little room left for further performance improvements. We introduce RTCUDB, the first query engine that leverages ray tracing (RT) cores in GPUs to accelerate database query processing. RTCUDB efficiently transforms the evaluation of a query into a ray-tracing job in a three-dimensional space. By dramatically reducing the amount of accessed data and optimizing the data access pattern with the ray tracing mechanism, the performance of RTCUDB is no longer limited by the memory bandwidth as in CUDA-based implementations. Experimental results show that RTCUDB outperforms the state-of-the-art GPU-based query engine by up to 18.3 times while the memory bandwidth usage drops to only 36.7% on average.

Figures

Figures reproduced from arXiv: 2412.09337 by the authors.

Figure 1
Figure 1. Running Scan on CUDA-based database systems [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Comparison of query runtime for Crystal, MonetDB, and HeavyDB on SSB flat q11 q12 q13 q21 q22 q23 q31 q32 q33 q34 q41 q42 q43AVG Queries 0 250 500 750 1000 Memory Throughput (GB/s) Memory Bandwidth Crystal [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 5
Figure 5. Two strategies of query execution with RT cores (a) Table Score and the corresponding primitives of its data records in space (b) The rays corresponding to query Q0 (3D) (c) The rays corresponding to query Q0 (XY plane) X (Math [Aggregation]) Y (Class [Group by]) Z (English [Scan]) 60 100 ½sy ½sx ↑ ↑ ↑ ↑ ↑ ↓ sx ↑ sy ↓ X (Math [Aggregation]) Y (Class [Group by]) ↑ ↓ ↑ ↓ ½sy A B C X (Math [Aggregation]) Y (Class [Grou… view at source ↗
Figures from the paper (5 more)
Figure 7
Figure 7. Figure 7: The workflow of RTCUDB encoding schemes for each operator to map the attributes as one coordinate (Section 4). Besides, encoding more attributes in each BVH can support more queries for execution. The workflow of RTCUDB is illustrated in [PITH_FULL_IMAGE:figures/full_…
Figure 9
Figure 9. Figure 9: Encoding for GroupBy Score1 Score2 Score3 Score4 ... 32 bits build phase encode attr. Any Hit Shader decode aggr. func1 aggr. func2 aggr. func3 aggr. func4 [PITH_FULL_IMAGE:figures/full_fig_p007_9.png]
Figure 12
Figure 12. Figure 12: Performance com￾parison of RTCUDB (pure CUDA) and Crystal implies a smaller number of data records in the query area, that is, a smaller amount of data to be accessed. Among the above queries, although q11 does not have the highest selec￾tivity (1.99%, the maximum sel…
Figure 13
Figure 13. Figure 13: Query memory throughput of RTCUDB and Crystal [PITH_FULL_IMAGE:figures/full_fig_p011_13.png]
Figure 15
Figure 15. Figure 15: Performance improvement with encoding on Scan q21 q22 q23 q31 q32 q33 q34 q41 q42 q43 AVG Queries 10 0 Execution Time (ms) splitting on GroupBy encoding on GroupBy [PITH_FULL_IMAGE:figures/full_fig_p012_15.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

31 extracted references · 30 canonical work pages

  1. [1]

    Blazingsql

    BlazingSQL. Blazingsql. https://github.com/ BlazingDB/blazingsql, 2021

    work page 2021

  2. [2]

    Monet: A next-generation DBMS kernel for query-intensive applications

    Peter A Boncz et al. Monet: A next-generation DBMS kernel for query-intensive applications. PhD thesis, Ph. d. thesis, Universiteit van Amsterdam, Amsterdam, The Netherlands, 2002

    work page 2002

  3. [3]

    Gpu database systems charac- terization and optimization

    Jiashen Cao, Rathijit Sen, Matteo Interlandi, Joy Arul- raj, and Hyesoon Kim. Gpu database systems charac- terization and optimization. Proceedings of the VLDB Endowment, 17(3):441–454, 2023

    work page 2023

  4. [4]

    Clickhouse

    ClickHouse. Clickhouse. https://clickhouse.com/ docs/en/getting-started/example-datasets/ star-schema, 2024

    work page 2024

  5. [5]

    Practical filtering for efficient ray-traced directional oc- clusion

    Kevin Egan, Frédo Durand, and Ravi Ramamoorthi. Practical filtering for efficient ray-traced directional oc- clusion. In Proceedings of the 2011 SIGGRAPH Asia Conference, pages 1–10, 2011

    work page 2011

  6. [6]

    Exploring the use of ray tracing for future games

    Heiko Friedrich, Johannes Günther, Andreas Dietrich, Michael Scherbaum, Hans-Peter Seidel, and Philipp Slusallek. Exploring the use of ray tracing for future games. In Proceedings of the 2006 ACM SIGGRAPH Symposium on Videogames, pages 41–50, 2006

    work page 2006

  7. [7]

    Pipelined query processing in coprocessor environments

    Henning Funke, Sebastian Breß, Stefan Noll, V olker Markl, and Jens Teubner. Pipelined query processing in coprocessor environments. In Proceedings of the 2018 International Conference on Management of Data, pages 1603–1618, 2018

    work page 2018

  8. [8]

    Franco Fuschini, Hassan El-Sallabi, Vittorio Degli- Esposti, Lasse Vuokko, Doriana Guiducci, and Pertti Vainikainen. Analysis of multipath propagation in urban environment through multidimensional measurements and advanced ray tracing simulation.IEEE Transactions on Antennas and Propagation, 56(3):848–857, 2008

    work page 2008

Show all 31 references
  1. [9]

    Query processing on tensor computation runtimes

    Dong He, Supun Nakandala, Dalitso Banda, Rathijit Sen, Karla Saur, Kwanghyun Park, Carlo Curino, Jesús Camacho-Rodríguez, Konstantinos Karanasos, and Mat- teo Interlandi. Query processing on tensor computation runtimes. arXiv preprint arXiv:2203.01877, 2022

    2022 arXiv

  2. [10]

    HeavyDB. Heavydb. https://github.com/ heavyai/heavydb, 2022

    2022

  3. [11]

    Rtindex: Exploiting hardware-accelerated gpu raytracing for database indexing

    Justus Henneberg and Felix Schuhknecht. Rtindex: Exploiting hardware-accelerated gpu raytracing for database indexing. arXiv preprint arXiv:2303.01139, 2023

    2023 arXiv

  4. [12]

    Tcudb: Accelerating database with tensor processors

    Yu-Ching Hu, Yuliang Li, and Hung-Wei Tseng. Tcudb: Accelerating database with tensor processors. In Pro- ceedings of the 2022 International Conference on Man- agement of Data, pages 1360–1374, 2022

    2022

  5. [13]

    High quality rendering using ray tracing and photon mapping

    Henrik Wann Jensen and Per Christensen. High quality rendering using ray tracing and photon mapping. In ACM SIGGRAPH 2007 courses, pages 1–es. 2007

    2007

  6. [14]

    Hippogriffdb: Balanc- ing i/o and gpu bandwidth in big data analytics

    Jing Li, Hung-Wei Tseng, Chunbin Lin, Yannis Papakon- stantinou, and Steven Swanson. Hippogriffdb: Balanc- ing i/o and gpu bandwidth in big data analytics. Pro- ceedings of the VLDB Endowment , 9(14):1647–1658, 2016

    2016

  7. [15]

    Rtscan: Efficient scan with ray trac- ing cores

    Yangming Lv, Kai Zhang, Ziming Wang, Xiaodong Zhang, Rubao Lee, Zhenying He, Yinan Jing, and X Sean Wang. Rtscan: Efficient scan with ray trac- ing cores. Proceedings of the VLDB Endowment , 17(6):1460–1472, 2024

    2024

  8. [16]

    Accelerating range minimum queries with ray tracing cores

    Enzo Meneses, Cristóbal A Navarro, Héctor Ferrada, and Felipe A Quezada. Accelerating range minimum queries with ray tracing cores. Future Generation Com- puter Systems, 157:98–111, 2024

    2024

  9. [17]

    Efficient space skipping and adaptive sampling of unstructured volumes using hardware accelerated ray tracing

    Nate Morrical, Will Usher, Ingo Wald, and Valerio Pas- cucci. Efficient space skipping and adaptive sampling of unstructured volumes using hardware accelerated ray tracing. In 2019 IEEE Visualization Conference (VIS), pages 256–260. IEEE, 2019

    2019

  10. [18]

    Accelerating unstructured mesh point location with rt cores

    Nate Morrical, Ingo Wald, Will Usher, and Valerio Pas- cucci. Accelerating unstructured mesh point location with rt cores. IEEE transactions on visualization and computer graphics, 28(8):2852–2866, 2020

    2020

  11. [19]

    Rt-knns unbound: Using rt cores to accelerate unre- stricted neighbor search

    Vani Nagarajan, Durga Mandarapu, and Milind Kulka- rni. Rt-knns unbound: Using rt cores to accelerate unre- stricted neighbor search. In Proceedings of the 37th In- ternational Conference on Supercomputing, pages 289– 300, 2023

    2023

  12. [20]

    An efficient fpga-based database processor for fast database analytics

    Xuan-Thuan Nguyen, Hong-Thu Nguyen, Trong-Thuc Hoang, Katsumi Inoue, Osamu Shimojo, Toshio Mu- rayama, Kenji Tominaga, and Cong-Kha Pham. An efficient fpga-based database processor for fast database analytics. In 2016 IEEE International Symposium on Circuits and Systems (ISCAS...

    2016

  13. [21]

    Nvidia turing gpu architec- ture

    NVIDIA. Nvidia turing gpu architec- ture. https://images.nvidia.cn/aem-dam/ en-zz/Solutions/design-visualization/ technologies/turing-architecture/ NVIDIA-Turing-Architecture-Whitepaper.pdf , 2018. 13

    2018

  14. [22]

    The star schema benchmark and aug- mented fact table indexing

    Patrick O’Neil, Elizabeth O’Neil, Xuedong Chen, and Stephen Revilak. The star schema benchmark and aug- mented fact table indexing. In Performance Evaluation and Benchmarking: First TPC Technology Conference, TPCTC 2009, Lyon, France, August 24-28, 2009, Re- vised Selected Pap...

    2009

  15. [23]

    Optix: a general purpose ray tracing engine

    Steven G Parker, James Bigler, Andreas Dietrich, Heiko Friedrich, Jared Hoberock, David Luebke, David McAl- lister, Morgan McGuire, Keith Morley, Austin Robison, et al. Optix: a general purpose ray tracing engine. Acm transactions on graphics (tog), 29(4):1–13, 2010

    2010

  16. [24]

    A study of the fundamental performance characteristics of gpus and cpus for database analytics

    Anil Shanbhag, Samuel Madden, and Xiangyao Yu. A study of the fundamental performance characteristics of gpus and cpus for database analytics. In Proceedings of the 2020 ACM SIGMOD international conference on Management of data, pages 1617–1632, 2020

    2020

  17. [25]

    Database analytics acceler- ation using fpgas

    Bharat Sukhwani, Hong Min, Mathew Thoennes, Parijat Dube, Balakrishna Iyer, Bernard Brezzo, Donna Dillen- berger, and Sameh Asaad. Database analytics acceler- ation using fpgas. In Proceedings of the 21st interna- tional conference on Parallel architectures and compi- lation t...

    2012

  18. [26]

    TPC-H. Tpc-h. https://www.tpc.org/tpch/, 2024

    2024

  19. [27]

    Rtx beyond ray tracing: Exploring the use of hardware ray tracing cores for tet-mesh point location

    Ingo Wald, Will Usher, Nathan Morrical, Laura Lediaev, and Valerio Pascucci. Rtx beyond ray tracing: Exploring the use of hardware ray tracing cores for tet-mesh point location. High Performance Graphics (Short Papers), 7:13, 2019

    2019

  20. [28]

    Concurrent analytical query processing with gpus

    Kaibo Wang, Kai Zhang, Yuan Yuan, Siyuan Ma, Rubao Lee, Xiaoning Ding, and Xiaodong Zhang. Concurrent analytical query processing with gpus. Proceedings of the VLDB Endowment, 7(11):1011–1022, 2014

    2014

  21. [29]

    The yin and yang of processing data warehousing queries on gpu devices

    Yuan Yuan, Rubao Lee, and Xiaodong Zhang. The yin and yang of processing data warehousing queries on gpu devices. Proceedings of the VLDB Endowment , 6(10):817–828, 2013

    2013

  22. [30]

    Ray tracing for radio propagation modeling: Principles and applications

    Zhengqing Yun and Magdy F Iskander. Ray tracing for radio propagation modeling: Principles and applications. IEEE access, 3:1089–1100, 2015

    2015

  23. [31]

    Rtnn: accelerating neighbor search using hardware ray tracing

    Yuhao Zhu. Rtnn: accelerating neighbor search using hardware ray tracing. In Proceedings of the 27th ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming, pages 76–89, 2022. 14

    2022

Pith tools

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