Ruby Kaigi2015 レポート

2015/12/11〜13に行われたRubyKaigi2015に参加しました。
簡単にですが内容をレポートします。 今年は築地市場近くのベルサール汐留で行われました。参加者には握り寿司が出ました!

Ruby3 Challenges

rubyの父Matzのキーノートから始まりました。

Ruby 2.3

まずRuby最新versionの2.3について説明がありました。当日の朝にpreview-2がリリースされ正式版はクリスマス(12/25)にリリースされます。
新機能についての簡単な説明です。詳細はNEWSを参考にしてください

Did you mean?

メソッド名を打ち間違いしてNoMethodErrorが発生した時に正しいメソッド名を推測して提案してくれる機能です

grev_v

正規表現でマッチしないものを取るためのメソッドです。正規表現で否定の記述をするのが複雑になりがちなため追加されました

Hash#fetch_values

指定したキーに対するvalueが存在した場合に配列を返すがvalueが存在しない場合は例外を返します（value_atは例外ではなくnilを返す）

Numeric#positive?, negative?

正の値だったらtrue、負の値だったらfalse

Hash comparison

Hashオブジェクト同士の比較（包含関係）ができるようになった

Hash#to_proc

ハッシュをプロックに変換できる、ブロックに&をつけたハッシュを渡せる

Array#dig, Hash#dig

ネストした配列、ハッシュに一気にアクセスできる

indented here document

ヒアドキュメントの先頭に~をつけると一番インデントが浅いところに合わせてくれる

safe navigation operator

メソッド呼び出しを&.をつけて行うとレシーバがnilかどうか判断して、nilの場合は移行のメソッド呼び出しを無視する(「&.」の見た目が体育座りした人が石っころを見つめているようなので「ぼっちオペレータ」と呼んでいるそう）

performance

2.2に比べると若干早くなっているとのこと。2.0から0.1version upするごとに5〜10％早くなっている

OCaaS

「oss as a shark」。造語で、ossの開発は変化がないと開発者がコミュニティから去ってしまうことからこの言葉を思いついた。
ossの開発には変化が常に必要と考えている（サメは止まると死んでしまう）
rubyは開発した当時、オブジェクト指向を取り入れたスクリプト言語をコンセプトにしていたが、スクリプト言語にオブジェクト指向は入らないと言われていた。
10年経ってそれが正しいと証明され、今ではオブジェクト指向が当たり前になっている

変化の難しさ

ユーザーは何が必要か分からない、未来の状況は分からないから言語のデザインは難しい
言語は他のものに比べて長生きすることもデザインを難しくする要因の一つ。Rubyを開発したのは1995年だが、同じ年に発売したWindows95はもうない
変化することはコストでもある（Railsのversion upのように）
1.9.0と1.8ではでは互換性に問題があって1.9の開発期間は３年だが多くのユーザーが1.9を使うまでに５年程度かかった。でもpython3よりはマシ
機能を全て同時に変えることはせず一つずつ置き換えた。文字列、VM、GC
version upするための移行パスを用意した

1.8から1.9への変化でわかったこと

何もかも捨ててはいけない
劇的な変化は良くない
でも変化は続けないといけない
ユーザーにベネフィットを与えないといけない

Ruby3

Ruby3の開発について、今の時代に合わせてRubyの開発をしていく必要がある

• rubyを開発した当時はシングルコアだったが現在コンピュータの性能を発揮するにはマルチコアに対応する必要がある
• rubyの主戦場がスクリプティングからWebアプリケーションになった。また、Webアプリケーションの規模が巨大になった

Concurrency

Rubyの並列処理モデルとして取り入れたい候補

actorモデル

elixir, scala, Go(Channel+routine)で使われている方法

ownershipモデル

ownershipを持っているスレッドのみ中を見ることができる。 mailboxやキューにメッセージを渡す時にownershipも渡す排他制御のやり方

software transaction memory

clojureで使われている。rubyにこれから導入するのは難しい

streamモデル

時間がないので説明はパス

Performance

Ruby 3x3 ruby3はruby2.0の3倍早くする。並列処理やより良いデータ構造を取り入れることで実現したい
2020年までにはリリースしたい

その他

• パイプラインをプログラムの中に入れたい
• Success Typing(成功型付け）、Elixir（Erlang）がdialyzerで実現していてRubyに欲しいものに近い。
• IBM J9チーム（IBM用JVMを作っているチーム）がJVM開発で培った技術をCRubyに適用してOSSとして公開していくとの発表があった（フォークではなくCRubyとして）

Compiling Ruby Scripts

Ruby Interpreterの開発者である笹田耕一さんからRuby2.3でAOTコンパイルのための機能が入った話しがありました （2.3ではexperimentalで導入されている）

Iseq(Instruction Sequence)の目的は高速起動、メモリ消費量、ポータビリティの削減の二つ。
今回ポータビリティはサポートしない

fast boot

• 事前にpre-compileでバイナリーを作っておいてロードする
• 簡単なrailsアプリケーションでもiseqのsetupにメモリ使用量の20%くらいある、これを圧縮したい
• 将来は複数プロセスでもバイトコードを共有できるようにしたい
• 実行に必要のないメソッドも最初に全てロードするのではなく、必要になった時に初めてロードするlazy loadingを実装

Experiments in sharing JAVA VM Technology with CRuby

IBM JIT開発者のMatthew GaudetさんからCRubyにJITを導入するお話です

IBM Cloudには複数の言語があり、どうやって最小限の努力で複数の言語の性能を向上させるかというミッションがあった。
そこでOMRというオープンソース言語向けのランタイムライブラリを作っている。
OMRにはGCやJITなどたくさんのコンポーネントが含まれていてそこでRubyのJITコンパイラの開発をしている。

IBMはこれからRuby高速化に貢献していき、OSSとして開発していく予定なのでフィードバックを欲しいとのことです
rubyomr-preview github-repository

Linux loves Ruby, Ruby loves Linux

RubyコミッターかつLinux Port maintainerでもある小崎さんよりRubyのデバッグについての話しがありました。
小崎さんは普段、RubyのバグでLinux起因で発生したものについて、Linuxの修正パッチを作って対応しているそうです。

Debug tool

Linuxには便利なデバッグツールが揃っているのにあまり使われていないため今回話したかった。

• Ftrace
• Perf tools
• SystemTap

Ftrace

コンテキストスイッチ、ページフォルトなどのLinuxのイベントが発生した場合に情報を取得できる

Perf tools

• perf top パフォーマンス情報を全て取得できる
• perf trace straceの拡張版、全てのプロセスが読んだシステムコールを取得できる

SystemTap

• Rubyからカーネルのシステムコールまで取れる便利なツール
• この資料を作るためにRubyのコードを調べてる時にRubyのバグを見つけて修正したそうです、さすが。

Rhebok , High performance Rack Handler

メルカリのエンジニアであるmasahiro naganoさんよりUnicornより早いRackサーバを実装したお話です

• unicornより早い(1.5x〜2x早い)
• unicornと同じpre-forkアーキテクチャをとっている
• perlのGazelleというWebサーバを移植している
• リクエストの処理が終わった後にまとめてGCを走らせることができる
• Hot Deployをサポートしている
• TCPでデータを書き込むときにバッファさせないためにTCP_NODERAYを有効にしている
• websocket, streamingには向かない
• http1.1サポート、2はサポートしていない
• Rhebokを使ってフィードバックをして欲しい

Ruby: 2020 how do wo get to Ruby3x3

最終日のキーノートの発表者はRubinus、Pumaの作者であり、RubyCentralの代表でもあるEvan Phoenixです。
Ruby3でどうやって高速化を実現するか提案がありました

Performance

Rubyのコアライブラリは並列化を意識して設計されていない実現するには奇策を取る必要がある。
多くの改善方法の中で、JITを導入するのが一番影響が少なく高速化を実現できる

Dynamic

全ての動的言語は早くない 90%以上のコードが一つのクラスから呼ばれている ランタイムからダイナミックな部分を取り除くことでパフォーマンス向上することができる
動的言語もJITで早くできる

StrongTalk

smalltalkに静的型システムを入れた言語
型は開発者のパフォーマンスを改善しなかった
Sunに買収されて研究の結果がHotSpotVMになった

V8

JSランタイムエンジンの高速化のためにSELFとStrongTalkの技術を使った

LLVM

LLVM IR(中間言語)をYARVから作りそれをLLVMに最適化させる
コアライブラリを事前にコンパイルしてLLVMのバイトコードに変換する

結論

大きな労力は必要なく、JITの利益を享受するにはただコンパイラ最適化があれば良い CRubyは変化が必要で今がその時だ

感想

今年も豪華な発表者をたくさん揃えたRubyKaigiでした（最終日のラストは去年も今年もすごかった）。
今年の特徴はMatzが話したRuby3x3という構想を実現するランタイムの改善案が多かったことでしょうか。
また、初めてRubyKaigiに参加する人も多く（3割以上いた？）Rubyのコミュニティがものすごい勢いで成長しているのを感じました。
そして、来年はなんと京都で3倍以上の広さの会場で行うと発表がありました!9月8日から10日の予定です

スタッフの皆さんお疲れ様でした。