NVIDIA のCUDA ライブラリを使用して、標準の圧縮方法 (Zip、GZip、BZip2、LZMA など) を実装するプロジェクトを知っている人はいますか?
多くの並列タスク (圧縮など) を利用できるアルゴリズムは、デュアルまたはクアッドコア CPU よりもグラフィックス カードではるかに高速に実行されないのではないかと考えていました。
このようなアプローチの長所と短所についてどう思いますか?
NVIDIA のCUDA ライブラリを使用して、標準の圧縮方法 (Zip、GZip、BZip2、LZMA など) を実装するプロジェクトを知っている人はいますか?
多くの並列タスク (圧縮など) を利用できるアルゴリズムは、デュアルまたはクアッドコア CPU よりもグラフィックス カードではるかに高速に実行されないのではないかと考えていました。
このようなアプローチの長所と短所についてどう思いますか?
ロスレスデータ圧縮アルゴリズムのパフォーマンスを向上させるための研究の第1段階を終了しました。プロトタイプにはBzip2が選択され、私たちのチームは1つの操作(Burrows–Wheeler変換)のみを最適化し、いくつかの結果が得られました。優れた圧縮可能ファイルで2倍から4倍の速度が得られました。コードは、すべてのテストでより高速に動作します。
bzip2を完了し、HTTPトラフィックやバックアップ圧縮などの実際のタスクでdeflateとLZMAをサポートします。
ブログリンク: http: //www.wave-access.com/public_en/blog/2011/april/22/breakthrough-in-cuda-data-compression.aspx
誰かがそれを行って公開したことを認識していません。私見ですが、あまり有望には思えません。
Martinus が指摘しているように、一部の圧縮アルゴリズムは非常にシリアルです。LZW のようなブロック圧縮アルゴリズムは、各ブロックを個別にコーディングすることで並列化できます。ファイルの大規模なツリーの圧縮は、ファイル レベルで並列化できます。
ただし、これらはいずれも実際には SIMD スタイルの並列処理 (Single Instruction Multiple Data) ではなく、大規模な並列処理ではありません。
GPU は基本的にベクトル プロセッサであり、数百または数千の ADD 命令をすべてロック ステップで実行し、データに依存する分岐がほとんどないプログラムを実行できます。
一般に、圧縮アルゴリズムは SPMD (Single Program Multiple Data) または MIMD (Multiple Instruction Multiple Data) プログラミング モデルに似ており、マルチコア CPU により適しています。
ビデオ圧縮アルゴリズムは、CUDA のような GPGPU 処理によって高速化できるのは、並行してコサイン変換または畳み込み (モーション検出用) を行う非常に多数のピクセル ブロックが存在し、IDCT または畳み込みサブルーチンを表現できる場合のみです。ブランチレスコードで。
GPU は、高い数値強度 (メモリ アクセスに対する数学演算の比率) を持つアルゴリズムも好みます。数値強度が低いアルゴリズム (2 つのベクトルの加算など) は、大規模な並列化と SIMD を実行できますが、CPU よりも GPU での実行が遅くなります。メモリバウンドです。
通常、圧縮アルゴリズムは並列タスクを利用できません。アルゴリズムを高度に並列化するのは簡単ではありません。あなたの例では、TAR は圧縮アルゴリズムではありません。ブロック圧縮アルゴリズムであるため、高度に並列化できる唯一のアルゴリズムは BZIP です。各ブロックは個別に圧縮できますが、これには大量のメモリが必要になります。LZMA も並列では動作しません。7zip が複数のスレッドを使用している場合、これは 7zip がデータ ストリームを 2 つの異なるストリームに分割し、それぞれが別のスレッドで LZMA で圧縮されるためです。したがって、圧縮アルゴリズム自体は並列ではありません。この分割は、データがこれを許可する場合にのみ機能します。
暗号化アルゴリズムはこの分野で非常に成功しているので、それを調べてみるとよいでしょう。CUDA および AES 暗号化に関連する論文は次のとおりです。http://www.manavski.com/downloads/PID505889.pdf
30%は良いのですが、バックアップのようなアプリケーションの場合、長い目で見れば十分ではありません。
私の経験では、このような場合の平均データストリームは、gzipを使用して1.2〜1.7:1の圧縮を取得し、最終的に30〜60Mb / sの出力レートに制限されます(これは、さまざまな最新(2010〜2012年頃)のメディアにまたがっています) -ハイエンドCPU。
ここでの制限は通常、データをCPU自体に供給することができる速度です。
残念ながら、LTO5テープドライブを満足させるには、約160Mb / sの生の(圧縮できない)データレートが必要です。圧縮可能なデータが供給される場合、さらに高速なデータレートが必要になります。
LTO圧縮は明らかにはるかに高速ですが、やや非効率的です(gzip -1と同等-ほとんどの目的には十分です)。LTO4ドライブ以降には、通常、これらの種類の速度を維持できるAES-256暗号化エンジンが組み込まれています。
これが私の場合に意味することは、それを価値があると考えるために、400%以上の改善が必要だということです。
同様の考慮事項がLAN全体に適用されます。30Mb / sでは、圧縮はGbクラスのネットワークの妨げになります。問題は、ネットワークと圧縮のどちらに多くを費やすかです... :)
bzip2 の CUDA への移植を試みています。:) これまでのところ (大まかなテストしか行っていません)、Burrows-Wheeler Transform はシリアル アルゴリズムよりも 30% 高速です。http://bzip2.github.com