RubyKaigi 2018 3日目のメモです。
1日目
2日目
Keynote
Truffle Ruby のパフォーマンスを示すデモと内部で行っている最適化の説明、そしてパフォーマンスを落とさないスレッドセーフなArray/Hashの実装について。
JVM の立ち上がりの遅さと JIT が効いた後の劇的なパフォーマンス向上が見て取れるデモは色んな意味で面白かった(果たして人類は160FPSのゲームをプレイできるのだろうか)
今の CRuby ではrb_ary_map
をインライン化できないというのは、まあそうだよな、と。これ結構致命的な差分だけで CRuby はどうするのかと思っていたら午後に答えが出ることに。
Grow and Shrink - Dynamically Extending the Ruby VM Stack
現在の CRuby はスレッド毎にスタック用の領域が固定長(デフォルト1MB)で確保されるが、これは無駄なので初期サイズを小さめにして動的に伸ばせるようにしたという話。
開発/デバッグのやり方について、「SIGSEGVの発生では具体的な要因の特定が難しいのでmprotect
を使った」とあり、これは参考になりそうだなと思った。
ところでWebアプリケーションのようなケースでは再帰回数は概ね定まりそうなので、動的に伸ばすよりもむしろ2日目の発表であったenv_mem
のように事前にプロファイリングして最適なスタックサイズを決めるというのもアリな気がした。
The Method JIT Compiler for Ruby 2.6
2.6で入る MJIT の現在のステータスと今後の展望について。Optcarrot では速くなったのに Rails では遅くなったので、その原因の調査と解決方針についても。
「C呼出しが悪いならいっそRubyにしようぜ」という締めは非常に前向きで明るい展望だと感じた。Rubyで書けるならそれに越したことはないので……
LuaJIT as a Ruby backend.
スクリプト言語処理系の中でも爆速と名高い LuaJIT の紹介と、それを mruby のバックエンドに使おうとしている話。 発表の大部分が LuaJIT の説明に当てられていたが、詳しい話を聞いたことはなかったので良い機会だった。
C 呼出しを跨ぐと遅くなるのは MJIT に限った話ではないようだが、libffi を使うと(?)速くなるというのはどういうことなのだろうか。
How to get the dark power from ISeq
一応触ることはできるものの中々自由には扱えない CRuby の Instruction Sequence を解析して自由に使えるライブラリまで作った話。
iseq_builder
を見ると夢があるなぁと思いつつ、かなり頻繁に VM 命令に変更が入っているのを見ると internal なものに留めたいという気持ちもわかるので、なかなか悩ましい。
Three Ruby performance projects
CRuby の高速化について。Float の内部表現改善、YARV 命令から RTL への変換、そして新たな中間言語の開発とそれを利用した JIT の3本立て。
Float の内部表現改善についてはきちんと実装を確認できてないが、なんなら2.6にも入っていいのでは思わされた。
MIR と JIT の実装はなんというかもう流石の一言。JVM や WASM にも適用したいというかなり壮大な計画も有るようだが、ある程度は本当に実現されそうなのが怖い。
TRICK 2018 (Final)
3回目の役に立たないへんてこ Ruby コード選手権結果発表。今回のスケジュールの中でも5本の指に入るくらい楽しみにしていたセッション。
発表中はご多分に漏れず爆笑したり変な声を挙げたりし続けていたが、個人的には sort 形式を変え続けるプログラムと、1位の予約語 only コードが好き。Most reserved award という賞名はてっきり優勝が予約されていたのかと思ったら。
ということで今年も大変濃厚で刺激的な3日間を過ごさせていただきました。スタッフ・スピーカーの皆様ありがとうございました。