追記: sort を使うときは，LC_ALL=C を忘れずに - ny23の日記
> 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 totalIntel Xeon E5462 (3.2Ghz) が Dual Core AMD Opteron 1210
RE: sort を使うときは，LC_ALL=C を忘れずに - ny23の日記
Twitter ID も livedoor ID もないので直接コメントできないが，sort (GNU coreutils) の名誉のために，ここにメモしておく． 404 Blog Not Found:algorithm - bucketsort.[ch] - 汎用かつlibcの*sortより高速な まず第一印象として，この程度のサイズのファイルのソートで sort (GNU coreutils) がいまどきこんなに遅いはずはない．LC_ALL=C で追試すると，やはり bucketsort との差は無くなった．上の記事（に対するツイート）は Twitter 上でもそれなりにリツイートされているように見えるのだけど，この実行時間に違和感を感じる人が全くいないのはどういうことなのだろうか．sort を実際に使う人がほとんど見ていないのか，それとも計算量が違うから速くて当然という思い込みか．
動的ダブル配列を使って Wikipedia のテキスト処理を高速化 - ny23の日記
Wikipediaによるテキストマイニング入門など，Wikipedia 中の単語頻度を測るのが流行っているようだ．例えば，Hadoop を使ったり（Hadoop で Wikipedia のテキスト処理を900倍高速化 - 武蔵野日記），ハッシュを使ったり（Hadoopを使わずにWikipediaのテキスト処理を400倍高速化 - tsubosakaの日記Hadoopを使わずにWikipediaのテキスト処理を400倍高速化 - tsubosakaの日記）とか．情報系の人間なら普通はハッシュで十分と思うところ，折角なので動的ダブル配列を使って測ってみた．動的ダブル配列から保存された文字列を効率的に取り出すには，ノードリンクを実装して traverse () を再帰的に呼び出せば良い．今回は MSD radix sort 用に sibling のリンクを昇順にしたバージョン（僅かに追加速度が低
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
