RubyKaigi 2日目は参加できなかったので、 あちこちのレポートをチェック。
akrさんの「Matzを説得する方法」は普通にオープンソースで自分の要望を通す方法として 有効だと思った。「Perlを出すと通る」というような枝葉は除いて。
authorNariの「RubyのGCを(ry」は誤解を招くと思った。
JRuby, Rubinius, CRubyのGCをそれぞれ
として、CRubyのGCは(形容詞が少ないから)劣っていると思わせるような表現があるが、 それはあまり適切ではない。GCの実装というのはいつもトレードオフだからだ。
前にも書いたがスループットはGC全体の処理時間、 レスポンス(or ポーズタイム)はGC1回によって本来の処理が停止する時間である。
これらは多くの場合トレードオフの関係にある。
incrementalとかgenerationalなGCを実装するためには write barrierという仕組みを入れる必要があるが、 それはほとんどの場合スループットを低下させる。 要するにwrite barrierを入れると遅くなるのだ。
普通の方法ではwrite barrierを入れることによって増大したコストを 穴埋めするほどGC処理効率を改善することはできないし、 card markingなどの手法を使うとこんどはメモリを馬鹿食いする。
CRubyはconservative(保守的な)GCを採用しており、 残りはexact(正確な)GCを採用している。
exactなGCの方が性能的にやや有利だが、 一方、拡張ライブラリの書きやすさは 保守的GCの方がずっと楽である。
たとえば、Rubiniusはexact GCを採用しているため
など、Cでのメソッド定義にかなり制約がある。 まあ、ほとんどのメソッドをRubyで実装しようというRubiniusでなら 受け入れられる制約なのかもしれない。
CRubyは開発効率を重視しているので、 今後も保守的GCを使い続けると思う。
Ruby Enterprise Edition*1でも 指摘されていることだが、サブプロセス間でメモリページが共有されている場合には オブジェクトにできるだけ触らない方がよい。ページのコピーが発生しちゃうから。
ところが、JRubyやRubiniusのcompactを行うGCは、そういう観点からは壊滅的である。 まあ、JavaにはforkはないからJRubyは気にする必要はないのかもしれないけど。
現在のCRubyのGCもcopy-on-writeについて問題はあるけれども、 compactingを行わないので、(REEが使っている)bitmarkingなどの手法で 対応する可能性は残されている。
というわけで、「どんげんかせんといかん」だろうとは思うが、 今のRuby GCが今のようになっているのはそれなりに理由がある、という話。
世代別GCだって、copy-on-write friendlyだって、実際に試してみた上で、 普通のケースで性能低下が発生するので採用していないわけで。
*1 Ruby Enterprise Editionについてはあとで書くつもり
Charlesが来るからオフィスに来て、と言われる。
でかけると、某社社長が松江市の業務システム(Ruby製、一部JRuby入り)について 一生懸命(英語で)説明している。すばらしい。
あと、Charles相手にNaCl対抗将棋戦、囲碁戦が行われる。 将棋はshugoの勝ち、囲碁は時間切れ。
島大で講義。Charlesの講義が聴ける島大生はラッキーだと思うけど、 本人たちがどれだけ自覚しているんだろうか。
懇親会(その前にCharlesたちは千鳥城を見学したらしい)。
NaClの若い衆がCharlesを取り囲んで一生懸命英語で話をしていた。 authorNariはJRubyのGCについて食い下がっていたけど(うーむ)、 「そんなにはJVMに任せているからシラネ」とあしらわれていた(らしい、本人談)。
ケータリングは大変おいしかった。食べ過ぎ。
これからCharlesは福岡→東京と移動するらしい。 うーむ、なんて体力勝負。