読者です 読者をやめる 読者になる 読者になる

Akatsuki Hackers Lab | 株式会社アカツキ(Akatsuki Inc.)

Akatsuki Hackers Labは株式会社アカツキが運営しています。

RubyKaigi2014 速報(2) - Building the Ruby Interpreter

イベント

Building the Ruby Interpreter - koi1

  • 参加者とのインタラクションを楽しむために、KeyNoteではあまり深ぼらない
  • 2014年は個人的にとても大切な年。今年結婚して明日結婚記念日。

10年

  • VARVから10年、Rubyの会から10年、Rubyist Magazineから10年
  • Rubyの開発で、何が簡単で、何が難しいか?という話をする。

Who am ko1?

  • CRuby committer
  • Herokuで、Full time でCRubyの開発をしている

    • Matzと中田さんと一緒に。中田さんには昨日ひさしぶりに会った。
    • HeorkuはBento sponsor。Herokuの本が昨日出た
  • Ruby assosiation 理事

    • 3件くらいのGrantを50万くらいで募集中
  • アンダースタンディングコンピューテーションという本の監訳

10年何をやってきたか?

  • YARV: Yet Another RubyVM

    • 笹田さんのRubyの世界: Ruby script -> Parse -> Compile -> Bytecodeを以下にやるかという風に見えている
    • Stack based VM。開発開始が2004/1/1。
    • Ruby実行がスレッドになった。GVLを持っている
  • Fiber(Ver. 1.9-)

    • ユーザが指定したタイミングでしかコンテキストが切り替わらない
  • Flonum(Ver. 2.0-)

  • RGenGC(Ver. 2.1-)

    • CRubyに導入するために、WB-unprotected というテクニックを使った
    • Ruby2.2 から Incremental GC が入るように頑張っている
    • サンディエゴのRuby conference で発表しようと考えているので、よかったら来てください
  • 研究プロジェクト

    • 主に高速化、並列化
  • その他

    • 活動内容: http://www.atdot.net/~ko1/activities/
    • 1ページに纏めておくと、履歴書書くのが楽なのでオススメ
    • 12月は予定がないので誰か呼んで欲しい。

何が簡単で、何が難しいか?

  • Rubyの高速化: Interpriter開発者の責務は、クオリティを高めること

    • 色んな尺度があるが、一番大事なのはちゃんと動くこと
    • 速く動くこと
    • 消費リソースが少ないこと: メモリ、消費電力
    • 昔作ったプログラムでちゃんと動くこと
    • 拡張性があること: 手を入れづらいとバグ修正に手間が掛かるし、ワクワクするような新しい機能が入りづらい
  • それぞれトレードオフが存在する

    • パフォーマンス < -> 信頼性、消費リソース、後方互換性、拡張性
  • 何をしなきゃいけないか?

    • どのようなトレードオフがあるかきちんと知る
    • どのようなところにバランスをとるか決める
    • トレードオフに打ち勝つ。どっちも良くなるような道を探す
  • 例えばRubyだと

    • Rubyが出る前は、豊富な言語機能を使おうとすると、書きやすさ、読みやすさが下がるという世界だった
    • それでRubyは性能が犠牲になるというのではダメなので、そうならないように性能を上げる事が必要
  • VM書くのはそんなに大変な作業ではない。シンプルに作るのは簡単だが、人間が管理可能にするとか最適化とか相互運用可能性を考えるとすごく難しい

簡単なVMのデザインを考える

  • ちょっとずつ簡単なものを追加していく。
  • testが既にあったので、楽だった
  • test frameworkもRubyだったので、それが動かないというのが大変だった
  • テストが走った!やった!Fが一個出たくらいだと全然壊れていないw
  • 命令をひとつ取ってきて、それを実行する: 簡単なものは1週間くらいで動くようになった
  • しかし全部動かすのはやっぱり難しい
    • ブロックのデータ構造や
    • 一ヶ月とかかければ大丈夫。時間が解決する
  • VMのデータ構造を考える必要がある
    • 同じようなコードをたくさん書くと保守性が下がる: VM記述言語を作って、そこからCのソースコードを生成する
    • GITコンパイラを作ろうとすると大変: LLVMを中間コードにするとか考えていく必要があると思っている
  • ちゃんと高速化しようとすると大変
    • アグレッシブにやろとすると、ダイナミックな特定(メソッド再定義など)を出来るように、脱最適化することもやらなければいけない
    • しんどい。一回最適化によってまぜこぜになったコードを元に戻さなければいけない: 難しいけど考える価値がある問題

Cコードとの親和性

  • Cはより多くの事ができるし、速い
  • それをやるとアグレッシブな最適化に対して不利になる
    • RubyのコードがCになるとVMから理解できない
    • JavaVMJavaで書いてある、という風にRubiniusのようにRubyRubyを書く。
    • Cのソースコードにannotationを付ける。しかし、人間は忘れるので
    • LLVMで解析する
    • RubyとCをミックスできるようにする?とか

Performance

  • 並列実行できない
  • 博士論文の一部は、Rubyでの並列実行
  • 単純に並列実行を提供すると、大変
    • Programming happy に並列実行/デバッグできる仕組みが必要と考えている
  • 1995年に"Why Threads Are A Bad Idea?"という発表がある

    • Threadプログラムはトップレベルのプログラマしかできない!
    • 全ての状態をshareしているので、syncする必要がある。これは、一つでも忘れるとバグになる
    • 同時に実行するべきではないものも実行してしまう: 複数のThreadから1つのものを触ってしまう
    • バグが出た!->再現しないのでデバッグがすごく辛くなる
    • このような大変なことをRubyでやると楽しくなくなるのではないか?Ruby Programmingはhappyなものであって欲しい
    • 人類がThread Programmingできるようになるかというとちょっと。。。w
  • トレードオフ: なんでもできるけど、危ないプログラムが書きやすい < -> 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は簡単。大規模なベンチマークは?
    • Railsでdiscourse benchmark。大きなアプリケーションを提供してもらえると、ベンチマークスイートとして検証できるので良かったら欲しい。
  • 何を測る?
    • 例えば、メモリ使用量とは何なのか。ピーク時の値なのか、中間値なのか平均なのか。いい知見がある人がいれば教えて欲しい。

Development community

  • Ruby committerになるのは難しくない。松本さんに
  • Ruby developerとして継続的に開発していくのは難しい
    • Rubyを使ってくれる会社、Herokuの様なサポートしてくれる会社が増えてくれれば嬉しい。
  • 書籍
  • Ruby 会議3日目、 Ruby kaigi interpriterの発表がすごく良い
  • Rubyの開発で大事なこと
    • 新しい技術を学び、発表し、実装し、評価するサイクル
    • それによってトレードオフに打ち勝つことはすごく嬉しい。こういうのが好きな人はぜひ一緒にやって欲しい。
    • まだまだやることはたくさんある。難しいこともたくさんある。職業的な理由、楽しみのためにぜひ参加して欲しい

質問

  • 特にやって欲しいこと

    • Rubyの開発では、さっき言ったこと全部やって欲しい
    • 例えば、並列処理をどのように解決するか
  • 今まで直面した問題、解決したもので難しくて嬉しかったもの

    • 世代別GCの導入が一番
    • 泥臭い話で辛かったのはProcをどのように作るか。本当にしんどかった。
  • コンセプト:他の言語処理系を利用して、並列処理を実装する様なことはしないのか?

    • 非常にagree。しかし、自分で作ったほうが楽しい!個人としては、CRubyで開発を続けてこうと考えている