Archive-Name: editor-faq/sed Posting-Frequency: irregular Last-modified: 10 March 2003 Version: 015 URL: http://sed.sourceforge.net/sedfaq.html Maintainer: Eric Pement (pemente@northpark.edu) CONTENTS 1. GENERAL INFORMATION 1.1. Introduction - How this FAQ is organized 1.2. Latest version of the sed FAQ 1.3. FAQ revision information 1.4. How do I add a question/answer to the sed FAQ? 1.5. FAQ abbr
他の方が書いていますが、メモリが高価だった(というか大容量メモリが無かった)時代の話です。 実メモリが4MBしかないとして、OS含めて20MBのメモリを必要とするプログラムを動かしたいとします。そうすると、差し引き最低16MBのスワップ領域が必要です。この場合だと、実メモリの4倍ですね。こういうケースでは一応動くにしてもページングが多発して実用に耐えない速度になり、もしくはOSの動作も不安定になります。 この、「ページングが多発して実用に耐えない速度」の目安が実メモリの2倍という経験値です。つまり、実メモリが4MBしかないなら、せいぜいスワップ8MBで合計12MB位の仮想メモリしかそのコンピュータでは使えない(20MBのメモリを必要とするプログラムは動かせない)ということです。 今の時代だと、必要仮想メモリをすべて実メモリでまかなえるならスワップ領域は必要ありません。いくら大きく定義しても
先日、Bloom Filter を利用して重複部分をフィルタすることで処理を簡潔にする、という記事を書きました。実際、3, 4秒の改善が図れたということも書きました。でも、普通の設計方法では、std::setより遅くなります。ご注意ください。 原因は、2つあります。ハッシュ値の計算 (std::string → size_t) が遅い。ハッシュ関数の個数が多い。std::set は、平衡二分木で実装されています。dblp.xml 内の著者数は、だいたい72万なので木の高さは19くらいになります。一方で、Bloom filter では、false positive probability を1%にするとハッシュ関数の個数は7、0.1%にすると10程度になります。std::setでの「最大19回の分岐処理」と Bloom filter での「いつも10回ハッシュ値計算」だと、totalでみて前
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く