CPU対応圧縮

かなり高速なネットワークを介して、あるコンピュータから別のコンピュータにデータを送信する必要があるとしましょう...たとえば、標準の100Mbit接続（〜10MB / s）。私のディスクドライブは標準HDDなので、速度は30MB / sから100MB / sの間です。そのため、その場でデータを圧縮することが役立つと思います。

しかし... CPUに制限されたくありません。CPUを集中的に使用するアルゴリズムを選択した場合、転送は実際には圧縮なしよりも遅くなります。

これは、GZIPやBZIP2などのコンプレッサーでは困難です。これは、通常、転送全体に対して一度圧縮強度を設定するためです。また、データストリームが時々簡単で、時々圧縮が難しいため、完全なCPUを使用しない場合があるため、プロセスが最適ではなくなります。また、帯域幅が十分に活用されていない場合もあります。

転送が最適になるように、現在のCPU /帯域幅に適応してスイートスポットに到達する圧縮プログラムはありますか？Linuxに理想的ですが、私はすべてのソリューションにまだ興味があります。GZIP / BZIP2デコンプレッサと互換性のあるものが見たいのですが、これは必須ではありません。

したがって、送信するバイト数だけでなく、総転送時間を最適化したいと思います。

また、リアルタイムの解凍は必要ありません...リアルタイムの圧縮で十分です。宛先ホストは、その空き時間に後でデータを処理できます。私はこれがあまり変化しないことを知っていますが（圧縮は通常、解凍よりもCPUに負荷がかかります）、この事実を使用できる解決策があれば、なお良いでしょう。

異なるデータを転送するたびに、これらの1回限りの転送を可能な限り迅速に実行したいのです。そのため、圧縮率が高いため、複数の転送を高速化するメリットはありません。

おかげで、

これは現在の研究テーマです。主にセンサーネットワークの領域で、スループットを最大化するのではなく、電力使用量を最小化することを目的としています。ただし、適応圧縮の原理は同じです。

これはUSCの教授からの最近の論文です。

たぶん、あなたは彼のアルゴリズムを実装することに挑戦できたでしょうか？良い実装に興味がある人はたくさんいると思います。

ええと、この質問は1年以上経過しているため、気付かれずに通過する可能性があります。

とにかく、Googleは最近、あなたが探しているものとまったく同じSnappyを公開しました。

[...]最大の圧縮、または他の圧縮ライブラリとの互換性を目的とするものではありません。代わりに、非常に高速で適度な圧縮を目指しています。たとえば、zlibの最高速モードと比較すると、ほとんどの入力でSnappyは桁違いに高速ですが、結果の圧縮ファイルは20％から100％大きくなります[...]

これはC ++で実装されており、Cおよびその他のさまざまな言語で使用できるバインディングがあります。