WGLog is introduced, the first web-browser-native GPU engine for compute-bound recursive database queries and replaces hash-table-based joins with atomic-free sorted-array joins, eliminating the serialization bottleneck that hash tables suffer on skewed graphs.
Abstract
Recursive query computation, central to graph algorithms and relational databases, demands GPU acceleration due to its inherent computational intensity. While substantial prior work addresses GPU implementations of recursive queries that require fixed-point evaluation, existing systems are restricted to native execution environments. We introduce WGLog, the first web-browser-native GPU engine for compute-bound recursive database queries. WGLog is built entirely on WebGPU compute shaders, a cross-platform API that enables GPU acceleration in web browsers. WGLog leverages two key technical innovations. First, we replace hash-table-based joins with atomic-free sorted-array joins, eliminating the serialization bottleneck that hash tables suffer on skewed graphs. Second, we develop an asynchronous execution pipeline using WebGPU's indirect dispatch capability, which eliminates GPU-host synchronizations that would otherwise dominate per-iteration overhead. On representative workloads, WGLog delivers a 1.48--4.68x speedup over native GPU systems and orders-of-magnitude improvement over CPU and WebAssembly implementations.
DataKernelBench is introduced, which translates SQL into validated PyTorch TorchPlan programs and evaluates LLMs that optimize either the core tensor-bounded snippet or the full query in CUDA or Triton through execution-guided repair and finds that higher-performing implementations commonly use kernel fusion and execution-strategy changes, stronger models benefit most from full-query specialization, and workload context matters more than hardware context.
Local subgraph counting computes the exact number of occurrences of a query graph around every vertex in a data graph. By capturing local higher-order structure, it supports extensive applications in network analysis and graph learning. The fastest existing method, SCOPE, accelerates counting through query graph decomposition, but it is designed for single-threaded CPU execution. As a result, it struggles on large graphs and cannot take advantage of modern GPU hardware. A naïve GPU adaptation is also ineffective: as the number of parallel GPU threads grows, the memory footprint of their intermediate results quickly drains the device memory.
We develop a high-performance GPU solution for local subgraph counting that preserves SCOPE's tree-decomposition framework while explicitly resolving the tension between massive GPU parallelism and limited device memory. Our approach compresses the intermediate join-and-aggregate results and proposes an insert-failure restart mechanism that guarantees correctness under bounded memory. We further design a key-mapping strategy that enables lock-free hash tables for higher throughput, eventually integrating these components into a complete GPU execution framework capable of handling arbitrarily complex queries. Experiments show that our GPU-accelerated method achieves up to a 35× speedup over a multi-threaded SCOPE implementation, reducing the processing time for a million-scale graph from days to about 20 minutes and making local subgraph counting practical at large scale.
Qiao He, Yi-Ran Li, M. Yiu et al.· Proceedings of the VLDB Endo...· 0 citations
OpRAG is presented, a resource-deterministic distributed runtime for GPU-backed multi-stage RAG workflows that combines an Arrow zero-copy data plane, persistent workers, bounded queues, CPU tokenizer prefetching, batched GPU embedding, and overlapped retrieval/generation execution to reduce non-model overhead around LLM inference.
A. Sarker, M. Staylor, Aymen Alsaadi et al.· 1 citation
The convergence of unified, cloud-native Lakehouse platforms such as Microsoft Fabric, and the widespread deployment of AI-optimized hardware in datacenters is driving the rise of GPU-based analytical engines. However, building a GPU query engine that is both competitive with hand-tuned implementations and portable across vendors (NVIDIA, AMD, custom silicon) remains an open challenge, as existing systems either lock into a single vendor's toolchain or sacrifice performance for generality. In this paper, we present TQP++, an ML-compiler-native analytical query processor that repurposes ML compiler infrastructure to close this gap, achieving high performance and hardware portability from a single codebase. TQP++ integrates the Antares compilation framework with tiered GPU resource scheduling for SQL operators, a map-reduce-oriented fusion schema that eliminates intermediate materializations, and a multi-gated execution graph that adapts operator algorithms to runtime data characteristics. On TPC-H SF 100, TQP++ executes all 22 queries in 1.1 second on an A100 (7× faster than HeavyDB, 15× faster than CPU baselines) and under 0.7 seconds on H100 and MI300, while targeting 9 devices across 3 vendors—including Xbox—without code changes. To our knowledge, this is the most hardware-diverse GPU query processor reported to date, while achieving sub-second TPC-H SF100 on a single GPU.
Wei Cui, Peng Cheng, Carlo Curino et al.· Proceedings of the VLDB Endo...· 0 citations
Modern web applications increasingly require computationally intensive processing, yet JavaScript, the dominant language of the web, has traditionally been limited to a single-threaded execution model. Node.js Worker Threads and browser Web Workers provide low-level mechanisms for parallel execution, but developers lack high-level abstractions that capture recurring parallel structures as reusable patterns. In this paper, we present ParaWeb, a TypeScript library that implements ten parallel programming patterns for server-side Node.js, client-side browser environments, and WebGPU compute shaders. ParaWeb provides three implementation variants for each pattern: a message-passing (MP) variant based on structured cloning via postMessage, a shared-buffer (Shared) variant that uses SharedArrayBuffer with typed array views, and a GPU variant that uses WebGPU compute shaders for hardware-accelerated execution. We describe the architecture, design decisions, and pattern-specific implementation strategies, and we evaluate the performance of all thirty implementations across three data sizes. Experimental evaluation results show that the CPU-based variants achieve speedups of up to 11.6x with 16 threads for compute-bound patterns, while the GPU variants reach speedups of up to 260x for compute-bound patterns with high arithmetic intensity such as Farm, Scatter, Reduce, and Map. A case study on five image-convolution filters further shows that GPU acceleration reaches up to 414x speedup over single-threaded CPU on non-separable kernels, with consistent scaling across 1024x1024$, 2048x2048$, and 4K images.
Compilation-based query execution produces optimized machine code per query but introduces a cold-start problem: when the compiled code is not cached, the query stalls during compilation, delaying data processing by up to orders of magnitude relative to the query's execution time. This overhead dominates short-running queries and creates latency variability for both interactive analytics and ETL pipelines. We introduce
composition
, a complementary technique in which query-time code generation emits only lightweight glue code to arrange pre-compiled operators into a query-specific execution plan, rather than re-emitting or compiling any operator logic, at a fraction of the cost of full compilation. Composition eliminates the cold-start stall while compilation catches up in the background and takes over for peak performance. We implement composition in Amazon Redshift through
FastCompose
, which enables both modes from a single code-base without relying on a separate fallback engine for cold runs. Compared to compilation-only cold starts (with caching and serverless compilation active), FastCompose achieves 7.0× speedup on TPC-DS 100 GB, 2.0× on TPC-DS 3 TB, 12.0× on TPC-H 100 GB, and 1.6× on TPC-H 3 TB. FastCompose is deployed across thousands of Redshift clusters. On production workloads, composition reduces cold-start dashboard load times by 3.5× and ETL duration by 1.9×, removing compilation as a bottleneck.
Yan-Kun Shen, Kiran Chinta, Shermal Fernando et al.· Proceedings of the VLDB Endo...· 0 citations
We use cookies to run the site and, with your consent, for analytics and to show ads.
See our Cookie Policy.
