CPUの世界では、内部の機構をフロントエンド(命令フェッチとデコード)とバックエンド(命令実行とメモリ)で分けることができます。つまりrailsbenchの実行においては、フロントエンドの処理がバックエンドの処理に対して間に合っておらず、全体としてCPUの性能を使い切れていないことになります。 また、RubyのプログラムとYJITが生成したコードの行き来(ジャンプ)が頻繁に行われていました。このジャンプが多いということは、それだけ実行のために参照するアドレスが多く、結果としてコードの実行パスが増えてしまいます。その結果、予測が失敗したパス(汚染されたパス)が大量に増えて、投機的実行の予測精度に影響を与えていました。 加えて初期のYJITでは、この汚染されたパスもコード生成に利用していたため、さらに問題を悪化させていました。 これらが原因となり、初期のYJITではrailsbenchのパフォ
![Alan Wu氏「YJITはRubyプロセス実行から終了まで全体のパフォーマンス向上を目指す」 ~RubyKaigi 2022 3日目キーノート | gihyo.jp](https://cdn-ak-scissors.b.st-hatena.com/image/square/0a3cce846b5baabec5d7f087536b9f09ac749716/height=288;version=1;width=512/https%3A%2F%2Fgihyo.jp%2Fassets%2Fimages%2Farticle%2F2022%2F10%2Frubykaigi2022-3%2Fimgs%2F0_title.jpg)