Compression and Searches with Modern Processors - Practice ... · Compression and Searches with...

Compression and Searches with Modern Processors - Practice and Implementation -

1

20120530 NTT Innovation Center

Takeshi Yamamuro

Today Outline

• Introduce Myself

• What’re Modern Processors?

– 最近のCPUの特徴/傾向や，その界隈の話

• Succinct Data Structure

– 基礎的な話と，2値のrank/select辞書

• Compression

– 整数列圧縮

– 文字列圧縮

• Searches

– 整数探索

2

Introduce Myself

• 名前

– 山室健 / Takeshi Yamamuro

• 所属

– Innovation Center, NTT lab.

• 研究分野

– データ工学 / データベース周辺技術

• PostgreSQL

• 探索，圧縮，並び替え

– Modern Hardware（CPU/GPU*1）によるアルゴリズム性能改善

Twitter: maropu

*1 今日はGPUの話題は出しません 3

Current Work in NTT Lab.

• PostgreSQL SQL/MED技術の研究開発 [PGMED][Ala12]

– （非Relationalな）外部データをSQLで操作するための技術

– 対象データ: CSV/TSV/JSON等

• コミュニティとの連携

– 新機能の拡充

– バグ修正

• 研究的観点

– 外部データ上の索引技術

– 圧縮技術の適用

※http://www.ntt.co.jp/cclab/activity/category_6/b_product_04.htmlから引用 4

What’re Modern Processors?

5

Hardware-aware Algorithms

• DB分野では’99年以降メモリ⇔CPU間の最適化が流行

– アルゴリズムや条件でin-memoryでも10～100倍の性能差

• 近年の傾向: 参照データ領域 < メモリサイズ

– メモリサイズの拡大と価格低下が原因

• 2012年の10のトレンド「in-memory Computing」

– Gartner Inc.による報告

– http://japan.cnet.com/news/business/35009907/

P. A. Boncz et al.: Database architecture optimized for the new bottleneck: Memory access, VLDB’99 (VLDB 10 years best paper)

6

Performance Gap by Access Patterns

• in-memory上のアクセスパタンと応答性能の関係

※2010年発売のCPU Xeon 5670を使用 7

Modern Processors

http://pc.watch.impress.co.jp/docs/news/20110406_437701.htmlから引用

Multi-core CPUs

http://newsroom.intel.com/docs/DOC-2152から引用

Many-core Architecture

コア数の増加傾向は変わらず - ’11年発売のXeon E7は10コア + HT （論理20コア）

命令の高機能化 - SIMD命令，文字列処理/ビット演算処理

x86命令が直接実行可能なHW - スレッド（pthread等）を利用して並列化

Intel CPUとソケット互換に - 写真はPCI外部接続だが現行版はMB上に装備

8

Optimization for Modern Processors

• Ninja Gap [Intel12]

– Intel Parallel Computing Lab.*1からのWhite Paper

– アルゴリズムのCPU最適化有無での性能差に関する調査

– 平均的に24Xの性能差（最大で53X程度）

• 様々なタスクを用い評価（ソート，探索や多体問題）

• 考慮するべき5つ（+α）のCPU特性観点

– 1. キャッシュ/DTLB

– 2. 分岐排除

– 3. メモリバンド帯域

– 4. CPU/コア間の同期性能

– 5. SIMD命令（SSE/AVX） http://pcl.intel-research.netから引用

*1 主にIntel CPU上の高効率なアルゴリズムの研究に従事している研究所（アメリカとインドの2拠点） 9

CPU Tips: 1. Cache/DTLB Penalties

• データR/WのCachelineとTLB（Translation Look-aside Buffer）

• CPU内の処理速度に比べデータのR/Wは非常に遅い

– CachelineとTLBの観点でデータ参照の局所性を考慮

ex.) Penalty cycles of cache/DTLB misses [IntelMan] - Sandy Bridge->DTLB: 7, L1 Data: 4, L2 unified: 12, LLC: 26-31

CPU

・・・

Cache・データ

0x0000H

0x0200H

0x0400H

0x0600H

0x0000H

0x0200H

0x0000H

Cacheline単位（64～256B）の

データブロックで転送

仮想メモリ空間

実メモリ空間 TLB・データ

0x0000H→0x0200H 0x0400H→0x0000H Page単位（4KiB～）

で入れ替え

10

CPU Tips: 1. Cache/DTLB Penalties

• 具体例: 索引木のノードサイズ決定問題 [Han03]

– ノードを小さくし過ぎると木が高くなりDTLBがボトルネックに

• 木探索のペナルティP(x)の推定*1

– H(x): 木の高さを表す関数

– SZとPはCachelineとPageのサイズと入れ替えコスト

ノードサイズx

木の高さH(x)

)()()( pgpgclcl PSZxPSZxxHxP

*1 ここではキャッシュとDTLBによるペナルティのみ考慮 11

CPU Tips: 2. Branch Penalties

12

if-then分岐によるペナルティ赤実線だけに注目（横軸: 分岐確率）

※[Zuk06]のFigure 4から引用

• x86/64系のCPUは分岐予測ミスのペナルティが高い [Zuk06]

• Xeon vs. Itanium

– ペナルティ特性は大きく異なる

– Xeonは比べ分岐確率が均等

の時にペナルティ最大に

CPU Tips: 3. Memory-Bandwidth

• メモリバンド帯域のボトルネックは深刻

– CPUコア当たりに使用可能な帯域は年々減少 [Rel08]

– 処理のスケーラビリティの阻害要因

• 参照するメモリ領域は最小に

– [Chh08][Sat10][Kim9, 10, 11, 12][Yam12]...

年代

コア当たりのメモリバンド

可能使用量（

GiB

/# o

f co

res)

2005 2008

※[Rei08]のFigure 2から引用 13

CPU Tips: 4. Synchronization Performance

• CPUやCPU内コア数の増加に伴い同期ペナルティは大

• 最近のCPUの同期性能

– 同一のメモリアドレス上にある値を同期インクリメント

– https://github.com/maropu/lockbench

1.0E-01

1.0E+00

1.0E+01

1.0E+02

1.0E+03

1 2 4 8 16 32

Thro

ugh

pu

ts

(co

un

ts p

er

clo

ck)

# of threads

X5260 (1, 2, Non-HT) X5570 (2, 4, HT) X5670 (1, 6, HT) Core i5-2500 (1, 4, Non-HT)

※CPU名の右括弧内は（# of CPUs, # of Cores, HT Capability）の意

14

CPU Tips: 4. Synchronization Performance

More information here ...

15

CPU Tips: 5. SIMD Instruction (SSE/AVX)

• CPUには特定用途に用いられる命令が実装 [IntelMan]

– SIMD命令，文字列処理/ビット演算処理

• Intel SSE/AVXによるSIMD命令

– 128/256-bitの単/倍精度浮動小数演算，128-bitの整数演算

– 加減算の並列命令や，水平演算/Shuffling

• Intel SSE4.2（Nehalem以降）に実装された命令 – 文字列高速比較命令: pcmpXstrY

http://www.slideshare.net/herumi/sse42

– ビット演算処理: popcnt

http://www.slideshare.net/takesako/x86x64-sse42-popcnt

16


• Intel SSE2によるSIMD加算のcode snippet – gccに-msse2オプションを加えてコンパイル

#include <stdio.h> #include <emmintrin.h> int main(int argc, char **argv) { int src[4] __attribute__((aligned(16))) = {1, 1, 1, 1}; int dst[4] __attribute__((aligned(16))); __m128i a = _mm_loadu_si128((__m128i *)src); __m128i b = _mm_set_epi32(1, 1, 1, 1); __m128i c = _mm_add_epi32(a, b); _mm_storeu_si128((__128i *)dst, c); ... return 0; }

SSE2用のヘッダファイル

ロード

ストア

加算

17


• 2013年に256-bitのSIMD演算を実装したAVX2のサポート

– 現在仕様は確定済み [IntelAVX]

– そのためiccやgcc-4.7.0では既に実行バイナリを生成可能

http://software.intel.com/file/36945から引用

マニュアル（約600p）

18


• 文字列処理命令（pcmpXstrY）の評価

– 単語数のカウンティング

• wdcnt_naive: Cによる標準的な実装

• wdcnt_intel: [IntelMan]に記載されている最適化実装

• wdcnt_opt: SSE4.2の命令を使用した実装

文字長 28 212 216 220 224

wdcnt_naive 80.67 64.71 66.08 66.29 66.08

wdcnt_intel 71.80 65.60 66.75 66.89 66.75

wdcnt_opt 8.07 4.17 3.71 3.16 3.08

※評価用実装はhttps://github.com/maropu/wdcnt_bench

19

各値は1単語をカウントするため要したCPUサイクル数（rdtsc）

CPU Tips: 6. Etc ... Instruction-Level Optimization

http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-optimization-manual.htmlから引用

実行コア - 実行可能な命令が異なる

命令スケジューラ - μ命令を各実行コアに振り分ける

• CPU最適化の極限: 命令レベルの高効率化 [IntelMan]

– 各実行コアの役割と性能（スループット/レイテンシ）

– 制御依存関係とOut-of-orderエンジン

20


• 具体例: Bitonic Sortにおける命令レベル分析 [Chh08]

min/max min/max min/max min/max



ソートされた整数列

A1 B4 A2 B3 A3 B2 A4 B1

minの出力 maxの出力

A1 A2 A3 A4

B1 B2 B3 B4

SIMDレジスタA

SIMDレジスタB

事前に昇順ソート済み

21






ソートされた整数列

A1 B4 A2 B3 A3 B2 A4 B1

minの出力 maxの出力

A1 A2 A3 A4

B1 B2 B3 B4

SIMDレジスタA

SIMDレジスタB

事前に昇順ソート済み

min max

suffle x2

min max

suffle x 2

min max

suffle x2

12個のSIMD 命令で並列ソート

22



※[Chh08]のFigure 7から引用

23



https://github.com/maropu/bitonic_sort 24


More information here ...

※ただし、2009年改訂の3rd editionからは除外 25

Succinct Data Structure

26

Succinct Data Structure

• 簡潔データ構造とは（Succinct Data Structure）・・・

– あるデータ集合Dを格納するデータ構造のこと

データ集合の例: ビット列 / 順序木 / 文字列…

• 簡潔データ構造=「簡潔データ表現」 + 「簡潔索引」 – 「簡潔データ表現」は対象データ集合Dの情報量下限（もしくはそれに近い値）の表現－情報量下限: 入力がL通り*1の場合にlog_L-bits

– 「簡潔索引」はデータ集合Dにおける操作（列挙や探索等）を明示的に展開せずにO(1)で実現するための補助的なo(log_L)のデータ構造

*1 入力データの出現確率は均等を仮定

結果的に，簡潔データ構造は(1 + o(1)) * Log_L-bitsで表現可能

27

Succinct Bit Sequence

• ビット列の簡潔データ構造が最も基本的で重要

– その他（順序木/文字列）の簡潔データ構造から利用

• ここではビット列に焦点を当てて紹介

– 「Compression:文字列圧縮」で文字列の簡潔データ構造を扱う

• その他の参考文献 – 去年のALSIP’11のInvited Talk3件

http://www-erato.ist.hokudai.ac.jp/alsip2011/program.html

– ERATO 田部井先生のブックマーク

http://www.ai-gakkai.or.jp/jsai/journal/mybookmark/26-6.html

28

Succinct Bit Sequence

• ビット列B[0, n), B[i]∈{0, 1}に対して以下の操作を実現

– lookupc(B, i): B[i]

– rankc(B, i): B[0...i)中のcの総数

– selectc(B, i): i番目のcの出現位置

[Oka11]のp.8から引用

29

Implementation of rank/select

• 密なビット列Bを仮定した実現方法

– 最もシンプルで重要なデータ構造

– n+o(n)-bitsで実現可能なGMMN*1の提案 [Cla96][Gon05]

– 様々な実装が現在利用可能（基本はGMMN） • rx-trie, http://code.google.com/p/mozc/

• marisa-trie, http://code.google.com/p/marisa-trie/

• wat-array, http://code.google.com/p/wat-array/

• 疎なビット列Bに対する圧縮手法

– ビット列Bを圧縮して，圧縮ビット列上でrank/selectを実現

– 整数列圧縮との連携/RECRANK/RRR/SDARRAY（説明は省略）

*1 略称は正式なものではなく[Fra08]を参考 30

Implementation of GMMN - rank

• Method of Four Russians

– 多段階で部分的な集約値を事前計算することでO(1)を実現

• rank1のための事前計算処理

– 1段目をサイズLSZ，2段目をサイズSSZのブロックに分割

– 1段目の事前計算: L[i] =rank1(B, i * LSZ)

– 2段目の事前計算: S[i]=rank1(B, i * SSZ) – rank1(B, i * SSZ / LSZ)

– 入力値（最大長はSSZ）のビット総数表を作成: P(X)

• rank1の計算

)),)/[((]/[]/[),(1 issiBPSSZiSLSZiLiBrank

31

Implementation of GMMN - rank

• 例: rank1計算 - LSZ=256bit & SSZ=32bitの場合

• 愚直に表を作成すると2SSZのエントリが必要

– 実装上は8bitに分割して計算

– Intel Nehaln以降ならSSE4.2 のpopcnt命令を利用可能 • 個人的にはメモリ参照する表引きよりもpopcntがおススメ

• 性能: http://www.slideshare.net/takesako/x86x64-sse42-popcnt

1 3 4 6 7 9 10 13

L[]:

S[]:

18

2 5 7 9 12 13 18 19 1 3 7 …

…

ビット列B: 01..000000....101......0 0110....001...............0 0000100 ...

256bit

32bit

rank1(B, 402=256*1+32*4+18)

21

残りのビット列は表引き

32

Implementation of GMMN - select

• selectの実装方法

– 1. O(1) select implementation

• rankと同様n+o(n)で実現可能 [Gon05]

– 2. O(log_n) select implementation

• rank/selectは逆関数関係

• rankを用いた2分探索で実現可能

• wat-arry/rx-trie/marisa-trieはこの方式を採用

– 個々の実装が細かな最適化を実施

http://www.scribd.com/doc/73565169/Lets-Impl-Sbv

• お勧めは2.の方法 – 適用サイズにもよるがo(n)のコストに対して改善が小さいため

33

Processor-Optimized Implementation of GMMN

• GMMNのrank/selectは参照改善は最重要 – 疎ビット列，文字列や順序木上の実装で利用されるため

– 私もrank/select性能問題で困っている・・・

• rank/select性能は参照Cacheline数に依存 – rankの場合，2段階の事前計算配列と表引きでランダムに4回参照

– O(log_n) selectの場合，ランダムに4 x log_n回参照

34


• Processor-Optimized rank implementation

– L以降は限定的な参照範囲を持つ

L[]:

S[]: …

…

ビット列B: 01..000000....101......0 0110....001...............0 0000100 ...

35


• Processor-Optimized rank implementation

– L以降は限定的な参照範囲を持つ

– LSZ=256bit & SSZ=32bitの場合はLがuint32_t/Sがuint8_t

– 以下のように配置すれば読み込みキャッシュライン数が1に

L[]:

S[]: …

…

ビット列B: 01..000000....101......0 0110....001...............0 0000100 ...

・・・ 0110....001....................0

64B Cache line

4B 1B 32B

48B Chunk

padding

36


• Processor-Optimized select implementation

– 1. 事前計算したL上を2分探索

• 整数探索の高速化手法などで高速化可能 [Kim10, 11]

– 2. SIMD命令を使用して8個まとめて比較

– 3. 残りのビット列は表引き

L[]:

S[]: …

…

ビット列B: 01..000000....101......0 0110....001...............0 0000100 ... 1. L上を2分探索

2. SIMDで比較

3. 表引き計算

※実際にはrank用にリアライメンとしたものを用いて探索

37

Compressed Bit Sequence - Integers Compression/RECRANK/RRR

38

Compressed Bit Seq.: Integers Compression

• ビット間隔長の整数列をγ/δ符号等で圧縮 [Kre10][Kre11]

• select(B, i * S)の対応する整数符号圧縮位置を記録 – Sはサンプリングパラメータ

– 任意の要素を効率的に参照するため

• この圧縮したビット列に対してrank/select辞書を作成

1 0 0 0 1 0 1 0 0 0 0 0 0 1 0 0 0 0 1 0 ... 0

4 2 7 5

γ符号列: 0 0 1 0 0 0 1 0 0 0 1 1 1 0 0 1 0 1

4 2 7 5

ビット列B:

39

Compressed Bit Seq.: Integers Compression

• ビット間隔長の整数列をγ/δ符号等で圧縮 [Kre10][Kre11]

• select(B, i * S)の対応する整数符号圧縮位置を記録 – Sはサンプリングパラメータ

– 任意の要素を効率的に参照するため

• この圧縮したビット列に対してrank/select辞書を作成

1 0 0 0 1 0 1 0 0 0 0 0 0 1 0 0 0 0 1 0 ... 0

4 2 7 5

γ符号列: 0 0 1 0 0 0 1 0 0 0 1 1 1 0 0 1 0 1

4 2 7 5

ビット列B:

S=2の場合

40

Compressed Bit Seq.: RECRANK

• 疎なビット列に対して0要素列を再帰的に間引くことで圧縮

• ビット列を固定長Sに分解して2つのビット列を作成

– Bc: 非0の固定長ブロック位置を記録

– Be: 非0ブロックを連結したビット列

ビット列B: 1 0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 ... 0

1 0 1 0 1 0 0 Bc:

Be: 1 0 0 1 0 0 0 1 0

（S=3の場合）

密なビット列になるまで再帰分解

41

Compressed Bit Seq.: RECRANK - rank

• 1回の分割に対するrank計算の変化

– rank1(B, i)の計算

• 圧縮効果と実性能観点で1回程度の分解でOK

– 再帰分割の度に圧縮改善量は低くなり，実性能も悪化

– 簡単に圧縮率を改善するためには再帰回数を増やすより固定長Sを調整したほうが良い（uint8_t/uint16_t/uint32_t）

)],/[),/((),( 111 ecc BSiBSBSirankrankiBrank

再帰分割T回に対してrank呼び出し回数が2Tに

42

Compressed Bit Seq.: RRR

• ’02年に提案された圧縮表現 [Ram02][Fra08]

• データ構造の概要

• 固定長uで分割して各ブロックR/S/Eを計算して保持

• R: 各ブロックの1の総数の列

• S: 1の総数が同じブロックグループ内での順位

• E: 各ブロックをR/S値の昇順で並び替えた数列（重複除去）

ビット列B: 1 0 0 0 0 0 0 1 1 0 0 0 0 0 0 1 1 0 0 1 0

整数列 R:

整数列 S:

1 0 2 0 0 2 1 1 0 0 0 0 1 0

[0 0 0] [0 1 0, 1 0 0] [0 1 1, 1 1 0] 整数列 E:

（u=3の場合）

43

Compressed Bit Seq.: RRR - rank

• i-bit目までのrank1の計算

• 1. 番目までのRのprefix-sumを計算

• 2. 番目のR/S値を用いEから番目のブロックを復元

• 3. 復元ブロックの先頭から番目までの1を数え上げ

• 4. 1.と3.の値の合計がi-bit目までのrank値

ui

ui

uiui

ビット列B*1: 1 0 0 0 0 0 0 1 1 0 0 0 0 0 0 1 1 0 0 1 0

整数列 R:

整数列 S:

1 0 2 0 0 2 1 1 0 0 0 0 1 0

[0 0 0] [0 1 0, 1 0 0] [0 1 1, 1 1 0] 整数列 E:

*1 実際にビット列Bは保存していない

rank1(B, 11=3*3+2)

ui

1. prefix-sumの計算

2. 対応ブロックの復元

3. 残りの1の数え上げ

44

Performance of Succinct Bit Sequence - GMMN/RECRANK/RRR/SDARRAY

45

Performance（rank & Compression Ratio）

[Fra08]のFig.1から引用

実験用のCPUがPentium4の3GHz（LLCミスが100-200cycle）から妥当な性能だが単体rank計算に約600clockは遅い

46



47



48

Performance（select & Compression Ratio）


49



50



51

Which Type of rank/select You Should Use?

• 基本的にはGMMNでOK – バグの少ない（はずの）公開ライブラリを使おう

• 「圧縮率>性能」の場合はビット密度を考慮

– 5%以下の場合はSDARRAY

– 10%前後の場合はRRR

– 20%を超える場合は慎重に検討 • ビットの出現分布が偏っている場合はRRR/RECRANKの効果有

52

Compression - 整数列圧縮 -

53

Integer Sequence Compression

• 負の歪度の出現分布をもつ整数列に対する圧縮手法

• 適用例

– もともと偏った分布を持つ整数列

– モデル変換による出現分布の調整

• Posting-listのURLソート [Yan09]，接尾辞配列のΨ配列変換 [Nav08]，N-gramの格納方式 [Ada11]，...

出現確率

1 2 3 4 5 6 ...

54

Two Type of Compression

• 1. 単体整数圧縮方式

– 小さい単体整数に少ないビットを割り当てる接頭符号化*1方式

– 例: VBytes，γ符号，δ符号，...

• 2. 整数ブロック圧縮方式

– 複数の整数をまとめて圧縮する方式

– CPU効率の観点では単体整数圧縮方式に比べ有利 • 分岐命令を極力排除した展開処理

• ワードアライメントの考慮

• 命令依存関係の少ないOut-of-Orderエンジンの効きやすい構造

– 例: Simple9/16，PForDelta，VSEncoder，...

*1 ハフマン符号のように全ての符号語が異なる接頭部もつように符号化すること

後ほど紹介

55

1. 単体整数圧縮方式の概要

• 個々の整数に異なるビットを割り当てる可変長方式

Ar[] = 1, 3, 2, 9, 1, 3, 7, 2, 2, 2, 23, 45, 1, 9, 5, 4, 8, 3, 1, 8, 8, 2, …

bit

-len

gth

可変長表現

56

1. 単体整数圧縮方式の概要

• 整数毎のヘッダから後続の必要ビット長を判断

– 後続のビット長判定のためのif-thenによる制御ハザード

– 非アライメント境界の参照によるペナルティ

・・・

ワードアライメント境界単体整数

先頭から読み込み順番に展開

メモリ上の配置例:

57

2. 整数ブロック圧縮の概要

• 複数整数のブロック単位でビット長を割り当てる方式 – 割り当てるビット長が変化するためブロックの分割方法が課題

bit

-len

gth

ブロック単位でビット長を決定

Ar[] = 1, 3, 2, 9, 1, 3, 7, 2, 2, 2, 23, 45, 1, 9, 5, 4, 8, 3, 1, 8, 8, 2, …

58

• 各ブロック毎のヘッダから後続の必要ビット長を判断

– アライメント境界参照であるため効率的

– 各ブロック内の整数復元は命令依存関係が少ない処理

メモリ上の配置例:

・・・

ワードアライメント境界

先頭から読み込み順番に展開

単体ブロック

2. 整数ブロック圧縮の概要

59

PForDelta [Zuk06]

• ’06年に提案されたブロック長を固定する方式

– 例えば128個や256個の固定ブロックで圧縮

• ブロック内の大半（ex. 95%）を表現可能なビット長を割り当て

– 割り当てビット長を超えた整数は例外領域に別途保存

Ar[]= 8, 3, 2, 38, 1,... , 5, 6, 2, 1, 5,... , 49,... ,1, 2, 9, ...

ブロック2 ブロック3 ブロック1

coded: 割り当てられたビットで表現可能な整数

exception: 割り当てビット長を超えた例外整数

60

※[Zuk06]のFigure 3から引用

PForDelta [Zuk06]

• PForDeltaのデータレイアウト

– 例外と判定された整数はポインタに置き換え

61

PForDelta [Zuk06]

• PForDeltaの展開アルゴリズム

codedのみを高速に展開

例外と判定された整数を『P』atchを適用するように展開 62

VSEncoder [Fab10]

• 動的計画法でブロック長を最適化する方式

• 各ブロック内の圧縮方法は任意のものを適用可能

– 固定長ビット表現，γ/δ符号，...

Ar[n]= 8, 3, 2, 38, 1, 2, 8, 5, 6, 2, 1, 5,... , 49,... ,1, 2, 9 ブロックs1 ブロックs2 ブロックsm ブロックsi

各ブロック長(l1, l2, ...)を

動的計画法で最適化

ブロックs3

l1=3 l2=4 l3=5

※ブロック数をm，各ブロック長をliとする

63

VSEncoder [Fab10]

• 圧縮後のサイズを表すVSE(Ar, s)関数を最小化するブロック分割順序集合s*の決定問題に還元 – Ar: 入力整数列

– s: ブロック分割の境界添え字を表す順序集合

1

1

* ))1]1[],[((minarg)),((minargm

iSsSs

isiscsArVSEs

ただし，c(x, y)はAr[x]からAr[y]の整数列の圧縮後サイズ

64

VSEncoder [Fab10]

• 動的計画法による解法

– 整数列長nに対して探索空間Sが指数的に増加（NP困難）

– 圧縮サイズの『部分構造最適性』に着眼

)),(][(min][)max,0max(

ijcjEiEijKj

E[j]: A[0]～A[j-1]までの最小圧縮サイズ

Ar[]= 8, 3, 2, 38, 1,... , 5, 6, 2, 1, 5,... , 49,... ,1, 2, 9, ...

i=1,2,..., maxK内で『E[j]+c(j,i)』を最小化するiを探索

部分最適構造の例:

※探索をmaxKに限定することで圧縮計算量がO(n*maxK)に 65

Compression Ratio and Speed

• 整数圧縮アルゴリズムの評価方法

– bpi（bit per integer）: 整数あたりの必要bit数

– mis（million integers per second）: 秒間あたりの展開整数

• 評価用コード – http://integerencoding.isti.cnr.it/

– Many thx, Rossano & Fabrizio in ISTI

• 評価用データ

– GOV2 Test Collectionを利用

• *.govのWebをクロールしたもの

66

Compression Ratio and Speed

0

500

1000

1500

2000

0

1

2

3

4

5

6

7

8

9

10

mis

: mill

ion

inte

gers

/ s

eco

nd

bp

i: b

it p

er

inte

ger bpi mis

単体整数圧縮手法整数ブロック圧縮手法

67

BETTER

BETTER

Compression - 文字列圧縮 -

68

LZEND: Compression with Random Accesses

• LZ77ベースの圧縮アルゴリズム [Kre10][Kre11]

– 任意の要素をO（M）で展開可能（要素長M）

– k次経験entropy [Man01]に漸近することを保証

• 従来の固定長で分割して任意要素を参照する手法との相違点

• 内部構造に簡潔データ構造を利用

• 簡潔データ構造の適用例

– ビット列，テキスト（シンボル）列，木構造，グラフ等今回はコレ

69

LZ77 & LZEND Parsing

• LZ77: ’77年に提案された圧縮アルゴリズム

– 先頭から順番に読み込み，過去の出現シンボル列のポインタ（一致位置/一致長/次の不一致記号）へ置換する方式

. . . . . . a p p l e . . . . a p p l e x . .

置換ポインタ（9, 5, x）

シンボル列:

現在の読み込み位置

過去出現シンボル位置

置換シンボル列

offset位置

70

LZ77 & LZEND Parsing

• LZEND: ’10年に提案された圧縮アルゴリズム

– 基本的なParsing方式はLZ77と同じだが，置換ポインタから一致長を除き代わりに一致長を表すビット列を追加

. . . . . . a p p l e . . . . a p p l e x . .


置換ポインタ（9, x）

シンボル列:

ビット列: . . . . . . . . . . . . . . . . 1 0 0 0 0 0 1 LZENDのKey Point: 次の不一致シンボル位置をビット列で記録



offset位置

71

Constant Time Access with LZEND

• 具体例（イメージ）: 任意位置からの参照

• 参照性能の課題: O（M）回のランダムアクセス

– メモリアクセス性能に依存した参照性能に

a p . . . . . _ _ p l e . . . . . . . _ _ _ _ _ x . . 圧縮シンボル列:

ビット列: 1 1 . . . . . . 0 0 1 1 1 . . . . . . . . 0 0 0 0 0 1

参照範囲

①対応する位置のビットが立っている場合は展開可能

※__ は置換されているシンボル

②再帰的に圧縮シンボルを展開

72

Code Snippet: Extract Sub-String

①対応する位置のビットが立っている場合は展開可能

②再帰的に圧縮シンボルを展開 73

LZEND: Parsing Issues

• 現在の読み込み位置を超えた自己参照置換ができない

– 読み込み位置前後に繰り返しパタンが存在する場合に発生

a b a b a b a b a b x . . . . . シンボル列:





offset位置

LZ77 Parsing

LZEND Parsing ‘ab’の繰り返しパタンに合致

74









offset位置

LZ77 Parsing

LZEND Parsing ‘ab’の繰り返しパタンに合致

75

自己参照置換領域




LZ77 Parsing

LZEND Parsing

76

(0, 0, a)(0, 0, b)(2, 8, x)... 置換シンボル列:

置換シンボル列: （ビット列は略）

自己参照置換ができるため LZENDより置換数が少ない

(0, a)(0, b)(2, a)(4, b)...

LZEND Implementation: liblzend

• LZENDをC++で実装したライブラリ

• 想定環境

– gcc >= 4.3.x

– sais （MIT/X11）: シンボル列探索用のSuffix Array構築ライブラリ

– wat-array （BSD）: RMQ（Range Maximum Query）用ライブラリ

• 実装上の特徴

– Sliding Windowによるポインタ置換

– 離散的なパタン探索

– ブロック単位のBW変換

– ビット列の圧縮

77

liblzend: Replacement with Sliding window

• 過去出現位置の探索範囲を限定

– offsetの値域を限定することによるサイズ削減

– 範囲限定による探索コスト削減

. . . . . . . . . . . . . . . . . . . . . . a p p l e x . .


シンボル列:

過去出現位置の探索範囲を限定

現在の限定範囲は64Kとして offset値はuint16_tで管理

offset位置

78

liblzend: Sparse Patten Matching

• 圧縮の高速化: 過去の出現パタン探索をスパースに実行

– 1回の出現パタンの判定のコストが高い

– 判定処理を間引く（判定間隔は現在決め打ち）

. . . a p p l e . . . . シンボル列:


元論文の密なパタン探索

実装の疎なパタン探索

79

liblzend: BW-Transformation in Blocks

• Burrows Wheeler変換

– シンボル列に対する可逆的な並び替え

– BWT後のシンボル列は非常に圧縮が行いやすい特徴

• 文脈情報を利用した圧縮手法

– BWT自体は圧縮手法ではないが原理的にはPPM（Context-based Compression）と同等

– 同じ文脈の直前には同じ文字が現れやすい傾向を利用

80


• 具体例: BWT前のシンボル列

86.500,12.0,0.0,1.500,0.0,0.0,14221312.0,57344.0,0.0,0.0,0.0,0.0,1141.0,523.0 86.0,14.0,0.0,0.0,0.0,0.0,5292032.0,10289152.0,0.0,0.0,0.0,0.0,1306.0,659.0 87.562,11.940,0.0,0.0,0.0,0.498,1114112.0,0.0,0.0,0.0,0.0,0.0,1085.0,458.0 81.0,12.0,6.0,1.0,0.0,0.0,1359872.0,0.0,0.0,0.0,0.0,0.0,1068.0,667.0 86.567,13.433,0.0,0.0,0.0,0.0,4554752.0,9306112.0,0.0,0.0,0.0,0.0,1334.0,640.0 86.432,12.563,1.005,0.0,0.0,0.0,598016.0,0.0,0.0,0.0,0.0,0.0,1116.0,620.0 48.756,1.493,49.751,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,1022.0,134.0 48.500,1.500,50.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,1033.0,169.0 49.749,1.508,48.744,0.0,0.0,0.0,0.0,0.0,9046.0,40534.0,0.0,0.0,1013.0,140.0 50.0,0.0,49.500,0.500,0.0,0.0,0.0,1908736.0,576.0,0.0,0.0,0.0,1083.0,175.0 68.500,11.0,20.500,0.0,0.0,0.0,1736704.0,0.0,0.0,0.0,0.0,0.0,1117.0,627.0 90.050,9.950,0.0,0.0,0.0,0.0,557056.0,0.0,0.0,0.0,0.0,0.0,1088.0,504.0 86.567,12.935,0.0,0.0,0.0,0.498,974848.0,0.0,5874.0,24958.0,0.0,0.0,1087.0,540.0 90.0,10.0,0.0,0.0,0.0,0.0,303104.0,0.0,0.0,0.0,0.0,0.0,1066.0,435.0 89.500,10.0,0.0,0.0,0.500,0.0,434176.0,0.0,0.0,0.0,0.0,0.0,1052.0,419.0 0.0,0.0,100.0,0.0,0.0,0.0,0.0,0.0,1518.0,9024.0,0.0,0.0,1012.0,135.0 0.0,0.0,99.010,0.495,0.0,0.495,0.0,393216.0,0.0,0.0,0.0,0.0,1076.0,172.0

81


• 具体例: BWT後のシンボル列（改行は除去）

00000000000000000100000000000000000400000000000000030000500000000000000000000050000000000000000000000000000000050000000000000000000000000000500000000000000003600900000000000000000280000027700000000000000000000000080300000000000000000000802954090583047950700000000064226640000006000042200400000006000000000000000044000000008000000100000000000020000000000000000000000000000800000006000000200000000000010022063003603014006206050810702600267468802019063100000010989861172668998219..................................................5.4...............00..........................0.....................................0........1...0...0.0..............0...0..........................0...............5....24445,,,,,,,,0,,,,,,,,,,1,,,,,,,,,,,,,,,,,,,,,,1,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,5,,,,,,,,,9,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,9,,,,2,,55555555551..11819132151790.147331115111915,814,,,,,10,,,,,,,,3,,,,,,,,,,,,,46,11111,03,,,0,,2,,,,,,11,,9021,1,,,454,637715113215115116,9230450,60536921381,190140940115347914177,430004123739165,113,1..,,73,,058,77,,...2..3099373890,..........,.71107,,0,54,70....5,,49,6,3575117,8746310888805,,5,,0,556301666281865185818.9.1.4.15090955486146449040090502416594844,,,1824,3..44.4,4455,

82

liblzend: Bit Sequence Compression

• ビット列Bは全体の30～40%占有するため圧縮が重要

• ビット列Bはuint32_t配列に格納

• 現在は配列要素が0のものを間引く圧縮手法を適用

– recrank[Oka06]から再帰圧縮処理を無くした実装

– 元論文はビット間隔をδ符号で圧縮

#define SetBit(B, pos) B[pos / 32] = pos % 32

83

liblzend: Compression & Access Performance

• 評価に用いたliblzend Variants – lzend1: LZEND + BWT + Sparse PM

– lzend2: LZEND + BWT

– lzend3: LZEND + Sparse PM

– lzend4: LZEND

• マシン環境 – Xeon 5670 2.93GHZ/16GiB/linux-3.1.0/gcc-4.6.2

• テストデータ（全て約100MiB） – PostgreSQL 9.1.3 source codes

– TREC .gov2

– pgbench_accountsをCSVでdump

– dstatの結果を—ouputで出力したCSV 84


• 圧縮率評価（値は圧縮率%）

LZEND1 BWT+Sparse

39.0 44.88 12.5 1.68

LZEND2 BWT

36.4 41.94 10.8 1.06

LZEND3 Sparse

39.8 42.70 24.2 18.1

LZEND4

35.5 37.39 15.8 8.00

PostgreSQL SC GOV2 DSTAT CSV PGBENCH CSV

gzip

20.4 22.0 8.43 2.92

bzip2

15.4 17.7 4.09 1.14

85


• 参照要素長を変化させた場合の性能評価（dstatのみ）

0.0

0.5

1.0

1.5

2.0

2.5

64 128 192 256 320 384 448 512

期待参照時間（

sec）

参照領域サイズ（KiB）

lzend1 (BWT+ Sparse) lzend2 (BWT) lzend3 (Sparse) lzend4

86


• 圧縮率/参照性能トレードオフ評価

0.0

0.1

0.2

0.3

0.4

0.5

0 0.1 0.2 0.3 0.4 0.5


sec）

圧縮率


Better Trade-off

87


• 圧縮率/参照性能トレードオフ評価

0.0

0.1

0.2

0.3

0.4

0.5

0 0.1 0.2 0.3 0.4 0.5


sec）

圧縮率


Better Trade-off

DSTAT

POSTGRESQL SC

GOV2

PGBENCH CSV

88

liblzend: Discussion

• 今回はマイクロベンチマークの評価

– 要約: CSV系のファイル圧縮率は○ / 参照性能が非常に悪い

• 今後の改善 / 評価の方向性

– 圧縮時間 / 圧縮率 / 参照性能の改善

• 圧縮時間: wat-arrayの改善

• 圧縮率: LZEND Parsingの課題解決，ビット列圧縮検討

• 参照性能: 再帰排除，ビット列参照性能改善，置換数制限等

89

Searches - 整数探索 -

90

整数探索と応用例

• 想定する処理

– 順序列（d1≦d2≦...≦dn）から任意の値を探索する処理

• 整数探索の高速化に用いられる一般的な構造

– 2分木，B木，...

12

48

68

7 20

ex. 2分木の例

参照が一様の場合分岐によるペナルティ大

NODE1

NODE3

NODE2

NODE4

NODE5

ポインタ利用の実装では jump毎にキャッシュ/DTLBミス

struct NODE { int compare_key; NODE *left, *right; } *node; …. if (search_key > node->compare_key) node = node->right; else node = node->left;

code snippet

91

Intel FAST [Kim10]

• CPUに最適化された整数探索用の高速なデータ構造

– ’10年のSIGMODのBest Paper Awardを受賞

• 使用している最適化手法

– 分岐排除を目的としたSIMD命令による差分移動

– 参照局所化を目的としたCacheline/Pageの再帰的ブロック化

int mask[4] __attribute__((aligned(16)));

__m128i __key1 = _mm_set_epi32(37, 78, 91, 0); __m128i __key2 = _mm_set_epi32(79, 79, 79, 79);

/* __key1と__key2の各要素の大小関係から0/1を返却 */

__m128i __mask = _mm_cmpgt_epi32(__key1, __key2);

/* mask = {1, 1, 0, 1} */ _mm_store_si128((__m128i *)mask, __mask);

32bitのSIMD比較命令 _mm_cmpgt_epi32

92

Intel FAST [Kim10]

[Yam12]のFig.1から引用

• FASTにおける分岐を排除した探索処理の例

93

Intel FAST [Kim10]


94

34 78 91 2 11 23 35 39 49 ・・・ 80 87 88

79 79 79

Consecutive area in memory （*__tree_data）

A search key （__skey）

1. Do _mm_cmpgt_epi32()

Intel FAST [Kim10]


95

34 78 91 2 11 23 35 39 49 ・・・ 80 87 88

79 79 79




Returned Values Offset Blocks

23 entry

A Lookup Table（rtable）

・・・

2. Check the lookup table

Intel FAST [Kim10]


96

34 78 91 2 11 23 35 39 49 ・・・ 80 87 88

79 79 79




Returned Values Offset Blocks

23 entry

A Lookup Table（rtable）

・・・

2. Check the lookup table

3. Move to the next SIMD block

VAST-Tree [Yam12]

• CPU最適な整数探索用の圧縮データ構造

– FASTのデータ構造に圧縮を適用

• FASTに対する改善手法 – 比較キーの非可逆圧縮によるSIMD命令の並列度向上

– 葉の位置に存在するキー列の圧縮

• 型サイズの異なるSIMD比較命令の利用 – _mm_cmpgt_epi32，_mm_cmpgt_epi16，_mm_cmpgt_epi8

97

VAST-Tree [Yam12]

• VAST-Treeのデータ構造概要

– P16とP8領域の比較キーを16bitと8bitにそれぞれ圧縮

98

VAST-Tree [Yam12]

• Prefix/Suffix bit-truncationの適用 [Bay77][Gra11]

– 領域毎に16bitと8bitの部分キー（partial keys）を生成

• 低い確率で大小関係の反転が発生 – エラーチェックと探索位置の修正処理は最後に実施

99

VAST-Tree [Yam12]

• VAST-Treeは葉圧縮の適用有無で評価

– 圧縮手法はP4Deltaを利用

• 圧縮適用後でもスループット性能はFASTと同等以上

– 総比較キー*1のサイズはFASTに対して5%以下

*1 葉を除いたデータ構造のサイズ 100

Today Summary / Suggestion

• CPU最適化を中心とした（私の興味のある）話題

– 整数と文字列それぞれの探索と圧縮

– Hardware最適化はDB分野でReviewerの反応が良い

• 最適化と移植性（汎用性） [Intel12]

– CPU最適化をやりすぎると魔術的なコードに

• ex. 高速な倍精度指数関数expの実装*1

– 最低限，参照局所性の考慮は必要

• 性能とCPUコアのスケーラビリティの観点で

• Cache-Conscious Succinct Trie [Otta12]は良い論文

*1 http://www.slideshare.net/herumi/exp-9499790 101

References

• 1. [Nav08] Navarro, G. and Makinen, V.: Compressed full-text indexes, Journal ACM Computing Surveys, 2008

• 2. [Intel11] Kim, C. et al: Designing fast architecture-sensitive tree search on modern multicore/many-core processors, Journal ACM TODS, 2011

• 3. [Intel12] Kim, C. et al: Closing the Ninja Performance Gap through Traditional Programming and Compiler Technology, Intel whiter paper, 2012

• 4. [Yam12] Yamamuro, T. et al: VAST-Tree: A Vector-Advanced and Compressed Structurefor Massive Data Tree Traversal, Proceedings of EDBT, 2012

• 5. [Kre10] Kreft, S. and Navarro, G.: LZ77-Like Compression with Fast Random Access, Proceedings of DCC, 2010

• 6. [Kre11] Kreft, S. and Navarro, G.: Self-Index Based on LZ77, Proceedings of 22nd CPM, 2011

• 7. [Fra08] Claude, F. and Navarro, G.: Practical rank/select queries over arbitrary sequence, Proceedings of 15th SPIRE, 2008

• 8. [Oka11] Daisuke, O.: Succinct Data Structure for Analyzing Document Collection, ALSIP 2011

• 9. [Cla96] Clark, D.: Compact Pat Trees, Ph.D thesis, Univ. of Waterloo, 1996

• 10. [Gon05] Gonzalez, R. et al.: Practical implementation of rank and select queries, In Posters WEA, p27-38, 2005

102

References

• 11. [Ram02] Raman, V. et al: Succinct indexable dictionaries with applications to encoding k-ary trees and multisets, In Proceedings of SODA, 2002

• 12. [PGMED] http://wiki.postgresql.org/wiki/SQL/MED • 13. [Ala12] Alagiannis, I. et al.: NoDB: Efficient Query Execution on Raw Data Files, In

Proceedings of SIGMOD, 2012 • 14. [IntelMan] Intel 64 and IA-32 Architectures Software Developer Manuals,

http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html

• 15. [Chh08] Chhugani, J. et al.: Efficient Implementation of Sorting on Multi-Core SIMD CPU Architecture, In Proceedings of VLDB, 2008

• 16. [Rel08] M. Reilly: When multicore isn’t enough: Trends and the future for multi-multicore systems, In HPEC, 2008

• 17. [Kim10] Kim, C. et al: FAST: fast architecture sensitive tree search on modern CPUs and GPUs, In Proceedings of SIGMOD, 2010

• 18. [Kim11] Kim, C. et al: Designing Fast Architecture Sensitive Tree Search on ModernMulti-Core/Many-Core Processors, ACM TOD, 2011

• 19. [Kim12] Kim, C. et al: CloudRAMSort: Fast and Efficient Large-Scale DistributedRAM Sort on Shared-Nothing Cluster, In Proceedings of SIGMOD, 2012

• 20. [Rei08] Reilly, M.: When multicore isn’t enough: Trends and the future for multi-multicore systems, HPEC'08

103

References

• 21. [Kim09] Kim, C. et al: Sort vs. Hash Revisited: Fast Join Implementation on • Modern Multi-Core CPUs, In Proceedings of VLDB, 2009 • 22. [Sat10] Satish, N.: Fast sort on CPUs and GPUs: a case for bandwidth oblivious SIMD

sort, In Proceedings of SIGMOD, 2010 • 23. [Zuk06] Zukowski, M. et al.: Super-Scalar RAM-CPU Cache Compression, In

Proceedings of IEEE ICDE, 2006 • 24. [Han2003] Hankins, R. A. and Patel, J. M.: Effect of node size on the performance of

cache-conscious b+-trees, In Proceedings of SIGMETRICS, 2003 • 25. [Man01] Manzini, G.: An analysis of the Burrows-Wheeler transform, Journal of

ACM, vol.48, pp.407-430, 2001 • 26. [Yan09] Yan, H. et al.: Inverted index compression and query processing with

optimized document ordering, In Proceedings of WWW conference, 2009 • 27. [Ada11] Pauls, A. and Klein, D.: Faster and Smaller N-Gram Language Models, In

Proceddings of ACL, 2011 • 28. [Fab10] Fabrizio, S. and Rossano, V.: VSEncoding: efficient coding and fast decoding

of integer lists via dynamic programming, In Proceedings of CIKM, 2010 • 29. [Bay77] Bayer, R. and Unterauer, K.: Prefix B-trees, ACM Transactions on Database

Systems, 1977 • 30. [Gra11] Graefe, G: Modern B-tree Techniques, Foundationsand Trends in Databases,

2011

104

Compression and Searches with Modern Processors - Practice ... · Compression and Searches with...

Documents

Transcript of Compression and Searches with Modern Processors - Practice ... · Compression and Searches with...