Alan Wu氏「YJITはRubyプロセス実行から終了まで全体のパフォーマンス向上を目指す」 ～RubyKaigi 2022 3日目キーノート | gihyo.jp

CPUの世界では、内部の機構をフロントエンド（命令フェッチとデコード）とバックエンド（命令実行とメモリ）で分けることができます。つまりrailsbenchの実行においては、フロントエンドの処理がバックエンドの処理に対して間に合っておらず、全体としてCPUの性能を使い切れていないことになります。 また、RubyのプログラムとYJITが生成したコードの行き来（ジャンプ）が頻繁に行われていました。このジャンプが多いということは、それだけ実行のために参照するアドレスが多く、結果としてコードの実行パスが増えてしまいます。その結果、予測が失敗したパス（汚染されたパス）が大量に増えて、投機的実行の予測精度に影響を与えていました。 加えて初期のYJITでは、この汚染されたパスもコード生成に利用していたため、さらに問題を悪化させていました。 これらが原因となり、初期のYJITではrailsbenchのパフォ

[naosuke2dx]

書きました。言いたいことはすべてまとめに書いてあります。

[pascal256]

あのラストキーノートの解説は本当に助かる…

[asonas]

“そういう意味でRubyKaigiの楽しさやおもしろさを凝縮した、RubyKaigi 2022を締めくくる最高のセッションだったのではないかと思います。”

[onk]

レポート助かる。こういう話だったのか / 「参加者のブログでも、ほとんど触れられていない」

[YaSuYuKi]

初めてYJITの実装の説明を見た時「ポリモーフィズムを駆使すると遅くなりそうだが、実コードではほとんどなかった」とコメントしたが、やはり自分以外でも実コードではほとんどないのは同じだったか

[takayamaki]

optcarrotとrailsbenchでCPUのフロントエンドとバックエンドのどちらがボトルネックになっているのかが違ったために一筋縄では行かなかった、くらいまでしか当日その場では理解できなかったのでとても助かる…

[YassLab]

“つまり最初のメソッド呼び出しで生成されたコードがそのまま再利用可能な確率が非常に高い / インラインキャッシュとの相性がよく、投機的実行にうまく効き、フロントエンド依存なストールに対して非常に効果的”

[katsyoshi]

おおおつかれててまったく頭入ってこなかったけどこういう話だったか