4

P2 (Panasonic) カードにある非常に大きなファイルを扱っています。私たちが採用しているプロセスの一部は、最初にコピーしようとしているファイルのチェックサムを生成し、次にファイルをコピーし、次にファイルに対してチェックサムを実行して、コピーが正常に行われたことを確認することです。問題は、ファイルが大きく (70 GB 以上)、完了するまでに時間がかかることです。最終的に何千ものこれらのファイルを処理することになるため、これは問題です。

System.Security.Cryptography.MD5CryptoServiceProvider を使用する以外に、チェックサムを生成するより高速な方法を見つけたいと思います。特殊なハードウェア カードを使用することを意味するかどうかは気にしません。現在のように表示できるように、プロセスがどこまで進んだかについてフィードバックを提供するエンコード方法が必要です。

アプリケーションは vb.net で書かれています。アプリケーション内でコンポーネント、ライブラリ、参照として使用できるようにしたいのですが、チェックサムの生成速度が十分に向上する場合は、外部アプリケーションを呼び出しても構わないと思っています。

言うまでもなく、チェックサムは一貫していて正確でなければなりません。:-)

お時間とご尽力いただき、誠にありがとうございました。

リチャード

4

2 に答える 2

2

このプロセスを高速化する方法の 1 つとして、コピーの実行前ではなく、コピーの実行中にソース ファイルの MD5 を計算する方法が考えられます。これにより、ファイル全体を読み取る必要がある回数が 3 回 (ソース ハッシュ、コピー、宛先ハッシュ) から 2 (コピー、宛先ハッシュ) に減ります。

このすべての欠点は、(System.IO.File.Copy に依存するのではなく) 独自のコピー コードを作成する必要があることです。 3 ステップのプロセスよりもとにかく終了します。

それ以外は、プロセス全体が設計によって I/O バウンドであるため、ここでできることはあまりないと思います。ほとんどの時間をファイルの読み取り/書き込みに費やしており、100MB/秒 (一般的な SATA ドライブのかなりの I/O 速度) でも、最高で約 5.8GB/分を実行します。

最新のプロセッサでは、MD5 (またはその他のもの) を計算するオーバーヘッドはあまり考慮されないため、高速化しても全体的なスループットは向上しません。特に暗号化アクセラレータは、ドライバーの実装が非常に効率的でない限り、外部カードにデータを供給するために必要なコンテキスト スイッチにより、節約できるよりも多くのオーバーヘッドを追加するため、ここでは役に立ちません。

改善したいのは、I/O 速度です。.NET フレームワークは、この点に関しては既にかなり効率的ですが (適切なサイズのバッファー、重複した I/O などを使用)、最適化されたネイティブ Windows アプリケーションの方がパフォーマンスが向上する可能性があります。私のアドバイス: Googleでいくつかのネイティブな MD5 電卓を探して、現在の .NET 実装と比較してみてください。ハッシュ計算速度の差が 10% を超える場合は、上記の外部アプリを使用することに切り替える価値があります。

于 2010-03-17T06:12:48.167 に答える
1

正解は、MD5 を使用しないことです。MD5 は、特定の暗号化機能を提供するように設計された暗号化ハッシュ関数です。偶発的な破損を検出するだけでは、過度に設計されており、時間がかかります。多くのより高速なチェックサムがあり、その設計は、エラーの検出と訂正に関する文献を調べることで理解できます。いくつかの一般的な例はCRCチェックサムで、CRC32 は非常に一般的ですが、MD5 ハッシュよりもはるかに高速に 64 ビットまたは 128 ビット、またはさらに大きな CRC を比較的簡単に計算することもできます。

于 2010-03-18T01:18:38.900 に答える