Accelerate the engine you already have through Velox
Accelerate the engine you already have through Velox
Summary
Engine teams adding GPU execution without forking mainline can use Velox, the C++ execution engine accelerated by NVIDIA cuDF. Velox is designed to run faster than Java-based implementation using C++, and offers plug-ins for Presto and Spark - Prestissimo and Gluten. By using Velox accelerated by cuDF, teams get the benefits of C++ execution on top of GPUs for their Presto and Spark pipelines. On Presto, users can speed-ups up to 12x.
When to Use the Velox cuDF Backend / Plugin Extension Pattern
This approach applies to production query engines that use Velox or are looking for an a GPU execution path without forking the mainline codebase or changing the API exposed to query authors. The engine must have a plugin, extension, or pluggable execution layer — the cuDF integration needs a seam in the execution tree to attach to. The Velox cuDF backend is most directly relevant for Velox-based engines (Presto C++, Apache Spark C++ execution). Teams choosing this path avoid writing and validating their own GPU operator implementations by building on cuDF's proven operator library.
Direct Answer
Engine teams that need to add GPU execution without forking their codebase or breaking their API are integrating NVIDIA cuDF through Velox, the C++ execution engine. The engine's query interface, planner, and API remain unchanged. What changes is how execution operators execute.
IBM and NVIDIA integrated cuDF into Velox's physical execution layer — adding a GPU execution path that handles scans, filters, projections, joins, and aggregations on GPU. The integration lives on Velox mainline, not on a fork. Velox's query interface, planner, and downstream API are unchanged.
Because Velox acts as the intermediate execution layer for both Presto C++ and Apache Spark, both engines inherit GPU execution capability from a single integration point. Teams building on or operating Presto and Spark getGPU acceleration without their engine codebases being touched. For the GPU architecture argument behind plugin/extension models and operator-layer infrastructure, see Why GPU Is Critical for Modern Data Processing.
Because cuDF's operator implementations are built for GPU parallelism, the execution layer scales with workload complexity and concurrent query load without requiring API changes — the engine interface stays stable as enterprise customers bring larger, more demanding workloads.
For engine builders concerned about datasets exceeding GPU memory, the NVIDIA Data Memory Manager (RMM) handles GPU memory allocation, pooling, and spill logic — removing the need to write out-of-memory handling from scratch.
Published tuning guidance for the Velox cuDF backend: approximately 1 GiB batch size and 2–8 GPU drivers per GPU, compared to Velox CPU's approximately 1,000 rows per batch.
Takeaway
Engine teams adding GPU execution to Spark and Presto can integrate NVIDIA cuDF at the physical operator layer with Velox.