#integer #compression #bitpacking

bitpacking

Fast integer compression/decompression via SIMD bit-packing. Port of simdcomp to rust.

10 releases (breaking)

0.8.0 Jul 10, 2019
0.7.0 Jun 26, 2019
0.6.0 Feb 4, 2019
0.5.1 Jun 26, 2018
0.1.0 Mar 18, 2018

#16 in Compression

Download history 333/week @ 2019-03-27 344/week @ 2019-04-03 177/week @ 2019-04-10 225/week @ 2019-04-17 177/week @ 2019-04-24 353/week @ 2019-05-01 332/week @ 2019-05-08 144/week @ 2019-05-15 216/week @ 2019-05-22 217/week @ 2019-05-29 187/week @ 2019-06-05 278/week @ 2019-06-12 261/week @ 2019-06-19 450/week @ 2019-06-26 207/week @ 2019-07-03

1,055 downloads per month
Used in 8 crates (2 directly)

MIT license

78KB
1.5K SLoC

Fast Bitpacking algorithms

Linux build status

This crate is a Rust port of Daniel Lemire's simdcomp C library.

It makes it possible to compress/decompress :

  • sequence of small integers
  • sequences of increasing integers

⭐️ It is fast. Expect > 4 billions integers per seconds.

How to compile ?

bitpacking compiles on stable rust but require rust > 1.27 to compile.

Just add to your Cargo.toml :

bitpacking = "0.5"

For some bitpacking flavor and for some platform, the bitpacking crate may benefit from some specific simd instruction set.

In this case, it will always ship an alternative scalar implementation and will fall back to the scalar implementation at runtime.

In other words, your do not need to configure anything. Your program will run correctly, and at the fastest speed available for your CPU.

Documentation

Reference documentation

What is bitpacking ?

Traditional compression schemes like LZ4 are not really suited to address this problem efficiently. Instead, there are different families of solutions to this problem.

One of the most straightforward and efficient ones is bitpacking :

  • Integers are first grouped into blocks of constant size (e.g. 128 when using the SSE2 implementation).
  • If not available implicitely, compute the minimum number of bits b that makes it possible to represent all of the integers. In other words, the smallest b such that all integers in the block are stricly smaller than 2b.
  • The bitpacked representation is then some variation of the concatenation of the integers restricted to their least significant b-bits.

For instance, assuming a block of 4, when encoding 4, 9, 3, 2. Assuming that the highest value in the block is 9, b = 4. All values will then be encoded over 4 bits as follows.

original number binary representation
4 0100
9 1001
3 0011
2 0010
... ...

As a result, each integer of this block will only require 4 bits.

Choosing between BitPacker1x, BitPacker4x and BitPacker8x.

⚠️ BitPacker1x, BitPacker4x, and BitPacker8x produce different formats, and are incompatible one with another.

BitPacker4x and BitPacker8x are designed specifically to leverage SSE3 and AVX2 instructions respectively.

It will safely fallback at runtime to a scalar implementation of these format if these instruction sets are not available on the running CPU.

👌 I recommend using BitPacker4x if you are in doubt.

BitPacker1x

BitPacker1x is what you would expect from a bitpacker. The integer representation over b bits are simply concatenated one after the other. One block must contain 32 integers.

BitPacker4x

BitPacker4x bits ordering works in layers of 4 integers. This gives an opportunity to leverage SSE3 instructions to encode and decode the stream. One block must contain 128 integers.

BitPacker8x

BitPacker8x bits ordering works in layers of 8 integers. This gives an opportunity to leverage AVX2 instructions to encode and decode the stream. One block must contain 256 integers.

Compressing small integers

extern crate bitpacking;

use bitpacking::{BitPacker4x, BitPacker};


// Detects if `SSE3` is available on the current computed
// and uses the best available implementation accordingly.
let bitpacker = BitPacker4x::new();

// Computes the number of bits used for each integers in the blocks.
// my_data is assumed to have a len of 128 for `BitPacker4x`.
let num_bits: u8 = bitpacker.num_bits(&my_data);

// The compressed array will take exactly `num_bits * BitPacker4x::BLOCK_LEN / 8`.
// But it is ok to have an output with a different len as long as it is larger
// than this.
let mut compressed = vec![0u8; 4 * BitPacker4x::BLOCK_LEN];

// Compress returns the len.
let compressed_len = bitpacker.compress(&my_data, &mut compressed[..], num_bits);
assert_eq!((num_bits as usize) *  BitPacker4x::BLOCK_LEN / 8, compressed_len);

// Decompressing
let mut decompressed = vec![0u32; BitPacker4x::BLOCK_LEN];
bitpacker.decompress(&compressed[..compressed_len], &mut decompressed[..], num_bits);

assert_eq!(&my_data, &decompressed);

Benchmark

The following benchmarks have been run on one thread on my laptop's CPU: Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz.

You can get accurate figures on your hardware by running the following command.

cargo +nightly bench --features unstable

BitPacker1x

operation throughput
compress 1.4 billions int/s
compress_delta 1.0 billions int/s
decompress 1.8 billions int/s
decompress_delta 1.4 billions int/s

BitPacker4x (assuming SSE3 instructions are available)

operation throughput
compress 5.3 billions int/s
compress_delta 2.8 billions int/s
decompress 5.5 billions int/s
decompress_delta 5 billions int/s

BitPacker8x (assuming AVX2 instructions are available)

operation throughput
compress 7 billions int/s
compress_delta 600 millions int/s
decompress 6.5 billions int/s
decompress_delta 5.6 billions int/s

Reference

Other crates you might want to check out

  • stream vbyte A Stream-VByte implementation
  • mayda Another crate implementation the same algorithms.

Dependencies