RubyKaigi 2023 参加記 #3 - "Ractor" reconsidered (Day1)

こんにちは！Engagementでエンジニアをしている渡邉(@eityans)です！RubyKaigiに参加しています！

RactorはRuby3.0から導入された並列処理を実現するため抽象化されたインターフェースです。Ractorの登場により、並列処理に興味を持った方も多いのでは無いでしょうか。たらい回ししました？

このセッションでは、笹田さんよりRactorの現状と課題、および将来の展望についての説明がされていました。

具体的な資料は公開されているので、詳細はそちらを見てもらいつつ、ここでは概要を説明していきたいと思います。

https://atdot.net/~ko1/activities/2023_rubykaigi2023.pdf

現状のRactorが抱える課題

講演は、現在のRactorが抱えている難しさや、課題の説明から始まりました。

現時点で、開発者の目線ではRactorシステムは広く使われておらず、その理由としていくつかの使用上の困難や問題があると述べていました。順番に説明していきたいと思います。

RactorAPIの難しさ

Ractorは、原則として、Ractor間のオブジェクトの共有を行いません。この思想のおかげで並列処理を実現させているのですが、その代わりに実装側で大きな制約が加わります。この制約に追従しているgemは多くなく、Ractorを用いた実装をさらに難しくしている状態になっています。

Ractor自体の実装の難しさ

Ractor自体の開発が難しいという課題も説明していました。現在の開発ではCIが数日に一度落ちてしまう状態で、デバッグが難しい問題が述べられていました。このあたりの取組については、以下のブログで詳しく紹介されています。

Ractorのパフォーマンス

一番課題に感じていると言っていたのがパフォーマンスの問題でした。

tarai関数を使ったベンチマークでは高いパフォーマンスを誇るRactorでしたが、いくつかの状況ではRactorを利用するとパフォーマンスが遅くなる状況がありました。

これは、Ractorが並列処理を実行するために必要とする処理のオーバーヘッドが多いためです。

具体例として、GCを行うたびに全てのRactorの処理がストップしてしまう（！）ことや、Ractor.selectがO(N)のオーダーになっていることがあります。（詳しくは資料を見てください！）

エコシステム

講演の中で、Ractorに課題がある状況だと、試してみる人が少なく、結果としてフィードバックが少なくなるという悪い循環がおきている話をしておりました。

これを解決するために、まずはRactorの性能を改善することで、トライする人を増やしていきたい、そしてフィードバックを増やしていくことを目指しています。

KeynoteでMatz氏が話ししていた、「パフォーマンスを良くすると、雑多な問題を解決してくれる」という話が思い出されます。

今後の展望

このように、まだまだ課題が残っているRactorではありますが、発表の最後では改善に向けて少しずつ歩を進めている様子が紹介されていました。

具体例として、並列GCという仕組みを導入して、GCのたびに全てのRactorが止まる問題を解決していくことや、MaNyによる改善が期待できる例が上げられていました。

発表の最後で、Rubyを並列処理の選択肢として、Go言語などと肩を並べる存在にしていきたいと語っていました。まだまだ解決すべき課題は多そうですが、今後のRactor、そしてRubyの進化に注目ですね！