version:2.0.0[ruby-dev:45085]Descriptionあけましておめでとうございます。ビットマップマーキングGCをRuby2.0向けに作りました。無事に動いてることを確認してます。https://gist.github.com/1542547全体的に実行時間は若干遅くなるようです。マークでRVALUEのフラグを立てるだけだったのが、ビットマップ上のフラグを立てるようになるので遅くなるのはしょうがないかなと...。skkzipcodeビットマップマーキングではマークでRVALUEに対して書き込みがなくなるので、Linuxで複数の子プロセスを実行した場合にも無駄なCoWが発生せず、総メモリ使用量が少なくなるという利点があります。skkzipcodeというサンプルプログラムで上記の点を確認しました。生成した子プロセスで親プロセスと共有したデータを利用します。kbPROCESS_CNTは子プロセスの数、SHARED_TOTALは子プロセスで利用している共有メモリ量、PRIV_TOTALは私有メモリ量です。bmapの方が共有メモリを沢山使っていることがわかり、私有メモリ使用量も少なくなっています。実装について簡単にまとめます。heaps_slotをヒープブロックに埋め込んだLinuxでfork()を使わないようなプログラムに対してはビットマップマーキングの恩恵はありません。CRubyで並列プログラミングしようとするときにはfork()を使って云々するライブラリがけっこう多いので(例えばpassengerとか...)そういうものに対しては結構効くはずです。GCの実行時間もそれほど遅くなりませんので、fork()を使わないプログラムでもそれほど問題にならないと思っています。能特性はどうなるのかな。明示的なsweepが要らないぶんと割り当て時にスキャンが発生するのとのトレードオフかなあ。提案していた手法だと,「ビットマップ探索高速化|のため~」云々はあまり気にしなくていいんじゃないかと思ったんですが,そう|でもないでしょうか.memalignで直接ページが得られた方が、PROの手法よりビットマップテーブルを得るためのメモリアクセスが1段減って高速のはずです。ビットマップテーブル取得はオブジェクトごとに発生しますから効いてくるはずです。難しいかな.うーん、1.8と1.9の差の方が大きすぎて意味のある性能比較はムリでしょう。メモリ消費量比較くらいなら有意義な比較ができるかな。能特性はどうなるのかな。明示的なsweepが要らないぶんと割り当て時にスキャンが発生するのとのトレードオフかなあ。提案していた手法だと,「ビットマップ探索高速化|のため〜」云々はあまり気にしなくていいんじゃないかと思ったんですが,そう|でもないでしょうか.memalignで直接ページが得られた方が、PROの手法よりビットマップテーブルを得るためのメモリアクセスが1段減って高速のはずです。ビットマップテーブル取得はオブジェクトごとに発生しますから効いてくるはずです。難しいかな.うーん、1.8と1.9の差の方が大きすぎて意味のある性能比較はムリでしょう。メモリ消費量比較くらいなら有意義な比較ができるかな。能特性はどうなるのかな。明示的なsweepが要らないぶんと割り当て時にスキャンが発生するのとのトレードオフかなあ。メモリアクセスが減る(かもしれない)ので,実測値を知りたいところです.まぁ,そのへんは実装によると思いますが.その辺りはどうなんでしょう...。実装するのはそれほど難しくないので、試しに実装して計測してみます。実装的には、sweep時に解放対象のオブジェクトに対してはobj_free()を呼ぶだけ、flagsは0にしない、freelistも繋がない、スロットをsweepしたあとにbitmapをクリアしない、オブジェクトアロケーション時にbitmapスキャン、みたいなのを考えています。提案していた手法だと,「ビットマップ探索高速化|のため〜」云々はあまり気にしなくていいんじゃないかと思ったんですが,そう|でもないでしょうか.memalignで直接ページが得られた方が、PROの手法よりビットマップテーブルを得るためのメモリアクセスが1段減って高速のはずです。ビットマップテーブル取得はオブジェクトごとに発生しますから効いてくるはずです。.定量的な比較がもしあると説得力が増すと思いました.実装して比較してもよいですが、実装者の感覚としては調べるまでもないような気も...。難しいかな.うーん、1.8と1.9の差の方が大きすぎて意味のある性能比較はムリでしょう。メモリ消費量比較くらいなら有意義な比較ができるかな。はい,難しいと思います.が,何らかの指標があると,マーケティングには良さそうです.REEとメモリ消費量を比較したのがあったほうがいいかもしれませんね。passengerは面倒そうなので、まずはskkzipcodeを動かしてみます。気が進みません...。喋った話ですが).そうですね。それはいろんなGCを選択したいなぁ、という時にやらないといけないことだと思っています。さださんがおっしゃってる「うまいこと整理」のイメージがあまり湧いてないので、どういうものか例を上げてくれると想像しやすいです。wrote:その辺りはどうなんでしょう...。実装するのはそれほど難しくないので、試しに実装して計測してみます。実装的には、sweep時に解放対象のオブジェクトに対してはobj_free()を呼ぶだけ、flagsは0にしない、freelistも繋がない、スロットをsweepしたあとにbitmapをクリアしない、オブジェクトアロケーション時にbitmapスキャン、みたいなのを考えています。提案していた手法だと,「ビットマップ探索高速化|のため〜」云々はあまり気にしなくていいんじゃないかと思ったんですが,そう|でもないでしょうか.memalignで直接ページが得られた方が、PROの手法よりビットマップテーブルを得るためのメモリアクセスが1段減って高速のはずです。ビットマップテーブル取得はオブジェクトごとに発生しますから効いてくるはずです。.定量的な比較がもしあると説得力が増すと思いました.実装して比較してもよいですが、実装者の感覚としては調べるまでもないような気も...。喋った話ですが).そうですね。それはいろんなGCを選択したいなぁ、という時にやらないといけないことだと思っています。さださんがおっしゃってる「うまいこと整理」のイメージがあまり湧いてないので、どういうものか例を上げてくれると想像しやすいです。wrote:その辺りはどうなんでしょう...。実装するのはそれほど難しくないので、試しに実装して計測してみます。実装的には、sweep時に解放対象のオブジェクトに対してはobj_free()を呼ぶだけ、flagsは0にしない、freelistも繋がない、スロットをsweepしたあとにbitmapをクリアしない、オブジェクトアロケーション時にbitmapスキャン、みたいなのを考えています。難しいかな.うーん、1.8と1.9の差の方が大きすぎて意味のある性能比較はムリでしょう。メモリ消費量比較くらいなら有意義な比較ができるかな。はい,難しいと思います.が,何らかの指標があると,マーケティングには良さそうです.REEとメモリ消費量を比較したのがあったほうがいいかもしれませんね。passengerは面倒そうなので、まずはskkzipcodeを動かしてみます。REEとRuby2.0ビットマーキングのメモリ使用量を比較しました。共有メモリ使用量と私有メモリ使用量の割合はほとんど変わりないようです。喋った話ですが).そうですね。それはいろんなGCを選択したいなぁ、という時にやらないといけないことだと思っています。さださんがおっしゃってる「うまいこと整理」のイメージがあまり湧いてないので、どういうものか例を上げてくれると想像しやすいです。並列マーキングに簡単に切り替えられるとか、tcmallocが簡単に使えるようになるとか...。個人的には具体的な目的があったほうがAPIも定義しやすいと思っています。2.0.0|||あけましておめでとうございます。||ビットマップマーキングGCをRuby2.0向けに作りました。無事に動いてることを確認してます。|https://gist.github.com/1542547|全体的に実行時間は若干遅くなるようです。||マークでRVALUEのフラグを立てるだけだったのが、ビットマップ上のフ|ラグを立てるようになるので遅くなるのはしょうがないかなと...。skkzipcode|ビットマップマーキングではマークでRVALUEに対して書き込みがなくなるので、|Linuxで複数の子プロセスを実行した場合にも無駄なCoWが発生せず、総メモリ|使用量が少なくなるという利点があります。||skkzipcodeというサンプルプログラムで上記の点を確認しました。|skkzipcodeは、親プロセスでたくさんメモリを使ってデータを保持しておいて、|生成した子プロセスで親プロセスと共有したデータを利用します。kb||PROCESS_CNTは子プロセスの数、SHARED_TOTALは子プロセスで利用している共有|メモリ量、PRIV_TOTALは私有メモリ量です。bmapの方が共有メモリを沢山使っ|ていることがわかり、私有メモリ使用量も少なくなっています。実装|実装について簡単にまとめます。heaps_slotをヒープブロックに埋め込んだ||Linuxでfork()を使わないようなプログラムに対してはビットマップマーキング|の恩恵はありません。CRubyで並列プログラミングしようとするときには|fork()を使って云々するライブラリがけっこう多いので(例えばpassengerとか...)|そういうものに対しては結構効くはずです。||GCの実行時間もそれほど遅くなりませんので、fork()を使わないプログラムで|もそれほど問題にならないと思っています。並列マーキングに簡単に切り替えられるとか、tcmallocが簡単に使えるようになるとか...。個人的には具体的な目的があったほうがAPIも定義しやすいと思っています。並列マーキングに簡単に切り替えられるとか、tcmallocが簡単に使えるようになるとか...。個人的には具体的な目的があったほうがAPIも定義しやすいと思っています。誤しやすくなるのはよいんではないかと思います.なるほど。LangLoading...。