Decoding billions of integers per second through vectorization

Abstract

SUMMARYIn many important applications-such as search engines and relational database systems-data are stored in the form of arrays of integers. Encoding and, most importantly, decoding of these arrays consumes considerable CPU time. Therefore, substantial effort has been made to reduce costs associated with compression and decompression. In particular, researchers have exploited the superscalar nature of modern processors and single-instruction, multiple-data (SIMD) instructions. Nevertheless, we introduce a novel vectorized scheme called SIMD-BP128? that improves over previously proposed vectorized approaches. It is nearly twice as fast as the previously fastest schemes on desktop processors (varint-G8IU and PFOR). At the same time, SIMD-BP128? saves up to 2 bits/int. For even better compression, we propose another new vectorized scheme (SIMD-FastPFOR) that has a compression ratio within 10% of a state-of-the-art scheme (Simple8b) while being two times faster during decoding.

On Inverted Index Compression for Search Engine Efficiency

“…Yan et al [9] analysed the compression ratio and decompression speed of many schemes while dealing with the compression of doc ids and term frequencies extracted from the GOV2 corpus using the AOL query log dataset. A similar work has been done by Lemire et al [10], studying the codecs behaviour for the ClueWeb09 corpus, but focusing just on document ids. While dealing with smaller datasets, Delbru et al [11] provided a comparison of codecs integrating these into an actual search engine with positional information.…”

“…In the Rice codec [22], b is a power of two, which means that bitwise operators can be exploited, permitting more efficient implementations at the cost of a small increase in the size of the compressed data. Nevertheless, Golomb and Rice coding are well-known for their decompression inefficiency [7,10,23], and hence, we omit experiments using these codecs from our work. Simple family: This family of codecs, firstly described in [23], stores as many integers as possible in a single word.…”

“…OptPFD [9] works similarly, but chooses b to optimise the compression ratio and the decompression speed. FastPFOR [10], instead, reserves 32 different areas of its output to store exceptions. Each area contains those exceptions that can be encoded using the same number of bits.…”

“…However, for small postings lists (and the remainder of each posting list) with less than 1024 elements, block sizes can be smaller, but no less than 128 elements [9]. For blocks smaller than 128, (P)FOR codecs have to fall back to other codecs: we use variable byte as per [10]. Table 3.…”

“…Moreover, they did not consider other posting payload information, such as field frequencies and positions, nor did they investigate how codecs behave on different corpora. On the other hand, while Lemire et al [10] did investigate compression codecs on both the GOV2 and ClueWeb09 corpora, they were focused only on docid compression, and did not analyse the impact on search engine efficiency in terms of query response time. Finally, while Delbru et al [11] integrated different compression codecs into an actual IR system with document ids, term frequencies and positional information, their experiments with synthetically generated queries do not necessarily reflect a realistic search engine workload.…”