疑問の尽きない話？
疑問の尽きない話２ - himadatenodeの日記を見て、自分の理解度が怪しく思えたので、再度2005-10-22を読み返して、自分の中での再確認をしたうえで反応してみる。*1
で、ソフトページフォールトとかハードページフォールトなる小難しい話が続いてるわけですが、結局どうも単に別の場所に書き写しているという感じがしないでもない。
ページフォールトは Working Set 上にない Memory を探しにいくことです。 ソフトページフォールトは Working Set 上にはないが、物理 Memory 上に存在する場合のページフォールト。ハードページフォールトは Working Set 上になく、物理 Memory 上にもなく、HDD 上に存在する場合のページフォールトです。 ソフトページフォールト・ハードページフォールトの違いを考え出すと混乱するかもしれません。
別の場所に書き写しているだけと考えて、大きな間違いはないと思います。
Firefoxの場合使用していると何故かどんどんメモリ使用量が増えるという問題があるようなのでメモリ使用量が問題になるわけだけど、実際には解放せずに別のところに置いているだけならば、使っているうちにドンドコ使用メモリが増えている問題は解決していないような気がしたので。
物理 Memory 使用量 ( ≒ Working Set ) が増えると問題がでますが、実際に物理 Memory 上に確保されていない Memory 使用量は増えてもそれほど問題にならないと思います。
なので、最小化で 物理 Memory 使用量は減るので確かに問題解決にはなります。ただ、それが本当に Plus であるかは疑問です。これについては昨日書いたものを参照。
これは恐らく "Working Set" の値を見ておられるのだと思いますが，実際これは Firefox のメモリ空間の内どれだけ物理メモリに残すかという OS 側の目標値が減少しただけで，(追記:最小化時には) Firefox はメモリの解放どころか何もしていないと考えられます
おそらく Firefox は本当に何もしていないでしょう ( 何もしない部分を変更するための設定を解説したサイトが最初に紹介されていたサイトです )。ただ、OS 側が Working Set を小さくすることで物理 Memory 使用量が減った場合、動作速度が変化する可能性は十分にあると思います。( OS 側の目標値が減少しただけで の部分です )
結論( ? )
- Firefox の Memory 使用量: 物理 Memory 上にある・ないを考慮しない Memory 使用量は減っていないと思います
- 物理 Memory 使用量が減ると速くなることもありますし遅くなることもあります、これは昨日書いたとおりです
疑問解決に役に立てればうれしいのですが……
Memory 使用量
疑問の尽きない話 - himadatenodeの日記 で、HDN の方が「減ってないんじゃないの？」と書いていらしたので、誤解されていないか少し不安になってきました。以前、私が書いたの記事を読むと、SetProcessWorkingSetSize() を『 Memory 使用量偽装関数』と解釈されてもおかしくないので、追記しておきます。( 注意 : 以下の文章は推測で書かれています。なので、不安な部分は語尾を「はずです」にしておきました。)
まず、最小化したとき、物理 Memory ( RAM ) 使用量は減っているはずです。
Windows は、最小化したときに「元に戻すまでは使わないだろう」と RAM 側の内容を HDD 側 ( Page File ) に書き出すはずです。確かに元に戻すまでは使用しないはずですし、そんな Application に RAM を使わせているのは勿体無い話ですからね。ただし、書き出してしまったものは、使うときには RAM 側に書き戻さなければいけません。なので、元に戻すときには少し時間がかかるはずです。
なにが言いたいかというと『何の目的もなく「RAM を使用しないことがいいことだ！」と HDD 側に書き出すことがいいこととは、私には思えない』ということです。
特に cltc の場合は速度を遅くされても嫌なので、できるなら RAM 側に存在してほしいのです。もし他の Application で必要なら Windows が勝手に cltc の使用している RAM 側から HDD 側に書き出してくれるはずです。それは cltc が考えるべきことではないはずです。なので、私は cltc で SetProcessWorkingSetSize() を使用していません。
Firefox で見ていない Page のために RAM が使用され、今見ようとしている Page の表示に時間がかかる、というのであれば、RAM -> HDD という方法もいいはずです。十分に RAM を積んでいるのであれば ( RAM の容量不足による速度低下が起きていないのであれば ) 、あまりそういう Memory 使用量については意識しない方がいいと、私は思います。
( 当然のこととして書いていませんが RAM と HDD なら RAM の方が読み書きが早いです。なので早く動作させたいなら情報は RAM においておくべきなんです。 )
laimen version 0.5 公開
laimen の version 0.5 を公開しました。
変更点は「 ESC でいつでも終了できる」と「 SPACE がきかないことがあるのを修正」です。
「こっそり遊べる Game がほしいのに、とっさに終了できないのは致命的」らしいです。 nigaim 同様 Play 中であっても ESC でいつでも終了できるようにしました。これで仕事中・授業中、存分に楽しめます。(あまりいいことではなさそうですが)
Title に戻ったとき SPACE がきかないことがあるみたいです。原因がよくわからないのですが、これかなと思う部分を修正してみました。
難易度の調節などはしていないので、Point は直接引き継いで問題ないと思います。
laimen version 0.1 公開 ( 初公開 )
今日は少し前に言っていたゲームが完成したので公開します。
名前は「laimen」 神経衰弱系へびゲーム です。
神経衰弱といえば、二枚のカードをめくって同じ数字であればそれを取り、そうでなければまた裏返し相手の番に、というあのゲームです。
へびゲームといえば、えさを食べるとしっぽが伸び、自分のしっぽや壁にあたると Game Over というあのゲームです。
laimen はへびゲームをベースに神経衰弱的な要素を加えました。
もっとも重要なことは「しっぽが見えない」ということです。へびゲームなのに、しっぽは見えません。いちばんうしろの一つは特別に見えますが、他は見えません。もちろん、見えなくてもあたると Game Over です。
次に重要なことは「壁もえさもない」ということです。壁もえさもありませんが、代わりにてきが出てきます。てきはえさと同じ扱いです。あたると、しっぽがのびます。てきはレーザで攻撃してきます。これはあたると Game Over です。
良ければ Download して、やってみてください。
ライブラリって偉大だなァ ( STL 初挑戦 )
昨日ここに書いた蛇ゲームの尻尾を STL の list と iterator を使って書き直してみました。
余計なものがなくなって、スッキリしました。*1「尻尾の先頭を指すポインタ」や「尻尾の個数」などを書く必要がなくなったからですね。すごくいいです。もうリストを自分で組む気にならないですね。( 通販ぽい口ぶりで )
他に、使ってみたいと思っているのは vector, string あたり。実行ファイルのサイズが大きくなってしまう以外に、欠点も見つからないので、これからは積極的に STL を使っていきたいです。
ただ、まだまだオブジェクト指向らしい書き方はできそうにないので、しばらくは better C でいきたいと思っています。
*1: 100 行程度のソースが80行程度まで小さくなりました。 かわりに実行ファイルのサイズが 20KByte 増です (笑)
