こんにちは、2024年に新卒で入社し、ジョブハウスでバックエンドエンジニアをしているププです。本記事では、2日目のMaxime Chevalier-Boisvert(@maximecb)さんによるセッション、Breaking the Ruby Performance Barrierについて紹介させていただきます。
Breaking the Ruby Performance Barrier
YJITはRubyのパフォーマンスを改善するため開発されているプロジェクトです。このプロジェクトの開発にはさまざまのベンチマークでの実験が何回も行われ、改善されてきています。おかげでRubyだけでなく、GitHubもYJIT3.3をデプロイして、パフォーマンスを改善する事ができました。
その後、超音速機に例えて、Rubyのパフォーマンスの話が展開されました。超音速機の場合は音の障壁ですが、Rubyの場合はパフォーマンスが障壁となります。これらの障壁を越えるためには、デザインを考え直すことが必要です。
Rubyと同じインタプリタ言語の例として、Pythonが挙げられます。Pythonのパフォーマンスを改善するアプローチとして、プログラムのボトルネックになっている箇所を、C言語で書き換える、という事が考えられます。
ただ、Rubyの開発においては、同様のアプローチはすでに効果的でない事がわかっています。
そのため、YJITの開発者はRubyをさらに改善するために自分の考え方を改めました。PythonやRubyはCより高級の言語で、直接コンパイルはせず、インタプリタが必要です。Cのように機械語と直接関連がないため、少し遅くなります。
しかし、YJITの一部はコンパイラであるため、機械語と直接関連ができ、パフォーマンスの改善ができます。
詳しくは、以下の記事を読んでください。
YJITのおかげで、現在、pure-rubyのgemの開発がいくつか行われています。
redis-clientの一つのドライバーやTinyGQL(GraphQLのパーサー)もありますが、ProtoboeufというGoogleのProtobufの代わりのプロトタイプが最近できました。
このProtoboeufは、デコードについてはProtobufより優れたパフォーマンスを発揮します。
一方で、エンコードについてはProtobufのパフォーマンスの方が優れており、今後改善していく予定とのことです。
では、さらにProtoboeufのパフォーマンスを改善するには、どうすれば良いでしょうか？
その実装がRubyで行われていることから、YJITのパフォーマンス改善をProboeufに合わせて行うことで、改善するアプローチが考えられます。YJIT、ProtoboeufのリポジトリオーナーがShopifyであることから、このアプローチは些か身勝手に見えるかもしれません。しかし、この開発は結果的に、YJIT、およびRuby全体への速度改善をもたらすものであり、利己的な体制ではありません。そもそも、ProtoboeufのデコードはYJITを無効にしてもProtobufより早く、YJITに依存せずともパフォーマンスが改善されていることがわかっています。
最後に、YJITについて気になる方に向けて、URLをいくつか紹介してくれました。
感想
プログラミングや飛行機など、一見関係がないように見えるエンジニアリング分野でも、意外と似たような問題があります。 様々な分野を参考にして自分のプロジェクトを改善しましょう。
Techouseでは、社会課題の解決に一緒に取り組むエンジニアを募集しております。 ご応募お待ちしております。 jp.techouse.com
