日時：2006年 3月16日（木）18:30 から
場所：東京農工大学 工学部情報コミュニケーション工学科 7号棟 3階3K室
JR中央線東小金井駅南口から，西へ向かって徒歩8分程度です。
農工大の東門に建物の配置図があります。
http://www.cs.tuat.ac.jp/access.html
に案内図があります。
食事:
ありません。東小金井駅近辺のモスバーガー、途中のピーコック （マク
ドナルドあり）などをご利用ください。
話者：
笹田耕一（東京農工大学大学院）
話題：
次期Ruby処理系の開発
概要：
オブジェクト指向スクリプト言語 Ruby はその使いやすさから世界中で利用され ている実際的なプログラミング言語である。しかし、現行の処理系はプログラム の実行方式が構文木をたどるという単純なインタプリタであり、速度的な問題が あった。そこで、発表者は命令列（バイトコード）実行型の Ruby 用仮想マシン YARV: Yet Another RubyVM を開発している。YARV はすでに Ruby のほとんどの 機能を備えており、さまざまな最適化により高速に Ruby プログラムを実行でき るよう工夫している。他にもネイティブスレッドへの対応などを行っている。 そこで、本発表では YARV の内部実装について概観し、Ruby 2.0 に向けての今 後の課題を示す。
出席者：21名
高橋孝一（産総研），佐々木直志（キヤノン），樋口直志（NEC）， 伊知地 宏（ラムダ数教研），石畑 清（明治大），長 慎也（早稲田大）， 久野 靖（筑波大），鴻池祐輔，並木美太郎（東京農工大）， 石崎賀昭，卜部昌平，大日向大地，寺田 実，丸山一貴，山口龍太郎（電気通信 大）， 荒川博志，田中哲朗，松崎公紀，森田直幸，横山大作，筧 一彦（東京大）
- Ruby2.0の仕様が決まっていない(決まらない)のなら, 機能を 削って, VMの高速化を図るのはどうか. それは大いにあり得ると思うが、現状では「Ruby」の仕様をおいかけるので手 一杯で、新たな(たとえばVMに有利な)仕様を起こす余裕がない。 - Perl 6.0のようなプラグマを導入するのはどうか. まさにそれを検討中です。が、記法が悩みどころです。 - なぜJava VMには持っていかなかったのか. 一番端的にはJava VMに実装してもつまんなかった、というのが理由ですが、 まともな理由としては、Java VMで高速なRubyの実装は現状では困難です。たと えば、メソッドディスパッチはJava VMレベルのInvoke*命令にすることは（ベリ ファイアの関係で）出来ませんでした。現在、これを緩和するための Invokedynamicという命令が提案されているそうで、これが入るとまた状況は変 わるかもしれません。あと、動的にクラスが編集、もしくは複製が出来るように なると、大分現実味が出てくると思います。.NET CLRではそういう工夫がされて いる（用に見える）ため、今そちらに興味があります。 - continuationの実装は. まだ実装していませんが、実装方法はVMのスタックとともにマシンスタックを コピーする方法をとる、つまり現在のRubyのVMと同様の実装方法になるかと思い ます。 - VMでCTRL stackの中身をheapに移し替える際, ポインタ付け替えをする ためにはstackをなめることになってしまうのか. はい。ただ、大体はスタックの先頭あたりで十分なので、これが速度的ボトル ネックにはならないかと思います。 - もともとの実装はどうであったものを, そのように置き換えたのか. もともとはスタックフレームがもっと冗長な表現だったため、それを簡略化し ました。 - 特化命令について毎回やるのは大変ではないか. グループ(ループ?)単位で できると良いのでは. 十分ありえる最適化だと思います。が、Rubyでは基本ブロックはあまり大きく 無いことが多いので、効果がどれくらいになるかは検討しないといけないと思い ます。ループからくくりだすときに有効、というご指摘はそのとおりかと思いま す。 - 「整数の"+"メソッドの再定義」ということは実際に起きるの? ないので あれば再定義されるまでは高速な実装を利用, ということでも良いのでは. それもありかと思います。 - i++ではなくてi.succなのか. まず、Ruby には ++ という表現がありません。また、i += 1 よりも i.succ のほうが（オペランドがない分）高速なため、i.succ を利用しています。 - ブロックのインラインは, Lispの実装でのmapの展開のようなことをする ことになるのか. はい。ただ、Lisp の実装ではコンパイル時に map であることを解析できるこ とが多いですが、Rubyの場合はそれが出来ないため、実行時（メソッド起動時） に判断する、ということになっています。 - timesについての高速化について説明があったが, timesを再定義されると どうなるのか(どう対応するのか). times メソッド自体がインライン化をするので、times が再定義されればイン ライン化も起こらなくなります。 - VM生成系により52命令が875命令になり, instruction cacheに載らなくなる という話しがあったが, 試したarchitectureは何か. PenMなら多く搭載 されているのでは. PenM で試したところこの結果なので、相当命令キャッシュが外れまくったん だな、という感じです。 - Threadについて, なぜ中断が必要か. たとえば、timeout の処理などで強制的な中断を利用します。入出力でブロッ クしてしまったスレッドに対して一定時間たったら timeout させたい、なんて 用途があります。 - Threadでのスピードについて, なぜ一つのスレッドしか動作し ないようロックをかけているのに Dual Core によって高速化したのか？ select の処理なのが多重化して高速化したんではないかとにらんでいますが、 詳細な評価はまだ行っておりません。