Accelerating Multigrid-based Hierarchical Scientific Data Refactoring on GPUs

Abstract

Rapid growth in scientific data and a widening gap between computational speed and I/O bandwidth makes it increasingly infeasible to store and share all data produced by scientific simulations. Instead, we need methods for reducing data volumes: ideally, methods that can scale data volumes adaptively so as to enable negotiation of performance and fidelity tradeoffs in different situations. Multigrid-based hierarchical data representations hold promise as a solution to this problem, allowing for flexible conversion between different fidelities so that, for example, data can be created at high fidelity and then transferred or stored at lower fidelity via logically simple and mathematically sound operations. However, the effective use of such representations has been hindered until now by the relatively high costs of creating, accessing, reducing, and otherwise operating on such representations. We describe here highly optimized data refactoring kernels for GPU accelerators that enable efficient creation and manipulation of data in multigrid-based hierarchical forms. We demonstrate that our optimized design can achieve up to 264 TB/s aggregated data refactoring throughput-92% of theoretical peak-on 1024 nodes of the Summit supercomputer. We showcase our optimized design by applying it to a large-scale scientific visualization workflow and the MGARD lossy compression software.

Optimizing Huffman Decoding for Error-Bounded Lossy Compression on GPUs

“…Compared with cuSZ and cuMGARD, cuZFP provides slightly higher compression throughput, but it only supports fixedrate mode [19], limiting its adoption in practice. Both cuSZ and cuMGARD use Huffman encoding to achieve high compression ratios and their decompression throughput is greatly limited by slow Huffman decoding on GPUs, but cuSZ has a much higher throughput than cuMGARD [38,5]. Thus, in this work, we focus on optimizing Huffman decoding for cuSZ.…”

“…SZ, ZFP, and MGARD were first developed for CPU architectures, and all started rolling out their GPU-based lossy compression recently. The SZ team, the ZFP team, and the MGARD team released their CUDA versions, called cuSZ [39], cuZFP [7], and cuMGARD [5], respectively. All the versions provide much higher throughputs for compression and decompression compared with their CPU versions [39,19,38].…”

“…These GPU versions can both accelerate the compression computation and reduce the time needed to transfer the data between the GPU and CPU after the compression. For example, both SZ and MGARD [1] have a GPU adaptation (known as cuSZ [39] and cuMGARD [5]), which have been implemented for GPU hardware, and more specifically Nvidia's CUDA platform.…”

Improving Energy Saving of One-sided Matrix Decompositions on CPU-GPU Heterogeneous Systems

“…As the type of processor that contributes the most of the computing parallelism in many current and future HPC systems, Graphics Processing Units (GPUs), equipped with thousands of low-power cores, offer high computational power and energy efficiency. Many applications and libraries have been designed and optimized for GPU accelerators [1,3,8,9,13,25,34,36,42,43]. Benefiting from the fact that GPUs are designed for highly parallelizable computations while CPUs are more efficient with serial computations, CPUs and GPUs that are linked through fast interconnections [30,31] are usually used together to form heterogeneous systems that can efficiently handle a large spectrum of scientific computing workloads.…”

FZ-GPU: A Fast and High-Ratio Lossy Compressor for Scientific Computing Applications on GPUs

“…Limitations of state-of-the-art approaches. Existing error-bounded lossy compressors for GPUs (such as cuSZ [14], cuZFP [15], and MGARD-GPU [16]) suffer from either low throughputs or low compression ratios. Specifically, although cuZFP has slightly higher throughput compared with cuSZ and MGARD-GPU, it supports only the fixed-rate mode [17], which suffers much lower compression quality than the fixed-accuracy mode (a.k.a error-bounded mode) [18], significantly limiting its adoption in practice.…”