ZipFlow: GPU-Optimized Data Transfer

• ZipFlow is a compiler-based framework that optimizes compressed data transfer in GPU analytics by jointly tuning compression, transfer, and GPU decompression.
• It leverages three parallel patterns—Fully-Parallel, Group-Parallel, and Non-Parallel—to generate tuned GPU kernels and efficiently pipeline PCIe transfers.
• Evaluations show end-to-end improvements up to 3.14× over CPU systems and 2.08× over nvCOMP, demonstrating significant impact in PCIe-bound environments.

Searching arXiv for the cited papers to ground the article in current metadata. arXiv search query: "ZipFlow compiler-based framework compressed data movement modern GPUs" ZipFlow is a compiler-based framework for optimizing compressed data transfer in GPU-accelerated data analytics, particularly in regimes where datasets are much larger than GPU memory and CPU–GPU interconnect bandwidth becomes the dominant bottleneck. It targets analytical workloads such as TPC-H, where GPU query processing can be more than $15\times$ faster than CPU execution, yet overall speedup collapses once CPU$\rightarrow$GPU transfer over PCIe dominates latency. ZipFlow addresses this by jointly optimizing compression, transfer, and GPU decompression, and by organizing lossless compression algorithms into three parallel patterns—Fully-Parallel, Group-Parallel, and Non-Parallel—used to generate tuned GPU kernels, support nested compression schemes, and pipeline PCIe transfer with GPU decompression (Yeo et al., 9 Feb 2026).

1. Problem setting and system objective

ZipFlow is motivated by GPU-accelerated data analytics in which the overhead of data transfer from CPU to GPU becomes a performance bottleneck when the data scales beyond GPU memory capacity due to the limited PCIe bandwidth. The targeted setting assumes modern discrete accelerators such as NVIDIA A100 and H100 or AMD MI50 and MI300X, high-bandwidth HBM2, HBM2e, or HBM3 on the device side, and CPU–GPU interconnects typically based on PCIe 4 or 5 with bandwidth around $32\ \mathrm{GB/s}$ theoretical in the main experiments (Yeo et al., 9 Feb 2026).

The framework is built around the observation that modern analytic systems already store data compressed, for example in Parquet or ORC, and that GPUs are effective decompression engines. The intended workflow is: compress on CPU and store compressed; when a query runs, transfer compressed columns over PCIe; decompress on GPU; and execute GPU query operators. ZipFlow treats the end-to-end query time as the interaction of compression, transfer, decompression, and query execution, with the key challenge being that compression is not free and that excessive emphasis on either compression ratio or decompression speed can worsen end-to-end latency. The framework therefore aims at holistic optimization rather than isolated kernel tuning (Yeo et al., 9 Feb 2026).

A central design premise is that the relevant optimization target is not merely decompression throughput but end-to-end data movement under query execution. In the TPC-H SF=100 evaluation, ZipFlow achieves an average improvement of $2.08$ times over the state-of-the-art GPU compression library nvCOMP and $3.14$ times speedup against CPU-based query processing engines such as DuckDB (Yeo et al., 9 Feb 2026).

2. Pattern classification and computational model

ZipFlow’s central abstraction is that most lossless compression and decompression algorithms used in analytic systems can be implemented as compositions of three parallel patterns: Fully-Parallel, Group-Parallel, and Non-Parallel (Yeo et al., 9 Feb 2026).

The Fully-Parallel pattern describes transformations in which each output element depends only on local input state and there are no cross-element dependencies within a chunk. Formally, for input arrays $I_1, \dots, I_n$ and output array $O$,

$$O[i] = f(I_1[\pi_1(i)], \dots, I_n[\pi_n(i)]), \quad \text{for all } i.$$

Typical algorithms in this class include dictionary decoding, bit unpacking, Float2Int conversion, and many “Fastlanes”-style decoders. Because each element is independent, this pattern is especially suitable for SIMD and SIMT execution and is also the most amenable to kernel fusion (Yeo et al., 9 Feb 2026).

The Group-Parallel pattern partitions data into groups $G_1, G_2, \dots, G_m$. Groups are independent from one another, but within a group there is a small dependency structure and group sizes may be highly non-uniform. Representative cases include RLE decoding, delta-based RLE variants, string-dictionary decompress, and DeltaStride. The canonical RLE decode sequence first computes a prefix sum of count[] to obtain per-group base indices and then expands value[i] across the corresponding output segment. ZipFlow implements the prefix-sum step with PyTorch’s cumsum and the expansion step with a Group-Parallel kernel (Yeo et al., 9 Feb 2026).

The Non-Parallel pattern captures algorithms with intrinsically sequential dependencies inside a chunk. For each chunk $k$,

$\rightarrow$0

This forces serial execution within a chunk, so parallelism arises only by chunking the input into independent segments and assigning each chunk to a thread, warp, or block. ZipFlow classifies ANS, Huffman, LZ4, Snappy, Deflate, and zstd decoding within this category (Yeo et al., 9 Feb 2026).

These patterns are not merely descriptive. They determine kernel generation, scheduling, nesting, and fusion decisions. A plausible implication is that ZipFlow’s main contribution lies in elevating compression structure to an explicit compilation target, so that algorithmic diversity can be handled without reducing the system to a small fixed set of hand-written kernels.

3. Compiler architecture and algorithm composition

ZipFlow is organized into four conceptual layers: the Pattern Layer, the Algorithm Layer, the Nesting Layer, and the Pipelining Layer (Yeo et al., 9 Feb 2026).

The Pattern Layer implements GPU operators corresponding to the three patterns and parameterizes them with a 3D configuration vector $\rightarrow$1, where $\rightarrow$2 is the number of loop iterations per block, $\rightarrow$3 is the number of threads per block, and $\rightarrow$4 is the number of elements that each thread processes per iteration. For Fully-Parallel kernels, each block processes $\rightarrow$5 elements; for Group-Parallel and Non-Parallel kernels, the same vector parameterizes the mapping of work to hardware resources in pattern-specific ways (Yeo et al., 9 Feb 2026).

The Algorithm Layer builds primitive compression and decompression algorithms from pattern-level kernels and can also reuse PyTorch operators such as sort, unique, and cumsum as auxiliary steps. Examples include bit-packing decode as a Fully-Parallel kernel, dictionary decode as a Fully-Parallel kernel, and RLE decode as a two-step combination of PyTorch cumsum and a Group-Parallel expansion kernel (Yeo et al., 9 Feb 2026).

The Nesting Layer composes primitive algorithms into column-specific nested compression schemes. ZipFlow supports flexible nesting such as Dictionary + Bitpack, Float2Int + Bitpack, RLE + DeltaStride + Bitpack, and String-dictionary + Bitpack + ANS. In the TPC-H configuration summarized in the paper, date columns such as L_COMMITDATE, L_RECEIPTDATE, L_SHIPDATE, and O_ORDERDATE use Dictionary encoding | Bit-packing; monetary numeric columns use Float2Int | Bit-packing; O_ORDERKEY uses DeltaStride | [Delta encoding | RLE | [Bit-packing, Bit-packing], Bit-packing]; and comment columns use String-dictionary | Bit-packing | ANS (Yeo et al., 9 Feb 2026).

The Pipelining Layer overlaps CPU$\rightarrow$6GPU transfer with GPU decompression across many chunks. Each block of data has a copy cost $\rightarrow$7 and a decompression cost $\rightarrow$8, and ZipFlow uses Johnson’s algorithm for the 2-machine flow shop scheduling problem to choose an order minimizing total completion time in $\rightarrow$9 time. Machine 1 is PCIe transfer; Machine 2 is GPU decompression. This design is explicitly intended to minimize end-to-end latency rather than only standalone kernel time (Yeo et al., 9 Feb 2026).

4. Scheduling, fusion, and device-specific tuning

The $32\ \mathrm{GB/s}$0 geometry is central to ZipFlow’s scheduling strategy. For Fully-Parallel kernels, the objective is to maximize memory bandwidth usage and GPU occupancy while enabling fusion. In the canonical mapping, $32\ \mathrm{GB/s}$1 controls the number of elements handled per thread per memory transaction, $32\ \mathrm{GB/s}$2 is chosen as a multiple of warp or wavefront size, and $32\ \mathrm{GB/s}$3 determines how many tiles are covered per block. Because output elements are independent, adjacent Fully-Parallel stages can be inlined into one kernel, allowing operations such as bit-unpacking, dictionary lookup, and type conversion to be performed in a single pass (Yeo et al., 9 Feb 2026).

For Group-Parallel kernels, the main concern is load imbalance under non-uniform group sizes. ZipFlow allows multiple blocks to share a group vertically while also allowing each block to process multiple groups horizontally. This arrangement is designed to handle even groups, random group sizes, outlier groups, and mixed distributions, and the evaluation reports that ZipFlow’s RLE decompression measurements remain close to the bandwidth bound across all tested distributions, whereas nvCOMP’s performance is significantly below that bound (Yeo et al., 9 Feb 2026).

For Non-Parallel kernels, ZipFlow accepts that no parallelism exists inside a chunk and therefore extracts parallelism only across chunks. Each chunk is assigned to a thread, and SIMT groups execute many sequential decode loops in lockstep. Chunk size becomes a tunable control knob: smaller chunks expose more parallelism and improve throughput for smaller inputs, whereas larger chunks improve compression ratio and can scale better for larger data (Yeo et al., 9 Feb 2026).

ZipFlow also uses simple bandwidth-based performance models. For bit-packing, the theoretical maximum throughput is approximated by

$32\ \mathrm{GB/s}$4

For fused versus unfused decompression pipelines, the paper derives that a fused kernel moves one compressed input and one plain output, while an unfused two-kernel pipeline moves one compressed input and three plain-data movements, leading to

$32\ \mathrm{GB/s}$5

This explains why fusion can yield more than $32\ \mathrm{GB/s}$6 speedup for some nested schemes (Yeo et al., 9 Feb 2026).

Different GPUs require different configurations. A configuration tuned for one GPU can be suboptimal on another, with up to $32\ \mathrm{GB/s}$7 degradation under a shared configuration. ZipFlow therefore performs offline tuning using a lightweight reinforcement learning search over restricted power-of-two configuration spaces, reducing exploration to around 10 candidates per GPU per pattern instead of brute-force search over tens or hundreds of configurations (Yeo et al., 9 Feb 2026).

5. Algorithms, implementation, and evaluation results

ZipFlow is implemented in Python 3.12 with PyTorch 2.6.0, using custom GPU kernels compiled via CUDA for NVIDIA and ROCm/HIP for AMD. Auxiliary operations such as sort, unique, and cumsum use PyTorch’s built-in GPU operators. The framework is integrated with TQP, a GPU query engine implemented in PyTorch, and functions as a compression subsystem rather than as a standalone DBMS (Yeo et al., 9 Feb 2026).

The supported primitive algorithms in the reported implementation are organized by pattern. Fully-Parallel primitives include Bit-pack/FOR, Delta, Dictionary, and Float2Int. Group-Parallel primitives include RLE, RLE+Delta, RLE+Dictionary, String-dictionary, and DeltaStride. Non-Parallel primitives include LZ4, ANS, and Huffman. Extensibility is an explicit design goal: new algorithms can be composed out of patterns and tuned via $32\ \mathrm{GB/s}$8 (Yeo et al., 9 Feb 2026).

The TPC-H SF=100 evaluation uses NVIDIA A100 80GB over PCIe Gen4 and AMD EPYC 7V12 with 64 cores as the default platform, with additional experiments on NVIDIA H100 80GB, AMD MI300X 192GB, and AMD MI50 32GB. Baselines include nvCOMP 4.0.1.0, DuckDB 1.4.1, SQL Server 2022, Parquet with and without zstd, and BtrBlocks (Yeo et al., 9 Feb 2026).

At the microbenchmark level, ZipFlow surpasses nvCOMP by $32\ \mathrm{GB/s}$9 in decompression throughput for a representative bit-packed column (L_PARTKEY, approximately 25-bit compressed). For Group-Parallel RLE decompression, ZipFlow consistently outperforms nvCOMP across 14 count-array distributions. For ANS, ZipFlow tunes chunk size so that it both matches or surpasses nvCOMP’s compression ratio and achieves higher decompression throughput across different input sizes (Yeo et al., 9 Feb 2026).

On TPC-H columns, the reported nested schemes are strongly data-type-specific. For date columns, dictionary encoding plus bit-packing is strongly effective, and nvCOMP cannot use dictionary encoding. For numeric columns, Float2Int plus bit-packing achieves better ratios and higher GPU decompression speeds. For almost monotonic keys such as O_ORDERKEY, DeltaStride + Delta + RLE + Bitpacking obtains high compression ratios. For O_COMMENT, the paper reports a custom dictionary built by tokenizing on spaces and periods, yielding 1,878 unique words; indices are bit-packed to 12 bits and then compressed with ANS (Yeo et al., 9 Feb 2026).

The file-level and query-level results are central. ZipFlow reduces file-level data movement overhead by $2.08$0 relative to nvCOMP. Fusion improves decompression by $2.08$1 for Dictionary + Bitpack, $2.08$2 for Float2Int + Bitpack, and $2.08$3 for RLE + Bitpack. In the end-to-end TPC-H study, noCOMP is dominated by PCIe transfers at about $2.08$4 of total time; nvCOMP cuts PCIe overhead by $2.08$5; and ZipFlow cuts PCIe overhead by $2.08$6. Overall, ZipFlow reports $2.08$7 average speedup over nvCOMP, $2.08$8 average speedup over DuckDB, and $2.08$9 average speedup over SQL Server across all 22 TPC-H queries (Yeo et al., 9 Feb 2026).

6. Relation to adjacent systems, limitations, and outlook

ZipFlow is positioned against GPU compression libraries, CPU-centric compression planners, and prior GPU query systems. Relative to nvCOMP, it provides a pattern-based abstraction and a compiler that can generate and tune kernels for a wider set of algorithms, including dictionary encoding, Float2Int, String-dictionary, and DeltaStride, while also enabling flexible nesting and cross-stage fusion beyond what Cascaded can express. Relative to CPU systems such as DuckDB, BtrBlocks, and Parquet with zstd, it reorients algorithm and nesting choices toward GPU-friendly decompression and PCIe-limited regimes rather than CPU decompression throughput alone (Yeo et al., 9 Feb 2026).

A useful point of contrast is the earlier system "ZipLine: In-Network Compression at Line Speed," which targets in-network compression and decompression inside a programmable switch pipeline on Intel/Barefoot Tofino with P4$3.14$0, using generalized deduplication, Hamming codes, and the Tofino CRC unit to achieve line-rate operation (Vaucher et al., 2021). ZipFlow operates in a fundamentally different setting—CPU–GPU compressed data movement for analytical workloads—yet both systems place compression design under tight hardware constraints and organize the solution around hardware-efficient primitives rather than general-purpose compression. This suggests a broader methodological commonality across heterogeneous systems research: compression becomes practical when the algorithmic form is chosen to match the execution substrate.

The limitations stated for ZipFlow are specific. Compression is mainly offline and decompression online; online compression for intermediate results is not addressed. Decompression is fused with decompression-only kernels but not with query operators such as decode-then-filter in a single pass. The evaluated design is PCIe-centric and does not implement NVLink or multi-GPU routing. The paper also does not present a fully formalized global cost model over $3.14$1, and it does not provide a fully automated GPU-aware compression planner analogous to BtrBlocks (Yeo et al., 9 Feb 2026).

The future directions indicated in the paper include integrating query-operator fusion with decompression, extending the framework to NVLink and multi-GPU topologies, building a full-fledged planner that searches nested algorithms using ZipFlow’s primitives and cost models, and applying the approach to other workloads such as large-scale machine learning feature pipelines and scientific data analysis. A plausible implication is that ZipFlow’s principal long-term significance lies less in any single codec and more in its attempt to make compressed data movement a compiler-managed, architecture-aware optimization problem (Yeo et al., 9 Feb 2026).