『Dr.WEB メールデーモン』、MTA 用迷惑メール対策製品です！
「ワールドビジネスサテライト」の取材。
Rubyの、ということではなく、「クラウドソーシング」について オープンソース経験者という視点から聞きたかったらしい。
が、そもそもクラウドソーシングなんて言葉を知らない私は 聞かれてからあわてて検索したりして。 役に立つんだか、立たないんだか。
で、あわてて調べたクラウドソーシングについては、 一時「オープンソースにすれば「コミュニティ」が手伝ってくれてどんどん発展する」と 「誤解」されていたのと、同じ臭いを感じるが気のせいだろうか。
一応、インセンティブが重要というコメントを付けておいたが、 最終的にどういう扱いになるんだか不安なものである。
あちこちでRuby(MRI)のGCについてけなされている。
まあ、たくさんのリソースをかけているJVMのGCに勝つのは 最初から無理な相談なんだが、とはいえ問題があるのであれば 改善したいのが技術者魂というものだ。
指摘されているRuby GCの「課題」は以下のようなものがある。
具体的に問題が生じているものもあれば 理論的可能性のものもあるが、まあ、問題がないとは言わない。
それぞれについて、もう少し解説した上で、 考えられる対策についても述べよう。
プログラムの実行時間全体の中で、 GCで消費される時間の比をスループットと呼ぶ。 これはGC全体の性能を意味する。
これを根本的に削減する方法はあまりないのだが、 世代別GCが有効だといわれている。
問題は世代別GCを正しく実装するためには 古い世代から新しい世代への参照を検出する必要があり、 そのためにはオブジェクトの書き換えをフックする「ライトバリアー(write barrier)」を 導入しなければならないこと。
以前のRubyに対して世代別GCを実装した結果では、 このライトバリアーのコストが高くて結果的に性能が低下してしまった。
とはいえ、現在の実装でスループットが悪くて使えないというケースは ほとんど聞いたことがないので、それほど強い動機づけはないかもしれない。
通常の実装ではGC中には他の作業を行うことができないので、 リアルタイム性の高い処理中にGCが発生すると 処理が引っかかったような印象を与えることがある。 ここで重要になるのが「停止時間」である。
停止時間には「平均停止時間」と「最大停止時間」があり、 応答性に重要なのは最大停止時間の方。 またハードリアルタイム領域では、ただ単に短いだけでなく 予想可能である(たとえば最大100msで終了するとか)であることが 重要である、らしい。
世代別GCではスキャンするオブジェクトが減るため、 平均停止時間は減少するが、フルGCにはそれなりにコストがかかるため 最大停止時間は減少する。
とはいえ、リアルタイム性が必要な領域でRubyを使うというケースは (まだ)あまり多くないので、停止時間が問題になることもそんなにないような気がする。
もし本当に問題になることがあるならば、 まずは現在のGCのままスイープフェーズをオンデマンドで行うことで、 GC時間をマーク時間だけに限定でき、停止時間を削減できる。
これは良く指摘されるのだが、 Rubyは保守的GCを使っているので、 本当は参照されていないはずのオブジェクトが参照されていると見なされて いつまでも解放されない(ので結果的にメモリリークになる)ことが ときどき観測されるのだという。
これは確かに私も見たことがある。 個人的には問題だったことはないけど、 サーバープロセスのような長期間生きるプログラムだと 問題になるかもしれない。
で、そういう問題が起きた時の状態をデバッガで観測した経験からいうと Rubyにおけるリークは保守的GC固有の問題(整数値がアドレスと区別できないのでとりあえず生きていると見なす)というよりも、 Cスタックに参照が残っていて生きていると見なされているようだ。 スタック先頭からスタックボトムまで全領域をルートとして 扱っているのが「無駄な参照」を検出してしまう大きな理由なのだろう。
スキャンするCスタックを減らせばよいのだろうが、 スタックの構造はCPUやOSに依存するので、 移植性が下がることになりかねない。
悩ましい。
可能性としては
がある。時間が取れれば考えてみる価値はありそう。
メモリリークとは別に長時間動き続けるRubyプロセスは肥大化する可能性がある。 これはRubyのメモリアロケータがオブジェクトのための領域をmallocする一方で なかなかfreeしないからである。
現状ではオブジェクトのためにheapと呼ばれる領域を割り当てているが ヒープに存在するオブジェクトがすべて解放された時だけ heap領域をfreeしている。 が、Ruby GCはオブジェクトの移動を行わないため、 現在の割り当て方針ではheapがfreeされる可能性はかなり低い。
現在、10000オブジェクト(2回目以降は前回のサイズの1.8倍)ぶん割り当ててるheapのサイズを もっと小さくすればfreeされるチャンスは増す。 もっともあまりfreeされすぎてもmallocとfreeの輻輳が起きて 効率が悪くなってしまうだろうけど。
あと、heapサイズを小さくすると保守的GCの使うオブジェクト判定のコストが上がってしまう 可能性がある。最近、trunkでオブジェクト判定にbsearchを導入したのは このheapサイズ縮小のための伏線である。
マーク・アンド・スイープGCでは、オブジェクトが生きているかどうかを判定するために 各オブジェクトごとにマークビットを設定している。 現状ではこのマークビットはオブジェクト内部に用意されているのだが、 考えてみるとGCごとにすべてのオブジェクトが(少なくとも1ビットは)書き換えられていることを 意味する。
これはUNIX系OSが備えているCopy-on-writeとすこぶる相性が悪い。 せっかく変更されないデータはプロセス間で共有しようとしているのに、 GCが起きるとオブジェクト領域が全部コピーされてしまう。
これだはfork(子プロセス生成)を多用するプログラムの効率が低下してしまう。 で、これについてはパッチを用意したのだが、 heapサイズ削減と相性が悪いし、それでなくてもGC性能が低下しそうである。 どうしたもんだか。
あと、そろそろ発売される日経Linux 4月号でもGCについて解説している。
今年もGoogle Summer of Codeがやってきた。 例年RubyCentralが参加しているのだが、 今年はそれに便乗するか、RubyAssociationとしてか、 メンターとして参加しようかなあ。
本当はRuby専門でRubyAssociationが主催すべきなのかもしれないけれど。
で、いずれにしてもどんなテーマが考えられるかなあ。
James Goslingが「Emacsは使うな」と言った、という話。
いや、私だって設計が古いEmacsを使い続けたいわけではない。 けれども、世の中にEmacsを置き換えるに足るツールが他に存在しないんだからしょうがない。 今まで使ってない機能が満載のEclipseを紹介してくれても 私にはうれしくない。
とりあえず、「今使ってる機能」を提供してくれる編集環境がほしいだけなんだが。 Emacsのフル機能を使ってるわけじゃないから、
くらいあれば。
今まで使ってない機能としては
とかあれば良いけど、なくても我慢できる。
Railsは(人々の注意をPythonに向けるという意味で)Pythonにとってもっとも良いものとなりえる、 という話。
私としてはRubyが他の言語(LispとかSmalltalkとかPythonとか)の 呼び水になったとしてもそれはそれでよいと思っているのだが、 Railsの連中はどうなのかな。
まあ、それでも他の言語に逃げなくても済むように いろいろな機能を提供し続けることは止めたりはしないけど。
いつか追い越せ、他言語。
RubyQuiz #157の結果から、 JRubyにおけるStructのアクセスがMRIより遅い、 というが正式にバグ認定されたという話。
まあ、勇気ある判断である。
ところで、このRubyQuiz #157ベンチマークであるが、 CRubyで試してみたところ、以下のようになった
matz@x61[ruby] ruby -I lib /tmp/157_benchmark.rb
user system total real
FRANK 24.060000 4.090000 28.150000 ( 28.630580)
JUSTIN 5.560000 0.410000 5.970000 ( 6.440966)
LIONEL 0.460000 0.050000 0.510000 ( 0.525290)
DOUG 2.970000 0.420000 3.390000 ( 3.515856)
PHILIPP 1.330000 0.070000 1.400000 ( 1.476920)
BILL 0.360000 0.030000 0.390000 ( 0.397130)
matz@x61[ruby] ruby1.9 -I lib /tmp/157_benchmark.rb
user system total real
FRANK 7.800000 0.020000 7.820000 ( 7.931905)
JUSTIN 3.500000 0.020000 3.520000 ( 3.527578)
LIONEL 0.220000 0.000000 0.220000 ( 0.218631)
DOUG 1.730000 0.010000 1.740000 ( 1.764487)
PHILIPP 0.800000 0.000000 0.800000 ( 0.800930)
BILL 0.180000 0.000000 0.180000 ( 0.182412)
ま、とりあえずRuby1.9の方がそれなりに速いってことで一安心。
が、うかうかしてるとJRubyに追いつかれるな。 競争は良いことだ。どきどきするけど。
LLVM 2.2が(Intel CPUにおいて)、GCC 4.2よりも性能の良いコードを生成したという話。 まあ、GCCのバックエンドがたまたま最良のコードを吐かないということは そんなに珍しいことではないと思うけど。
が、LLVMってのは興味深い技術だよなあ。 もうちょっと真剣に調べてみるかなあ。
Ola BiniのGoogle TechTalk。
またMRIがけちょんけちょんにされてて悲しいんだけど。
eBayがトランザクションを使っていないという話から スケーラビリティをなにか(この場合は一貫性)と引き換えにする、という話。
性能となにかを引き換えるというのはよくある話で、 一番よくあるのは時間と空間の取り引き、 つまり、メモリをより消費することによって性能をあげること。
しかし、データ量そのものが大きくなると そのような取り引きは難しくなる。 メモリには限界があるから。
で、いろいろと考えるわけだ。いわく
他にどんな「取り引き」が考えられるだろうか。
Pythonのイディオム。
List Comprehensionの解説で
results = [(x, y)
for x in range(10)
for y in range(10)
if x + y == 5
if x > y]
という例題がある。そうか、forって複数指定できるんだ。
で、Rubyのメソッドチェーンではこのような複数シーケンスの ネストしたループをストレートに書くことができないことに気がついた。
(1..2).xxxx(1..2)
で、
[1,1],[1,2],[2,1],[2,2]
を返すようなxxxxメソッドがあれば、
(1..10).xxxx(1..10).select{|x,y| x+y == 5}.select{|x,y|x > y}
と書けるんだけど、名前がな。いい名前ないかな。
Rubyのオブジェクトはヒープと呼ばれる複数のメモリ領域のいずれかに所属する。 GCの過程で(保守的なチェックの一環で)ポインタがどのヒープ領域に所属するか をチェックしているところがある。
今までは線形探索をしていたのだが、 ここを二分検索するようにした。 まあ、現時点ではヒープの数はあまり多くならないので メリットはさしてないのだが、今後ひとつひとつのヒープのサイズを小さくすることを 考えているのでそのための下準備として。
ところが、二分検索の基本的なアルゴリズムは理解していたはずなのに なかなかバグが取れない。結構、情けない。
クリスチャン的視点から見たフリーソフトウェア運動。
っていうか、タイトルを見た時にはどういう論理展開するのかと思って読んだのだが、 実は穏当な意見であった。
テレビはダメかもしれん、という話(そのまんま)。
実際、ここ数年テレビを見る時間はぐんぐん減っている。 私の家族も最近はPCを使った情報収集に時間を取られて テレビはあまり見なくなってしまっている。
テレビはもはや時間が余った時に雑学を入力する手段くらいにしかなってなくて、 しかもそれってインターネットで代用可能だったりするんだよね。
やっぱ、2011年にはテレビを捨てることになるのかなあ。
Zed 「ゲットー」 Shawが(CIOに向けて)Rubyの「欠点」について語る。
言語そのものについての欠点の指摘はほとんどないので 言語デザイナーとしては安堵なのだが、欠点のほとんどは私の実装(MRI)の弱点なので そういう意味では涙目である。
やや、根拠が薄いような気もするが(ほんとに遅いのかとか、ほんとにリークするのかとか)、 改善の余地があることについては私も認める。
悔しいので、また手を入れることにする。 一番難しいのはGCだろうか。「保守性によるリーク」や「停止時間」の問題について また考えてみたい。
某雑誌の記事のため写真撮影。 なんか金かけてるよな。
今日はいきつけの本屋さんで立ち読みしているところの撮影だとか。 事前に本屋には許可を取ってあるのだが、 立ち読みしてるところをバシバシとられるのは かなり恥ずかしい。
_ yasm [pair、pair_with なんてどうでしょう？ 直感的に。]
_ まつもと [pairだと2重しか意味しませんよね。]
_ Thor [単純に関数として (Ruby1.9ではGeneratorが死んでるので1.8で) require 'generat..]
_ kzgs [配列の要素数が決まってしまう＆Ruby的に怪しい雰囲気になりますが (1..3).ijk { i+j+k } な..]
_ taiji [comboってのは？]
_ じょりちょこ [nest_withでは？]
_ 元職業プログラマ [いっそのこと、 ([1..2],[1..2],[1..2]).select{|x,y,z| ...} とか、 ([1..]
_ uehaj [Groovyでは「combinations()」が相当するようですね。 http://groovy.codeh..]
_ まつもと [ううむ。Ruby1.9にはArray#combinationっていう全然違うことをするメソッドがありますから混乱しそ..]
_ 元職業プログラマ [さすがはRuby! Ruby1.9にはArray#permutationもあるんですね。 http://d.ha..]
先週は(雪のせいで)教会に来れなかったが、 今週は無事参加できた。 毎週教会に出席するのは当たり前と感じていたが、 改めてありがたいかとだなあと思う。
集会終了後、息子が飛ばしていた紙飛行機が 駐車場の車の屋根に乗ってしまう。 「お父さん、とって」と頼まれるが ひとの車によじ登るのはなあ、とためらっていると 車の持ち主(180cm超)がやってきて、 やすやすと取ってくれる。
あんなに身長が高けりゃな。
「こんなことにしか役立ちませんけど」とか 言われたけど、それでもやっぱり身長が高いのはあこがれる。
アメリカに行った時とか、(立ったまま)打ち合わせしてても みんな背が高いから見上げないといけなくてつらいんだよな。
_ ジョン・ドゥ [よければ放送予定の日にちを教えてもらえないでしょうか？]
_ まつもと [15日、土曜日でした。手遅れですね。ごめんなさい。]
_ ささだ [最大停止時間は減少したほうがいいんじゃないでしょうか。]
_ まつもと [減少しない方がよいわけはないのですが、現状でも平気なケースは多いのも事実です。と思ったらLazySweepを実装した..]
_ まつもと [よく見たらトラックバックじゃなかった。URL貼っときます http://d.hatena.ne.jp/author..]
_ kenn [Rails+FastCGIだと、プロセスサイズの肥大化は結構致命的だったりします。Rubyプロセスのいくつかが500..]