2014年9月18日~20日の3日間、タワーホール船堀にてRubyKaigi 2014が開催されました。基調講演をそれぞれレポートしていきます。
1日目の基調講演は、YARVやRGenGC、RincGCを始めたした主要機能の開発に携わっているRubyのコアコミッターの笹田耕一さんの「Ruby開発者にとって簡単なこと、難しいこと(Building the Ruby Interpreter What is easy and what is difficult?) 」という講演です。
Rubyコントリビューターとしての活動
笹田さんにとって次の事柄が10年になることを挙げ、2014年はRubyコントリビューターとしての節目の年になったと言及しました。
YARVの開発から10年(2004年1月~)
日本Rubyの会発足から10年(2004年7月~)
Rubyist Magazine発刊から10年(2004年9月~)
笹田さんは、Herokuでまつもとゆきひろさんのチームに所属し、フルタイムのRubyコミッターとしてRubyの中核となるインタプリタの開発を行っています。
Ruby 1.9ではYARV・Nativeスレッド・Fiberを、Ruby 2.0ではFlonum・メソッドキャッシュを、Ruby 2.1では世代別ガベージコレクション(GC)となるRGenGCを開発しました。
現在は、Rubyの次期バージョンに組み込む予定のインクリメンタルGCの開発に携わっています(RubyのインクリメンタルGCについては、Rubyist Magazine 0048号に「インクリメンタル GC の導入 」という記事を寄稿しています) 。コンパイラの性能や並列処理、プロファイルにおける研究にも取り組んでいて、Rubyの性能向上に多大な貢献をしています。
また、Rubyコミュニティでも多くの活動を行っています。日本Rubyの会の理事として過去のRubyKaigiを運営したり、Rubyアソシエーションの理事として2014年には世界中のRubyConfに参加し、Rubyの普及・発展活動に取り組んでいます。
笹田さんの数々の活動はホームページ にまとまっています。
Rubyの改善とトレードオフ
インタプリタ開発者としてのミッションは「インタプリタのクオリティの改善」と笹田さんは語ります。クオリティの改善はトレードオフを招きます。例えば、性能をあげるとリソース消費量の上昇、信頼性や互換性、拡張性の低下に繋がる可能性があります。エンジニアやプログラマはそういったトレードオフのパターンを理解し、考え、打ち勝つ必要があると笹田さんは述べました。
Ruby自体も、言語としての力と読みやすさ・書きやすさのトレードオフに打ち勝って生産性を獲得してきました。現在のRubyが抱える性能面の問題においても言えることであり、生産性と性能のトレードオフに打ち勝つために、笹田さん含め、Rubyコミッターは日々Rubyの改善を続けています。
今回の基調講演では、Rubyに携わっている中で得られた、開発者にとって「簡単なこと・難しいこと」という知見をテーマごとに紹介しました。
シリアル実行性能
Virtual Machine(VM)と最適化、RubyとCの共存について話しました。
簡単なこと
難しいこと
Rubyを動かすVMを、人間が管理しやすいように作ること
C言語との親和性を保つこと
簡単な処理系は、作り始めてから1週間で実装できたそうです。しかし、このVM上でRubyは動かなかったため、命令を徐々に追加してYARVを開発したとのことです。
すでに存在していたRubyのテストスイーツをすべて動かすことをゴールとして作業を進めました。この作業は非常に大変で、テストフレームワークがRubyで書いてあるため、そもそもテストが動かないという問題に陥ったそうです。テストが全部最後まで実行できた時は達成感を感じたと当時の心境を語りました。
今後の展望として、アグレシッブな最適化の実施やソースコードをCで書き直すことの可能性、LLVMの導入やRubyとCをうまく混ぜる仕組みを作ることなどを検討しているそうです。
パラレル実行性能
マルチスレッドやRubyでの並列プログラミングの展望について話しました。
簡単なこと
難しいこと
スレッドプログラミング
並列プログラミングのデバッガ
マルチスレッドでは各スレッドがすべての状態を共有しています。複数のスレッドから一つの状態を触ると意図しない状態を触る可能性があるため、必要な同期をしないといけません。もし一個でも忘れるとバグになります。
Why Threads Are A Bad Idea (for most purposes) によると、スレッドプログラミングはウィザード級の能力が必要という話があります。同期を意識したプログラミングも大変ですが、バグの再現ができない場合があるため、デバッグもしづらいです。スレッドプログラミングで大変な経験した結果、Rubyを書くのがつらくなり、Rubyが良くないのではないかと感じることは避けたいと話していました。
Rubyのマルチスレッドプログラミングでは、スレッドを使うのではなくforkをして別プロセスを起動することで状態を共有させない並行処理を使うことができます。これを促進するためにプロセス間通信(IPC)をもっと良くするという改善の方向性があります。他にも、複数のVMを利用したり、サブセットのような小さなインタプリタを用意して並列処理を実行するという案も検討しています。
すべてのオブジェクトがオーナースレッドを持ち、それ以外のスレッドでオブジェクトにはアクセスさせないような制限をする方式も検討していて、「 安全な並列スレッドを提供できないか、すごく面白いと思うので誰か一緒に考えてくれたらなと思います」と述べていました。
そして、普通の人でも並列プログラミングをより使いやすく提供するモデルを探すことをに力を入れていくそうです。デバッガについても様々な提案や研究がされていて、それをきちんと実装していくとのことです。
ガベージコレクション
Rubyのガベージコレクション(GC)開発について話しました。
簡単なこと
難しいこと
GCアルゴリズム以外の処理のケア
バグの検出や修正
GCアルゴリズムを修正したり使うためには、インタプリタ全体を見直す必要があると言います。互換性に絡んでどうしても適用できないアルゴリズムもあり、その度にインタプリタ全体を見直しながらの修正を繰り返しているそうです。世代別GCを導入した時も、Write Barrier(WB)をCの拡張ライブラリに適用できず、新しいアルゴリズムを発明することでRuby 2.1に組み込めたとのことです。
GCのバグは非決定的なところがあり再現が難しいため、GC.stress
を使ってたくさんGCを発生させることで再現する場所を特定しました。世代別GCでは、WBを入れ忘れると起こりえることで発生するケースを確認する仕組みを入れて対応した結果、バグを発見することができたと述べていました。
なお、Ruby 2.1ではGC.verify_internal_consistency
という機能が追加されたため、GCのバグかなと感じた時に利用すると何か分かるかもしれません。
計測
Rubyの性能の測定の話をしました。
性能の計測には物理環境が有利な場合があります。しかし現実では、測定したいOSやCPUアーキテクチャを揃えられていないため、実施環境の確保に苦心しているそうです。計測に利用するアプリケーションについても同様の発言をしていました。
指標には、起動時間を含めるかどうか等、基準を変えることで計測時間のずれが発生することがあります。また、その他の指標としてメモリ使用量が使われることも多いですが、メモリ使用量は何かしらの要因で上下するため、どのタイミングを指標として用いるべきかといった点は判断が難しいらしく、「 いい知見がある人がいたら教えていただけると」と会場全体に意見を求めていました。
開発者コミュニティ
コミッターになるきっかけや、開発者としての心構えを話をしました。
信頼できる人できちんと目的があれば、まつもとさんからコミット権をもらうことができるので、Rubyコミッターになることはそんなに難しくないそうです。その代わり、Ruby開発者であり続けるためには、モチベーションを持ってメンテナンスを続けていく必要があるため難しいとのことです。
また、雇用の問題もあり、「 Ruby開発者は増えてほしいが、Herokuのように、Rubyの開発を支援してくれる企業はまだそれほど多くはない。そのような会社が他にも増えるといい。Ruby自体の開発や新しい技術について挑戦したり考えたり実践したり、そういうのが好きな人がRubyプログラマにはたくさんいると思う。ぜひ一緒にやってもらいたい」と述べていました。
ちなみに笹田さんがRubyコミッターになったのは、『 Ruby Hacking Guide』を読んだことがきっかけだそうです。また、Rubyの中身を知るための資料として『Ruby Under a Microscope』も紹介していました。
そして、多くのRuby開発者のために、笹田さんも資料を提供する意味でもっとコミュニティに対して貢献していきたいと言います。開発者がモチベーションを維持する活動として、ブログやミートアップ、論文での新技術への取り組みや、SNSや開発者会議、カンファレンスへ参加し議論することを推奨していました。
開発者へのメッセージ
最後に、Ruby開発者への向けて次のメッセージを述べました。
We are facing with large blue ocean yet.
Join us for your profession and fun!
そして、「 まだまだやることたくさんあります。難しいところを紹介しただけでまだ手がついていないところはたくさんあるので、職業的な理由、もしくは楽しみのためにご参加いただけないかなと思います」と、会場に集まった多くの開発者へ向けて熱いメッセージを伝えていました。