RubyKaigi2017 3日目を振り返ってみて② #RubyKaigi2017

2017年10月4日 更新 
ドリコムのサーバサイドエンジニアの hayabusa333 (橘田)です。

9/20に開催されたRubyKaigi2017の3日目を印象に残ったセッションを中心にレポートします。

Introducing the Jet Programming Language @i2y_

上記のセッションに関しましては事前資料としまして、下記のgistの内容がまとめられておりました。

今回のセッションで話されますJETの実装に関してもgistのリンク先にありますので確認することができます。

https://gist.github.com/i2y/849a544ba8dc6f626644ee22e97a8e6e



単一CPUの性能は頭打ちであり、処理をより早くしていくためには複数のCPUにて処理を分散化する必要性がでてきます。

しかしRubyやPythonなどの言語ではGlobal Interoreter Lockがあり、最終的にはシングルスレッドになってしまいマルチコアで処理をするのは難しいため、問題がでてきます。



上記を解決するためにあげられていたのが下記の3つになります

- Ruby-likeな言語を使用する

- 他のRuby言語実装を使用する

- Ruby自体を直す



上記の解決策の中で発表者の方はErlangVMを使用している言語に着目をおきまして、ErlangVMを使用している言語のなかでもReiaを押しておりましたが、Reia自体は開発が止まってしまっており、そこでReiaのオブジェクト指向を強く押している思想とErlang自体の速度に近い速度を出せる思想を受け継いだJETを作成したようです 。



JETの設計方針としては下記の方針を元に設計しております

- イミュータブルデータ

- パターンマッチング

- 軽量プロセス

- モジュールはErlangのモジュールとして扱える
(Rubyのモジュールとは違うため完全な互換性があるわけではない)

- Erlangのコードは使用出来る

- Ruby Like なシンタックスとオブジェクト



JETがRubyと違うところは下記の方針のところです

- Jetはメソッドの引数がある場合はカッコで囲まなければいけない

- クラス継承をサポートしていない。Mixinがその役割を持っているから

- ブロックを引数として渡すことができる



今後の展望としては下記の内容を考えていらっしゃるようです。

- Dialyzerをサポートする - 実装をよりよくしていくこと

- ドキュメントの拡充

- よりRubyらしくしていく



@i2y_さんは今後もJETの更新を行っていき、よりJETをよくしていくとのことでしたので今後の更新が楽しみでもあります。 またJETに興味がある方の協力を求められていましたので興味のある方は参加してみるのも楽しいかもしれません。

Towards Ruby 3×3 performance @vnmakarov

RubyKaigiの最終keynoteは、@vnmakarovさんのkeynoteとなります。

RubyKaigi最終日のkeynoteは技術的に濃いセッションが行われており、難しい内容でもありますので間違いなどあるかもしれませんが記載していきたいと思います。

MatzはRuby3 にて3倍早くするという目的を設定して、それにむかってみんなが動いています。

@vnmakarovさんは、Stack Instructions ではなく、RTL Instructionsにて高速化を目指して実装を行っているようです。 RTL Instructions では memory trafficが少ないなど、メリットがあるようです。

RTL Instructions に変更することによって27%ぐらいの速度の改善が行えているようで、こちらはmake checkまでは実行可能な状況となっているようです。

また、JITに関しては下記の3種類の方法をRubyに当てはめることができて、それぞれメリットやデメリットがあります。



自分で書く

 - フルスクラッチで全部書けば全てを制御でき、小さくまとめられて高速にコンパイルできる

 - 時間がかかりすぎて時間がたりない

 GCC/LLVMみたいな最適化コンパイラを使う

 - よく最適化されていて、ポータブルでテストされてて新たな依存がない

 - コンパイルが遅い



既存のJITを使う

- JVMなどは安定しているがGCCより遅い

- ライセンス・特許などの問題がある

上記にて、GCCを使っての最適化をすることによって速度の向上を行っていくようです。

MJITによって3倍近い速度の改善が行われているようです。

しかもメモリの使用量もそれほど変わっていないというおまけがついてきております。

しかし、MJITは開発中であり make testまでしか動いていないため、より速度の向上であったり、ブラッシュアップを行って成熟していくためには最低でも1年以上はかかってしまうようです。最低でも1年という時点でもすごいです。



次回のRubyKaigi2018が仙台で5月末に行われるとのことなので、その時点では成熟はしきっていないかもしれませんが、より詳しい情報が出てくるかもしれず、楽しみな状況で今回のRubyKaigiはClosingとなりました。

三日間の開催、関係者の皆様、スピーカーの皆様、参加者の皆様本当にお疲れさまでした。

関連記事