NvidiaのCUDAを使用した圧縮ライブラリ
NVIDIAの CUDAライブラリ を使用して、標準の圧縮方法（Zip、GZip、BZip2、LZMAなど）を実装するプロジェクトを知っている人はいますか？
多くの並列タスク（圧縮など）を利用できるアルゴリズムが、デュアルまたはクアッドコアCPUを使用するよりもグラフィックスカードで実行する方が速くならないのではないかと思いました。
そのようなアプローチの長所と短所についてどう思いますか？
誰もそれをしてそれを公開したことを知らない。ちょうど私見、それは非常に有望に聞こえません。
Martinusが指摘しているように、一部の圧縮アルゴリズムは高度にシリアルです。 LZWのようなブロック圧縮アルゴリズムは、各ブロックを個別にコーディングすることで並列化できます。ファイルの大きなツリーの圧縮は、ファイルレベルで並列化できます。
ただし、これらはどれもSIMDスタイルの並列処理（単一命令複数データ）ではなく、大規模な並列処理ではありません。
GPUは基本的にベクトルプロセッサであり、数百または数千のADD命令をすべてロックステップで実行でき、データ依存分岐が非常に少ないプログラムを実行できます。
一般的な圧縮アルゴリズムは、SPMD（Single Program Multiple Data）またはMIMD（Multiple Instruction Multiple Data）プログラミングモデルに似ており、マルチコアCPUに適しています。
ビデオ圧縮アルゴリズムは、CUDAのようなGPGPU処理によって、余弦変換または畳み込まれている（モーション検出のために）非常に多数のピクセルブロックが並列にある場合にのみ加速でき、IDCTまたは畳み込みサブルーチンを表現できます。ブランチレスコードで。
GPUは、数値の強度が高い（メモリアクセスに対する数学演算の比率）アルゴリズムも好みます。数値の強度が低いアルゴリズム（2つのベクトルを追加するなど）は、超並列およびSIMDになりますが、CPUよりもGPUでの実行が遅くなります。 'メモリバウンドです。
ロスレスデータ圧縮アルゴリズムのパフォーマンスを向上させるための研究の第1フェーズを終了しました。プロトタイプにはBzip2が選択され、チームは1つの操作（Burrows–Wheeler変換）のみを最適化しました。いくつかの結果が得られました。コードはすべてのテストで高速に動作します。
HTTPトラフィックやバックアップ圧縮などの実際のタスクのために、bzip2、deflate、LZMAをサポートします。
ブログのリンク： http://www.wave-access.com/public_en/blog/2011/april/22/breakthrough-in-cuda-data-compression.aspx
通常、圧縮アルゴリズムは並列タスクを利用できません。アルゴリズムを高度に並列化できるようにするのは簡単ではありません。あなたの例では、TARは圧縮アルゴリズムではなく、ブロック圧縮アルゴリズムであるため、高度に並列化できる可能性がある唯一のアルゴリズムはBZIPです。各ブロックは個別に圧縮できますが、これには大量のメモリが必要になります。複数のスレッドを使用する7Zipを見ると、LZMAは並行して動作しません。これは、7Zipがデータストリームを2つの異なるストリームに分割し、それぞれが別々のスレッドでLZMAで圧縮されるため、圧縮アルゴリズム自体が並列ではないためです。この分割は、データで許可されている場合にのみ機能します。
Bzip2をCUDAに移植しようとしています。 :)これまでのところ（そして大まかなテストのみが行われている場合）、Burrows-Wheeler変換はシリアルアルゴリズムよりも30％高速です。 http://bzip2.github.com
暗号化アルゴリズムはこの分野で非常に成功しているので、調べてみてください。 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のraw（非圧縮）データレートが必要です。圧縮可能なデータを供給する場合、さらに高速のデータレートが必要です。
LTO圧縮は明らかにはるかに高速ですが、やや非効率的です（gzip -1と同等-ほとんどの目的には十分です）。 LTO4以上のドライブには通常、AES-256暗号化エンジンが組み込まれており、これらの種類の速度も維持できます。
私の場合、これが意味することは、価値があると考えるためには400％以上の改善が必要だということです。
同様の考慮事項がLAN全体に適用されます。 30Mb/sでは、圧縮はGbクラスのネットワークの障害であり、問題はネットワーキングに費やすか圧縮に費やすかということです... :)