いつまでたってもRite VMの開発に取り掛かれないし、 そうこうしているうちに笹田さんがyarv(yunoだっけ？)を始めちゃったりしてるので、 今までサーベイしたことをメモしておこう。
Rubyのような型情報が一切なく、最適化が行いにくい言語のための仮想機械で有効そうなテクニックは以下の通り(全部ではない)。
基本的なアイディアは、仮想機械の実行のうち、 もっとも多く時間を消費するのは、命令のフェッチとジャンプであるので、 ここを改善しようというもの。ソフトウェアによる仮想機械ではCISCな発想が良いみたい。 yarvはこれらの多くをすでに実現している。
これらでVM部分の実行時間が半分以下くらいになるんじゃないかと期待している。
後、残りは
だが、これはなかなか良いアイディアがない。
メソッドキャッシュの高速化について考えると、 現在のメソッドキャッシュはなかなか効率的ではあるが、 グローバルなテーブルルックアップなのがスレッドには嬉しくない。 とはいえ、インラインメソッドキャッシュはなかなか難しいし。
メソッド呼び出しの方はスタックのデザインで少し変わるかも。 vmgenのサンプルにあるminiとかが参考になるかもしれない*1。 それと、演算子呼び出しなどで、条件が成立している時には、 直接計算してしまうことでメソッド呼び出しを削減できる。 lightningのようなものによる JITも考えられるけど、移植性を犠牲にする割にどれだけ嬉しいかは検討しないとな。
JITに限らずVMの高速化は面白いテーマではあるが、 所詮スクリプト言語なので報われるかどうかわからない分野である。
*1 もっともminiが速いのはチェックがないからかも
明日は経済産業省による「高度IT人材早期発掘のあり方検討会」の第二回である。
しかし、はっきり言って私には画期的なアイディアはないのだよなあ。
ような企画ってのはどんなものがあるのか。 「未踏ユース」でいいじゃんって思いも一部あったりする。
先日来のアクセス増加のため(スラッシュドットの影響が大きいらしい)、 昼休みや深夜などには負荷が高くこの「にっき」をはじめ boron.rubyist.net 上のたくさんのページが閲覧できないことがあったようだ。
調べたら日に何度もロードアベレージが30とかになっている。まあ、boronはもともとかずひこくんのマシンだったものをrubyist.netやmodruby.netなどが間借りしているのだが、 どうもマシンパワーが不足しているようだ。先日、全面的にmod_ruby化を行ったりしているのだが、焼け石に水らしい。
マシンリプレースが必要か。しかし、原資はどこから？
ソフトウェア特許の危険性について触れた社説。こういう「一般向け文書」はありがたい。
朝、道が凍結していたが、心配したほどではなく、無事に飛行機で東京に。 そのまま表参道の青山ダイアモンドホールへ。
参加したセッションは以下の通り。
XP事例カタログ
「dRubyの方から来ました」の咳さんをはじめとしたXP実践の事例紹介。 「忍者式テスト」とか「スタンダップミーティング」とか、実際にうまくやっている例は参考になる。 もっとも、私はうちのチームで一番XPを実践していないので、 他のチームメンバーには常識なのかもしれない。
Web-DBシステムチューニングの方法
割とフツーのDBチューニング。私はDBに関しては素人以下なのだが、 みなさん、日々こんな苦労をしているのね。
軽量Javaへの潮流
「Struts + Spring + JSP」でJ2EE5.0を先取りって話。 「新しい技術で楽ができる」ことが強調されるが、 それはつまり「今のJava技術者」がめちゃめちゃ苦労していることを意味するような気がする。 これらがオープンソースソフトウェアであるのは確かだが、 この内容は「オープンソース」トラックではないような。
なぜ「オープンソース」でうまくいくのか(前編)
副題が『オープンソース的開発手法の秘密をさぐる』。 Linuxの開発体制をベースに「オープンソース的開発手法」 あるいは「バザール手法」について解説。 私(とその周辺)には物足りなかったけど、 今日の聴衆の大半にはちょうどいいレベルだったのかも。 ビジネス的な話はあえて避けたみたい。
聴衆における「スーツ族」の割合がめっぽう高いのも印象的だった。
なぜ「オープンソース」でうまくいくのか(後編)
後半。副題は『まつもとゆきひろが語る「オープンソース的開発手法の現実」』。 後半になるとスーツ族とギーク族の割合が変化しているような気が。
風穴さんが質問して、私がそれに答えるというスタイル。 私のバックグラウンドやらRubyの開発動機やら開発体制やら。 風穴さんの意向でオープンソースの思想やらビジネスやらの話は避けて、 開発スタイルや開発者の気持ちなどにフォーカス。 当たり前だが私にとってはなにも新しい話ではないので(みんなどこかで話したような気がするし)、 これを聞いた人たちがどう思ったのかはよくわからない。 私の周辺にいる人たちにとっては新規性は無かったみたいだし。
最後の質疑応答でややビジネス的な話が。うち(netlab.jp)が差別化にオープンソースを使っている話を紹介した。あと、時節柄、特許の話が。それに対する答えは
結局、ソフトウェア特許はオープンソースに対する脅威というよりは、 ソフトウェア産業全体に対する脅威だと思う。良い機会なのでもっと議論を深めるべきだ。
その後、有志と表参道(から渋谷方面にちょっと移動した)インド料理店で食事。
参加者は、(私の席から時計まわりに)Shelacyさん、 naruseさん、かずひこくん、tellmeさん、 えとーさん、風穴さん、くろももさん(名前、間違ってないよね)。
今回はRuby関連の集まりとしてはありえない男女比であったような気がする。
えー、個人的にはおなかが空いていたのでがつがつ食べることばかりで(カレーおいしかった)、 あまりお話できなかった人もいましたが、私は楽しかったです。
参加表明してたのに、来れなかった人は残念でした。またの機会に。
メソッド定義の対象となるクラスを指すruby_classと、定数参照の対象となるクラスを 指すruby_cbase(その実態はruby_cref)は、非常に似通っている。というか、このふたつ って本来は統一した方がわかりやすいんじゃないだろうか。きっとユーザーもそれを期 待してると思うし。
ということで、統一する。今回はruby_classを全削除して、 ruby_cbaseに置き換えるこ とにする。
で、思い立ったら３０分で作業が終了してしまった。今まで１０年以上これらスタック と格闘してきたのは一体なんだったんだろう。
というわけで、1.9ではスタックを３本削減。残るは以下の５本。
これらも手を入れる余地はありそうな気がする。たとえばprot_tagを一つ一つジャンプ しながらチェーンするのではなく、目的の場所までいっきにジャンプするとか。 ruby_dyna_varsをリンクではなく各レベルごとの配列にするとか。
昨日の高速化パッチは高速なんだけど、どうやらN-GramのインデックスになっているBDBの更新に問題があるようで、検索結果に大きな漏れがある。morqのようなタイプのメールリーダーでは検索以外にメールに到達する方法が無いので、漏れは致命的だ。
しばらくソースを眺めてみたが、かなり大規模な修正で、どこに問題があるのか発見することはできなかった。
しかたがない。このパッチは当面断念しよう。
で、パッチを当てる前のRastのソースを眺めてみる。とりあえず遅いのはsyncする部分のようなので、そのへんを重点的に。
まず、明示的なfflush(3)とBDBのsyncはおそらく不要なので外すことにする。 stdioの方はfseek(3)を呼んでいるのでそのタイミングでflushされているはずだし、 BDBの方も明示的にsyncする理由はなさそうだ。BDB自身に任せた方が賢いsyncをしてくれるだろう。
次にソースをよく読むと、データファイルの書き出しで、各N-Gramごとに fseek+fread+fwriteを繰り返している。
デバッガで実行してみると、 syncの遅さはどうやらここに由来しているようだ。プロファイラまで動かせると確実なんだが、 Rubyで書いてあるmorqからRast部分だけのプロファイルを取る良い方法を知らないのだ。
というわけで、できればここをページ単位での書き出しにしたいところ。
だが、なかなか良いアイディアが思いつかない。
いっそ、現在の「BDBによるインデックス＋データファイル」という構成から「全部QDBM」にしてしまうってのはどうだろうか(QDBMS好き)。
Curiaを使えば、データ容量の問題もさほどではなさそうに思うし、素朴に要素ごとにfeek+read+writeするよりは、 (ページングしてるから)速度的にも、(圧縮してるから)容量的にも有利だと思うんだけど。
でも、確かRast設計段階でこのアイディアはボツにされたんだよな。ま、単なる「上司の思いつき」だったので、その時は強くは出なかったんだけど。自分が作業するわけじゃないから、当事者の意見の方が重要だしね。
でも、担当者が忙しい今のうちに、こっそり試してみるか*1。
はっ、...もう２月か。原稿の〆切が近づいているぞ。もうちょっと先まで我慢したほう がよいか。
追記:
後でQDBMのソースを読んだら、DepotやCuriaはデータ圧縮してなかった。容量的な利点 は無いようだ。
*1 ここに書いたら全然「こっそり」じゃないなあ
教会の宣教師による英会話を手伝ってくる。
今日は「英語によるスキット」。我々の班(６名)は、即興で「三匹の子豚」を演じたの だった。急だったわりには全員ノリノリだったという。
確かに結構楽しかった。
降ってきたよ。7時前に帰宅したときには降ってなかったのに、 7時10分に英会話に出発 しようとしたら、わずか２０分ほどで地面が真っ白になっていた。
明日の温泉は大丈夫かな。寒い方が風情が出るけど。
そして、明日こそは安来苑の温泉に入ろう。古くからインターネット接続完備の温泉旅 館として(知る人には)知られている安来苑では過去数回宴会を行っているのだが、私は いずれもハックに熱中していて、温泉に入りそこねているのだ。
明日こそは。明日の「Ruby温泉ミーティング」こそは。
今日になってからFirefoxを始めとするいろいろなプログラムが起動に失敗して coredumpするようになる。どうもフォントに問題があるらしい、と気がつくまでずいぶんかかった。
strace付きでFirefoxを起動して、フォントファイルの読み込みあたりで落ちていることでようやくわかった。その後、fc-cacheも落ちるので、これもstrace付きで実行させ、原因がttf-arabeyesというTrueTypeフォントであることを突き止めた。
そういえば何日か前にdselectでチェックを入れたような気がする。
もともと不要だったので、さくっと削除。やっと通常通りに動作するようになった。しかし、こんな問題が起きるようでは、まだまだ「コンピュータは難しすぎて使えない」ものだよなあ。普通の人がこんな問題に直面したら、対処しようがないじゃん。
答え: 「普通の人」はDebianを使いません。
ま、それは冗談としても。うちの妻のマシン(OSS貢献者賞でもらった日立のPrius)は、ネットワークが接続しているのに、「サーバーが見当たりません」というエラーをしばしば出す。どうやら、DNSがおかしいように思うのだが、ネットワークの仕組みはわかっていても、 Windows XPの仕組みがわからないので直しようがない。ネットワークの「修復」を行うと再接続をして、一時的には状況は改善するのだが、すぐに再発してしまう。
Debianでそんな問題起きたことがない(あるいは問題と意識する前に復旧できる)んだけどなあ。
とうとう申し込みオープン。今年はいったいどれくらいでチケットが売り切れるか。
まず今年の会場は(OSCONの会場でもあるくらいだから)バカ広い。 さらに受け入れ人数も昨年の倍を予定している(ということは800越えか？)らしい。 となると、3日で売り切れた昨年よりはマシであることが期待できる。
とはいえ、Railsの話題性を考えると楽観はできないな。
「行きたい」と叫んでいた後輩のKくんはすでに申し込みをすませたらしい。 仕事の調整はつくのかな。費用は会社負担にしたげるから。
音声インタフェースはうるさいので実用は難しい気はするけど(「はどそ〜んっ」)、 一度遊んでみたい気はする。
まわりに誰も居ないところで。
何週間かぶりの教会の掃除当番。当初は私一人でやるつもりだったが、 「夕食、外食にして、ついでについていくよ」と家族総出になった。
掃除機かけて、イス並べて、ゴミ片づけて。 いや、人数が多いと仕事が早い。 助かった。
その後、サティで食事と買い物。 末娘が食べるのが超遅いので、 私と末娘だけ置いていかれた。
「口、からっぽになった？」
「あーん(まだ入ってる)」
を何度繰り返したことか。
女性陣はチョコレートと、洋服。息子は靴を買ってもらったほかは本屋へ。
私は子守り。
先々週まで「お母さんといっしょでないとプライマリーのクラスに出ない」と 駄々をこねていた娘は、先週からひとりでクラスに出れるようになった。 ちょっとした動機づけと、それによる「良い行動」をさんざんほめてやったのが 原因のようだ。ポジティブフィードバックが効いた、ということでもあるが、 いずれにせよ、聞き分けのある態度を見せるだけ成長してくれたのがうれしい。
「親にとって都合が良い」ことを喜んでる側面もないではないな。
先週、教会の大管長であるゴードン・Ｂ・ヒンクレーが亡くなったので、 彼の葬儀および埋葬が執り行われた。 その様子は衛星放送で中継された。
彼の生涯のダイジェストも放送されたが、 立派な人をなくしたのだと惜しむ気持ちが強かった。 もっともすでに９７歳にもなっておられたので、 これ以上激務を背負わせるのはいかがなものかとも思ってはいたのだが。
いくつかのことを改めて気付かされた時間であった。