RubyKaigi 2018 速報!!(3日目)

こんにちは! Speeeで開発基盤ユニットのサーバーサイドエンジニアをやっている森岡 (@selmertsx)です。RubyKaigi 3日目のレポートをさせていただきます!

Parallel and Thread-Safe Ruby at High-Speed with TruffleRuby

speakerdeck.com

さて、最初のセッションは@eregontpさんから、TruffleRubyを高速で実行しつつ、ArrayやHashをスレッドセーフに利用できるようにしたお話でした。

@eregontpさんは、セッションの中で No need to rewrite applications in other languages for speed とおっしゃっており、既存のRubyコードを書き直さなくともスレッドセーフの恩恵を受けられるようになるとのことです。この機能は今年の夏頃にmasterに入る予定とのことで楽しみですね!

個人的にはTruffleRubyが、Rubyにおける Google JavaScript V8 Engineのような存在になりたい という言葉が非常に印象に残ったセッションでした。

Grow and Shrink – Dynamically Extending the Ruby VM Stack

続きまして、@sugiyama-kさんと@duerstさんから、スレッド毎のスタックスペースを1MB固定ではなく、それより小さい値から必要になったときに動的に獲得しにいく仕組みについてのお話でした。

call stackをlinked listに、internal stackを stretch listにすることで、メモリ使用率が30~40%程度削減され、速度は6%程度遅くなった とのことでした。実装はこちらになります。

今回発表された@sugiyama-kさんは青山大学院の大学院1年生とのことで、インターンシップ先を探しているとのことです!

The Method JIT Compiler for Ruby 2.6

C language is dead と名言を残された@k0kubunさんから、Ruby 2.6のpreview版で導入されたJITコンパイラの最適化手法についてのお話でした。

speakerdeck.com

性能の評価はoptcarrotで行っていて、JITオプションで起動することによって、ruby2.6と比較し2倍ほど早くなっておりました。しかしながら、Railsのベンチマークではむしろ遅くなっており、セッションの中ではこれらの仮説検証を詳細に説明していきます。

原因については、optcarrotよりもRailsベンチマークのほうが実行されるメソッドが分散しており、JIT化されたコードが大量にできると遅くなるということでした。その問題を避けるために、methodをインライン化する必要があり、inline化したRubyのコードを呼び出したところ、Cの2倍ほど早くなる という結果が得られました。ここから C language is dead という名言が生まれました。

なお、Ruby2.6.0-preview2には、並列実行の際に問題が発生することがあるとのことで、本番でのJIT運用はまだお控えくださいとのことでした!

LuaJIT as a Ruby backend.

speakerdeck.com

@take-cheezeさんから、LuaJITのエッセンスを学んでmrubyに活かそうと試行錯誤されたお話でした。LuaJITは動的型付け言語のJITの中では、V8に匹敵するほど高速なものとのこと。mrubyとLuaは非常に似ている部分があるとのことで、mrubyにも活かすことができると思い、調べ始めたとのことでした。

セッションの中ではLuaJITの良さについて詳細にお話されており、RubyKaigiのセッションの中では非常にめずらしいものでした。他の言語の良いところをRubyに持ってくる というのは2日目のKeyNoteをされていた@kouさんや、3日目のVM stackのお話をされていた@sugiyama-kさんと@duerstさんも行われており(linked listはluaで採用されていたもの) 、これからもますます盛んになっていくのではないかと個人的には考えていて、すごくためになるセッションでした。

How to get the dark power from ISeq

発表スライド: http://youchan.org/RubyKaigi2018/

@youchanさんより、ISeqのドキュメントを作ろう!というお話でした。ISeqとは、コンパイラとRubyVMの間にいるもので、バイナリやRubyコードを、Rubyインタプリタが実行できる形に変換する役割を持っています。

ISeqを使うことによって、 他の言語で作成されたバイナリがRubyVM上で動くようになったり、VMを変えていろんなプラットフォームで動かすことも可能 です。@youchanさんはドキュメントを作ることによって、これをもっと便利にできる環境を作りたいと考えておられるようでした。それによって、 erlangに対するelixirみたいな、Rubyの方言がたくさん作られるようになったら良いですよね とのこと。Rubyの可能性を広げるめちゃくちゃ熱い話でした!

TRICK 2018 (FINAL)

さて、今回が最後となった超絶技巧プログラミングコンテストTRICK。 今回も常人には理解できないコードがたくさん出てきました。

優勝は、kinabaさんから予約後だけで行ったプログラムでした!

alias    BEGIN    for      unless   def      class
super    true     or       return   defined? next
break    while    begin    undef    do       end
rescue   then     retry    else     undef    module
nil      ensure   case     if       yield    __LINE__
self     and      redo     elsif    not      __FILE__
alias    END      in       end      when     __ENCODING__
end      until    false    end

このコードではaliasが2回、endが4回使われています。kinabaさんいわく、 理論的にはどれか1つは減らせる とのことですので、みんなこぞって探しましょう。

個人的に一番笑ったのは、tompngさんの "Best double meaning" 賞に受賞したコードでしたw このコードは一見なんの変哲もないFizzBuzzのコードなのですが、コードから全角スペースを取り除くと、ちょっと異なる挙動をします。tompngさんいわく「スペースを有効活用して、見栄えと動作を分離することに成功している。空白に本当に実行したいプログラムをエンコードして隠している。」とのことです!空白スペースの可能性を感じましたw

優勝されたkinabaさんの、「このような遊びをみんなが楽しめるようになってきて、Rubyという言語が音楽や短歌のように、文化的に成熟してきたことを感じる。」といういい言葉で〆られました。

Closing Session

最後は松田明さんからClosing Sessionになります。3日間続いたRubyKaigiもこれで終わりです。

f:id:selmertsx:20180602180015j:plain

今回は今までで最大のRubyKaigiになったとのことで、1017人の参加者、71企業がスポンサーになりました。松田さんは、なぜこんなに大きなイベントになったのかと考えたときに、RubyKaigiはトークが良いのはもちろん、コードを書いているRubistのためのイベントであるからだと仰っていました。

最後はRubistのためのイベントらしく、 コードをたくさん書こう! という言葉で締めくくられました!いい言葉ですね!

最後に

RubyKaigi1、2日目の速報は、それぞれ @nyamadori@__mnc90が書きました。こちらも合わせて御覧ください!

tech.speee.jp

tech.speee.jp

最後にちょっとだけ、弊社Speeeの宣伝をさせてください!今回のRubyKaigiですが僕たちエンジニアは業務として参加しました。 移動費、宿泊費は会社負担、土曜日も休日出勤扱い になっています。弊社Speeeでは、エンジニアが技術力をつけるための勉強会については本人が業務に活かせると判断するのであれば、基本的に業務扱いにしてくれます。

もし、弊社にご興味を持っていただけましたら、弊社でやっているイベント(直近だと6/16のもくもく会など)にお越しいただければと思います!

それではまた、次回は福岡でお会いしましょう〜