miyuriの日記: ファイル比較 11
日記 by
miyuri
ちょろっと大きなファイルの比較をする必要が出てきたようなので、テキトーに動かしてみた。
多分、どれもキャッシュから追い出してあるハズ。
GNU utilities for Win32のdiff: 3.4[MB/s]
高速ファイル比較ツール Ver1.03: 3[MB/s]
フォルダ内のファイル比較ツール: 6.5[MB/s]
バッファはソコソコ大きめに取ろうね、って感じ。
読込転送レートを100[MB/s]、シークタイムを10[ms]、とりあえず4[MiB]ずつ処理するとしてみる。
両方のファイルから4[MiB]読むのに大雑把に100[ms]掛かるから、40[MiB/s]、色々とテキトーに差し引いて、20[MiB/s]くらいは欲しい。
ハッシュを取って比べるなら、シークタイム分を幾らか抑えられる。FILE_FLAG_NO_BUFFERINGを立てておきたい。
他に適当なモノは有るかな。
2013-05-24 14:26
一致するか否かの検査、と書いた方が良かったかも。
2013-05-24 18:17
とりあえず、HashSumを勧めておいた。
使うツールを間違えてる (スコア:1)
「高速ファイル比較ツール」も「フォルダ内のファイル比較ツール」も完全一致か否かをチェックするツールのようですが、UNIX tools でそれに相当するのは diff ではなく cmp ですね。
自分とこの環境で、ちょっと試したところでは、cmp の方が diff よりも2倍ちょっと速かったです。
#まあ、diff はディレクトリ比較ができますけど、cmp には出来ないので、フォルダ中のファイル全比較、とかだと find を組み合わせる必要があってちょっと面倒ですが…
速度を気にするなんて (スコア:0)
いちばん気にするべきは誤差である。
間違いがあれば、どんなに速くても台無しである。
Re:速度を気にするなんて (スコア:2)
ハッシュを取るなら、そうだね。
単位時間当たりの検査量の比較は、全域の一致について調べている場合だけだよ。
VB6製が最速? (スコア:0)
VB6製が一番速いってなんかの間違いだろ?GNUはmingwだから遅くても納得だけど
Re: (スコア:0)
CPU命令の実行時間なんてディスクアクセスに比べたら誤差の範囲ってことをお前みたいな勘違い最適化厨に教えてるんだよ。
# ストレージはSSDじゃないのかな
一致のみでよければハッシュでいいじゃん (スコア:0)
Q6600 で HDD 上にある 4.7GB のファイル md5sum 取っても 53 秒しかかからなかったので
md5sum した結果を diff 取ると少なくとも上で挙げてるツールで直に比較する場合と比べて、少なくとも10倍くらい速いと思うんだ。
かけたい手間はどれぐらい?? (スコア:0)
あと、上り下りの速度差とか…
話を簡単にするために彼我でほぼ同じスペックのマシン、上り下りの速度差はなし、通信は全2重としよう。さらに通信回線を開く上での面倒はないとする。
まず最初にやるのは双方のファイルサイズとSHA1辺りのハッシュ値を取得して、それを比較。
違ってれば、ほぼこれで除去できる。
次に比較ファイルを前半1/2と後半1/2に分ける。厳密に1/2でなくてもよいが、彼我で同じポイントで分割しなくてはいけない。
で、それぞれについて「SHA1」を取り、それを「前半は自分側で」「後半は相手側で」比較する。
どちらか一方でも合致していなければ、それは違っている。
最後に「相手側の持っている前半部」を手元に、「自分側の持っている後半部」を相手側に送って、それぞれを diff とかで比較する。
「相手のデータをこちらに持ってくるだけ」や「こちらのデータを相手に持っていくだけ」のようなほとんど半二重に近い通信方式よりも、この方が効率が良い。
netcat (nc) と、bash の (command) 構文と、diff かcmp があれば実装できるはずだ。
すぐわかると思いますが、これは凄く面倒くさい。実装の手間と、待ち時間、どちらを取る?という問題になる。
Re:かけたい手間はどれぐらい?? (スコア:2)
ローカルにあるデバイス内のファイルのみなので、その辺の面白味は無かったという事で。
Re: (スコア:0)
物理ドライブが1つか2つかだけでもだいぶ違うよ。FastCopyは実際に同一ドライブと別ドライブで異なるアルゴリズムを採用してるし。
なんという情報弱者の群… (スコア:0)
あまりの酷さに開いた口が塞がらない
diff的なものでなくハッシュ値で十分な時点で、そこはmd5deep一択だろjk
md5deepなり、sha1deep、sha256deepなり好きなのチョイスして
$ md5deep -j -lr > list.txt
後は片割れも同じく取ってdiffかますなり、直に
$ md5deep -j 同じ -rX list.txt > result.txt 2>&1
-jが使えるかどうかが全て、単品ファイル当たりの読み込み速度なぞOSに任せて無視して良い
これ常識
むしろ老害の群 (スコア:0)
> -jが使えるかどうかが全て、
それってマルチコア時代になってからの常識だよね? コア数より多くのスレッド立てたらコンテキストスイッチの切り替えのオーバーヘッド分かえって遅くなるだけだし。
# 1プロセスのファイル読み込みだけではバスの帯域を使い切れないなら意味あるか。