違い：LZ77対LZ4対LZ4HC（圧縮アルゴリズム）？
LZ77およびLZ78アルゴリズムを理解しています。 LZ4 here および here について読み、 code for it を見つけました。
これらのリンクは、LZ4ブロック形式について説明しています。しかし、誰かが説明できる（または、私に何らかのリソースを説明するように指示する）ことができれば素晴らしいと思います。
- LZ4とLZ77の違いは何ですか？
- LZ4HCとLZ4の違いは何ですか？
- LZ4HCアルゴリズムをこれほど高速にするアイデアは何ですか？
LZ4 は、コアあたり数百MB/sで高速に圧縮するように構築されています。非常に安価な圧縮が必要なアプリケーションに適しています。たとえば、ネットワークまたはディスク上のフォーマットをよりコンパクトにしようとしていますが、圧縮に大量のCPU時間を費やすことはできません。たとえば、 snappy と [〜＃〜] lzo [〜＃〜] のファミリーに属します。
自然な比較ポイントはzlibの DEFLATEアルゴリズム です。これは LZ77 および Huffmanコーディング を使用し、gzip、.Zipおよび.PNG形式などで使用されます。カウントする他の場所。
これらの高速コンプレッサーは、次の理由で異なります。
- 彼らはより高速な繰り返し検出コードを使用します（多くの場合、衝突検出のない単純な hashtable ）が、最適なものを見つけるために複数の可能な一致を検索しません（時間がかかりますが、圧縮率が高くなります）。短い一致が見つかりません。
- 入力の繰り返しを圧縮しようとするだけです。他のバイトより一般的なバイトを利用しようとはしません。
- 2に密接に関連し、ビットではなく、一度に1バイトの出力を生成します。バイト単位のコードを許可すると、より多くの圧縮が可能になる場合がありますが、エンコードおよびデコードするためにより多くのCPU操作（潜在的にビットシフトおよびマスキングと分岐）が必要になります。
- 多くの実践的な作業が、最新のCPUでの実装の高速化に費やされています。
比較すると、DEFLATEはより良い圧縮を取得しますが、 [〜＃〜] lzma [〜＃〜] 、 bzip2 、 [〜 ＃〜] lzham [〜＃〜] 、または brotli はさらに時間がかかる傾向があります（ただし、 Brotliはより高速な設定でzlibと競合できます ）。高圧縮アルゴリズムにはさまざまなバリエーションがありますが、概して、長距離で冗長性をキャプチャし、コンテキストを利用して可能性のあるバイトを決定し、よりコンパクトだが遅い方法で結果をビットで表現する傾向があります。
LZ4HCはLZ4の「高圧縮」バリアントであり、上記のポイント1を変更します。コンプレッサーは現在と過去のデータの間で複数の一致を検出し、出力が小さいことを確認するために最適な一致を探します。これにより、圧縮比が改善されますが、LZ4と比較して圧縮speedが低下します。ただし、解凍速度は害になりません。そのため、一度圧縮して何度も解凍し、ほとんどの場合非常に安価な解凍が必要な場合、LZ4HCは理にかなっています。
SSDや高速データセンターリンクによって提供される帯域幅のように、高速コンプレッサーでも1つのコアで大量の帯域幅を飽和させることはできないことに注意してください。 一時的にデータをRAM にパックするために使用されることがある、より低い比率のより高速なコンプレッサーもあります。 WKdm および Density は2つですそのようなコンプレッサー;彼らが共有する1つの特徴は、個々のバイトではなく、一度に4バイトマシンワードの入力に作用します。 SamsungのExynosチップ または IntelのQuickAssistテクノロジー のような圧縮。
LZ4よりも圧縮するが、deflateよりもCPU時間の少ない圧縮に興味がある場合、LZ4の作者（Yann Collet）は Zstd というライブラリを作成しました。安定版リリースでは、 Facebookがその使用方法について投稿しました 。エントロピー符号化には、ハフマン符号ではなく 有限状態マシン を使用します。私はこの分野の専門家ではありませんが、少なくとも アルゴリズムはRFCで詳細に説明されています 。 zstdの最速モード は、比率と速度がLZ4に近づいています。 Appleは同様の原理で lzfse を書きました。数年前、Googleは gipfeli と呼ばれるライブラリを公開しましたが、あまり取り上げられなかったようです。トラクション： [〜＃〜] slz [〜＃〜] や CloudFlareとIntelによるzlibへのパッチ など、Zlib形式での高速圧縮を目的としたプロジェクトもあります。
最速のコンプレッサーと比較して、これらの「ミディアム」パッカーはエントロピーエンコーディングの形式を追加します。つまり、いくつかのバイトがより一般的であることを利用します。より一般的なバイト値の出力に含まれるビットの数を減らします。
合計CPU時間ではなくレイテンシが主な関心事であり、1つの長いストリームを圧縮する場合、 pigz およびzstdコマンドの-Tスレッドオプションなどの圧縮を並行して実行するツールがあります。ラインツール。 （ さまざま 実験的 packers もありますが、現在使用するためではなく、速度や密度の限界を押し広げるために存在しています。）
したがって、一般的に、さまざまなアプリ用のかなりの範囲の代替コンプレッサーがあります：リアルタイム圧縮用のLZ4（またはより弱いメモリコンプレッサー）、バランス圧縮の古い標準としてのDEFLATE、積極的に開発された新しい代替品としてのZstd、およびbrotliとその他の高圧縮用。 LZ4からDEFLATEを介してbrotliに移行すると、データを予測およびエンコードし、ある程度の速度を犠牲にしてより多くの圧縮を取得するための努力が重ねられます。
余談ですが、brotliやzstdのようなアルゴリズムは、一般的にgzipを上回ることができます-特定の速度でより良く圧縮するか、同じ圧縮をより高速に取得できます-しかし、これは実際にはzlibが何もしなかったためではありません。むしろ、zlibは1995年にリリースされ、当時のハードウェアに対して適切な選択を行いました。たとえば、32KBの履歴ウィンドウは、RAM cost 3,000倍以上の場合に意味がありましたまた、今日のCPUは、操作が安価/高価なバランスをいじっています、例えば、予測が困難な分岐は今日では大したことであり、多くの演算を行うことは比較的安価です。