This repository contains the command line tool rapidgzip, which can be used for parallel decompression of almost any gzip file. Other tools, such as bgzip, can only parallelize decompression of gzip files produced by themselves. rapidgzip works with all files, especially those produced by the usually installed GNU gzip. How this works can be read in the pugz paper or in the rapidgzip paper, which builds upon the former.

The Python module provides a RapidgzipFile class, which can be used to seek inside gzip files without having to decompress them first. Alternatively, you can use this simply as a parallelized gzip decoder as a replacement for Python's builtin gzip module in order to fully utilize all your cores.

The random seeking support is the same as provided by indexed_gzip, but further speedups are realized at the cost of higher memory usage thanks to a least-recently-used cache in combination with a parallelized prefetcher.

This repository is a light-weight fork of the indexed_bzip2 repository, in which the main development takes place. This repository was created for visibility reasons and in order to keep indexed_bzip2 and rapidgzip releases and packaging separate. It will be updated at least for each release. Issues regarding rapidgzip should be opened here.

Table of Contents

1. Installation
2. Performance
   1. Scaling Benchmarks on 2xAMD EPYC CPU 7702 (2x64 cores)
   2. Scaling Benchmarks on Ryzen 3900X
   3. Benchmarks for Different Compressors
   4. Benchmarks for Different Decompressors
3. Usage
   1. Command Line Tool
   2. Python Library
   3. Via Ratarmount
   4. C++ Library
4. Citation
5. About
6. Internal Architecture
7. Tracing the Decoder

Installation

You can simply install it from PyPI:

python3 -m pip install --upgrade pip # Recommended for newer manylinux wheels python3 -m pip install rapidgzip rapidgzip --help

Performance

Following are benchmarks showing the decompression bandwidth over the number of used cores.

There are two rapidgzip variants shown: (index) and (no index). Rapidgzip is generally faster when given an index with --import-index because it can delegate the decompression to ISA-l or zlib while it has to use its own custom-written gzip decompression engine when no index exists yet. Furthermore, decompression can be parallelized more evenly and more effectively when an index exists because the serializing window propagation step is not necessary.

The violin plots show 20 repeated measurements as a single "blob". Thin blobs signal very reproducible timings, while thick blobs signal a large variance.

Scaling Benchmarks on 2xAMD EPYC CPU 7702 (2x64 cores)

Decompression of Silesia Corpus

This benchmark uses the Silesia corpus compressed as a .tar.gz file to show the decompression performance. However, the compressed dataset is only ~69 MB, which is not sufficiently large to show parallelization over 128 cores. That's why the TAR file is repeated as often as there are number of cores in the benchmark times 2 and then compressed into a single large gzip file, which is ~18 GB compressed and 54 GB uncompressed for 128 cores.

Rapidgzip achieves up to 24 GB/s with an index and 12 GB/s without.

Pugz is not shown as a comparison because it is not able to decompress the Silesia dataset because it contains binary data, which it cannot handle.

Usage

Command Line Tool

```bash rapidgzip --help

Parallel decoding: 1.7 s

time rapidgzip -d -c -P 0 sample.gz | wc -c

Serial decoding: 22 s

time gzip -d -c sample.gz | wc -c ```

Python Library

Simple open, seek, read, and close

```python3 from rapidgzip import RapidgzipFile

file = RapidgzipFile("example.gz", parallelization=os.cpu_count())

You can now use it like a normal file

file.seek(123) data = file.read(100) file.close() ```

The first call to seek will ensure that the block offset list is complete and therefore might create them first. Because of this, the first call to seek might take a while.

Use with context manager

```python3 import os import rapidgzip

with rapidgzip.open("example.gz", parallelization=os.cpu_count()) as file: file.seek(123) data = file.read(100) ```

Storing and loading the block offset map

The creation of the list of gzip blocks can take a while because it has to decode the gzip file completely. To avoid this setup when opening a gzip file, the block offset list can be exported and imported.

```python3 import os import rapidgzip

index_path = "example.gz.gzindex"

with rapidgzip.open("example.gz", parallelization=os.cpucount()) as file: file.seek(123) data = file.read(100) file.exportindex(index_path)

with rapidgzip.open("example.gz", parallelization=os.cpucount()) as file: file.importindex(index_path) file.seek(123) data = file.read(100) ```

Open a pure Python file-like object for indexed reading

```python3 import io import os import rapidgzip as rapidgzip

with open("example.gz", "rb") as file: inmemoryfile = io.BytesIO(file.read())

with rapidgzip.open(inmemoryfile, parallelization=os.cpu_count()) as file: file.seek(123) data = file.read(100) ```

Via Ratarmount

rapidgzip is the default backend in ratarmount since version 0.14.0. Then, you can use ratarmount to mount single gzip files easily.

```bash base64 /dev/urandom | head -c $(( 4 * 1024 * 1024 * 1024 )) | gzip > sample.gz

Serial decoding: 23 s

time gzip -c -d sample.gz | wc -c

python3 -m pip install --user ratarmount ratarmount sample.gz mounted

Parallel decoding: 3.5 s

time cat mounted/sample | wc -c

Random seeking to the middle of the file and reading 1 MiB: 0.287 s

time dd if=mounted/sample bs=$(( 1024 * 1024 )) \ iflag=skipbytes,countbytes skip=$(( 2 * 1024 * 1024 * 1024 )) count=$(( 1024 * 1024 )) | wc -c ```

C++ library

Because it is written in C++, it can of course also be used as a C++ library. rapidgzip supports streaming of uncompressed data with a predefined buffer size, although small buffer sizes decrease performance.

In order to make heavy use of templates and to simplify compiling with Python setuptools, it is header-only. The license is also permissive enough for most use cases.

Rapidgzip can be added to an existing CMake project using FetchContent, or directly via add_subdirectory

An example CMake build using FetchContent can be found here.

Citation

A paper describing the implementation details and showing the scaling behavior with up to 128 cores has been submitted to and accepted in ACM HPDC'23, The 32nd International Symposium on High-Performance Parallel and Distributed Computing. The paper can also be accessed on ACM DL or Arxiv. The accompanying presentation can be found here.

If you use this software for your scientific publication, please cite it as:

bibtex @inproceedings{rapidgzip, author = {Knespel, Maximilian and Brunst, Holger}, title = {Rapidgzip: Parallel Decompression and Seeking in Gzip Files Using Cache Prefetching}, year = {2023}, isbn = {9798400701559}, publisher = {Association for Computing Machinery}, address = {New York, NY, USA}, url = {https://doi.org/10.1145/3588195.3592992}, doi = {10.1145/3588195.3592992}, abstract = {Gzip is a file compression format, which is ubiquitously used. Although a multitude of gzip implementations exist, only pugz can fully utilize current multi-core processor architectures for decompression. Yet, pugz cannot decompress arbitrary gzip files. It requires the decompressed stream to only contain byte values 9–126. In this work, we present a generalization of the parallelization scheme used by pugz that can be reliably applied to arbitrary gzip-compressed data without compromising performance. We show that the requirements on the file contents posed by pugz can be dropped by implementing an architecture based on a cache and a parallelized prefetcher. This architecture can safely handle faulty decompression results, which can appear when threads start decompressing in the middle of a gzip file by using trial and error. Using 128 cores, our implementation reaches 8.7 GB/s decompression bandwidth for gzip-compressed base64-encoded data, a speedup of 55 over the single-threaded GNU gzip, and 5.6 GB/s for the Silesia corpus, a speedup of 33 over GNU gzip.}, booktitle = {Proceedings of the 32nd International Symposium on High-Performance Parallel and Distributed Computing}, pages = {295–307}, numpages = {13}, keywords = {gzip, decompression, parallel algorithm, performance, random access}, location = {Orlando, FL, USA}, series = {HPDC '23}, }

About

This tool originated as a backend for ratarmount. After writing the bzip2 backend for ratarmount, my hesitation about reimplementing custom decoders for existing file formats has vastly diminished. And, while random access to gzip files did exist with indexed_gzip, it did not support parallel decompression neither for the index creation nor when the index already exists. The latter of which is trivial, when ignoring load balancing issues, but parallelizing even the index creation is vastly more complicated because decompressing data requires the previous 32 KiB of decompressed data to be known.

After implementing a production-ready version by improving upon the algorithm used by pugz, I submitted a paper. The review process was double-blind and I was unsure whether to pseudonymize Pragzip because it has already been uploaded to Github. In the end, I used "rapidgzip" during the review process and because I was not sure, which form fields should be filled with the pseudonymized title, I simply stuck with it. Rapidgzip was chosen for similar reason to pragzip, namely the P and RA are acronyms for Parallel and Random Access. As rapgzip, did not stick, I used rapidgzip, which now also contains the foremost design goal in its name: being rapidly faster than single-threaded implementations. Furthermore, the additional ID could be interpreted to stand for Index and Decompression, making "rapid" a partial backronym.

Internal Architecture

The main part of the internal architecture used for parallelizing is the same as used for indexed_bzip2.

Tracing the Decoder

Performance profiling and tracing is done with Score-P for instrumentation and Vampir for visualization. This is one way, you could install Score-P with most of the functionalities on Ubuntu 22.04.

Installation of Dependencies

Tracing

Results for a version from 2023-02-04

Comparison without and with rpmalloc preloaded