Hatena::ブログ(Diary)

ny23の日記 このページをアンテナに追加 RSSフィード

2010-06-11 流行りにのってみる

追記: sort を使うときは,LC_ALL=C を忘れずに

|  追記: sort を使うときは,LC_ALL=C を忘れずにを含むブックマーク  追記: sort を使うときは,LC_ALL=C を忘れずにのブックマークコメント

> wc --lines unigram_raw.txt 
290768333 unigram_raw.txt

そもそも,たかだか3億要素,1.7Gのデータのソートに,最近のマシンで

sort | uniq -c

が858分もかかるのは変ですよね.

> export LC_ALL=C
> time sort -S 2G unigram_raw.txt | uniq -c  > tmp.sort.uniq
sort -S 2G unigram_raw.txt  389.93s user 16.32s system 99% cpu 6:49.61 total
uniq -c > tmp.sort.uniq  15.40s user 1.56s system 4% cpu 6:49.62 total

Intel Xeon E5462 (3.2Ghz) が Dual Core AMD Opteron 1210 より 100倍以上速い,わけはなく,LC_ALL環境変数とsortコマンド - sileのブログにある通り,LC_ALL を C にせずに実行している可能性が高そう(手元で LC_ALL=C しないで sort すると,文字列の比較に失敗して落ちるので違うかも知れないけど).誰も変だと思わないのはちょっと危険なのでエントリで取り上げてみる.

export LC_ALL=C

と打つだけで >100 倍ですよ(流石にこれは言い過ぎか).LC_ALL がシェル全体で有効になるのが嫌なら,

> time LC_ALL=C sort -S 2G unigram_raw.txt | LC_ALL=C uniq -c > tmp.sort.uniq.utf8
LC_ALL=C sort -S 2G unigram_raw.txt  376.42s user 15.87s system 98% cpu 6:39.86 total
LC_ALL=C uniq -c > tmp.sort.uniq.utf8  15.40s user 1.43s system 4% cpu 6:39.86 total

でも ok.

nokunonokuno 2010/06/12 18:29 ありがとうございます! どうもsortコマンドが遅すぎると思ってたところです。
ソートがO(n log(n))といったってlog(n)で400倍も遅くなるわけないし、と…

ny23ny23 2010/06/12 19:25 単語頻度のカウントに使う場合,100倍とまで行かなくても,手元で試した限り,10倍程度は変わりそうな感じでした.
これで解決されると良いですね.