Building the Ruby Interpreter - koi1
- 参加者とのインタラクションを楽しむために、KeyNoteではあまり深ぼらない
- 2014年は個人的にとても大切な年。今年結婚して明日結婚記念日。
10年
Who am ko1?
- CRuby committer
Herokuで、Full time でCRubyの開発をしている
- Matzと中田さんと一緒に。中田さんには昨日ひさしぶりに会った。
- HeorkuはBento sponsor。Herokuの本が昨日出た
Ruby assosiation 理事
- 3件くらいのGrantを50万くらいで募集中
アンダースタンディングコンピューテーションという本の監訳
- コンピュータサイエンスという理論。苦手だが、読めたのでオススメ。
10年何をやってきたか？
YARV: Yet Another RubyVM
Fiber(Ver. 1.9-)
- ユーザが指定したタイミングでしかコンテキストが切り替わらない
- coroutine, semi-coroutine
- これを高速にコンテキストスイッチするようなものを大学で作った
- ユーザが指定したタイミングでしかコンテキストが切り替わらない
Flonum(Ver. 2.0-)
RGenGC(Ver. 2.1-)
研究プロジェクト
- 主に高速化、並列化
その他
- 活動内容: http://www.atdot.net/~ko1/activities/
- 1ページに纏めておくと、履歴書書くのが楽なのでオススメ
- 12月は予定がないので誰か呼んで欲しい。
何が簡単で、何が難しいか？
Rubyの高速化: Interpriter開発者の責務は、クオリティを高めること
- 色んな尺度があるが、一番大事なのはちゃんと動くこと
- 速く動くこと
- 消費リソースが少ないこと: メモリ、消費電力
- 昔作ったプログラムでちゃんと動くこと
- 拡張性があること: 手を入れづらいとバグ修正に手間が掛かるし、ワクワクするような新しい機能が入りづらい
それぞれトレードオフが存在する
- パフォーマンス < -> 信頼性、消費リソース、後方互換性、拡張性
何をしなきゃいけないか？
例えばRubyだと
VM書くのはそんなに大変な作業ではない。シンプルに作るのは簡単だが、人間が管理可能にするとか最適化とか相互運用可能性を考えるとすごく難しい
簡単なVMのデザインを考える
- ちょっとずつ簡単なものを追加していく。
- testが既にあったので、楽だった
- test frameworkもRubyだったので、それが動かないというのが大変だった
- テストが走った！やった！Fが一個出たくらいだと全然壊れていないｗ
- 命令をひとつ取ってきて、それを実行する: 簡単なものは1週間くらいで動くようになった
- しかし全部動かすのはやっぱり難しい
- ブロックのデータ構造や
- 一ヶ月とかかければ大丈夫。時間が解決する
- VMのデータ構造を考える必要がある
- ちゃんと高速化しようとすると大変
- アグレッシブにやろとすると、ダイナミックな特定(メソッド再定義など)を出来るように、脱最適化することもやらなければいけない
- しんどい。一回最適化によってまぜこぜになったコードを元に戻さなければいけない: 難しいけど考える価値がある問題
Cコードとの親和性
- Cはより多くの事ができるし、速い
- それをやるとアグレッシブな最適化に対して不利になる
Performance
- 並列実行できない
- 博士論文の一部は、Rubyでの並列実行
- 単純に並列実行を提供すると、大変
- Programming happy に並列実行/デバッグできる仕組みが必要と考えている
1995年に"Why Threads Are A Bad Idea?"という発表がある
トレードオフ: なんでもできるけど、危ないプログラムが書きやすい < -> safeコードしかかけないけど制約がある
- 書きやすいけど安全、というものを皆探している
- Flexibility < -> Relizzability
- Threadプログラミングを"ちゃんと"やれば速いし、動く
- free() vs GC の議論と似ている
安全なものをどのように提供するか？
- プロセスを分ければ
- IPC(inter-process communication)をもっと良くする
- MVM。小さなインタプリタ
- 全てのスレッドがオーナスレッドを持っていて、オーナスレッド以外からアクセスするとエラーになるとか
- ローカル変数にアクセスしようとするとprocオブジェクト。Globalなアクセスが難しいとか色々あるが、どのようにしたら良いか考えている
- すごく面白いテーマだと思うので、誰か一緒に考えてくれると嬉しい
- バグが有ることを検出するための仕組み
- 非決定的な挙動は、デバッグによってプログラマを殺していまう
- 検出の方法として研究で出てきているものを実装する
- どこでコンテキストスイッチしたかを再現するとか
GC
- GCのアルゴリズムは簡単。それをバグ無くちゃんと作るのは大変
- 色々なアルゴリズムはあるが、考え方は簡単
- しかし、アルゴリズム以外の考え方とMixすると難しい
また、互換性の問題も合って、GCを上手く実装できなくなったりする
- Write-Barrierという仕組みは世代別GCに必要。だが、全ての人に強制することはできない
- 我々は解決策としてWBを選べるようにした
GCのバグが発生したことが分かった時には、原因はずっと前に起こっていたりする
- Assertionをたくさん作る
例えば: old object が new object を参照することはない
- WBを入れ忘れると起こる可能性がある
Measurement
- 実行時間を測るだけは簡単だけど、定期実行したり、何を測るか考えるのは大変
- 物理環境だとやりやすい。
- 小さなラックスペースを芝浦工大の菅谷先生から提供してもらっている。
- もし、速いマシンが眠っていたら貸して欲しい
- micro benchmarkは簡単。大規模なベンチマークは？
- 何を測る？
- 例えば、メモリ使用量とは何なのか。ピーク時の値なのか、中間値なのか平均なのか。いい知見がある人がいれば教えて欲しい。
Development community
- Ruby committerになるのは難しくない。松本さんに
- Ruby developerとして継続的に開発していくのは難しい
- Rubyを使ってくれる会社、Herokuの様なサポートしてくれる会社が増えてくれれば嬉しい。
- 書籍
- Ruby 会議3日目、 Ruby kaigi interpriterの発表がすごく良い
- Rubyの開発で大事なこと
- 新しい技術を学び、発表し、実装し、評価するサイクル
- それによってトレードオフに打ち勝つことはすごく嬉しい。こういうのが好きな人はぜひ一緒にやって欲しい。
- まだまだやることはたくさんある。難しいこともたくさんある。職業的な理由、楽しみのためにぜひ参加して欲しい
