Gemini saidE-coreの「幽閉」問題。Antigravityがカクつく真犯人は“賢すぎる”スケジューラーだった

・・こんにちは、yukidoujiです。

最近、Google Antigravityで物理演算シミュレータを走らせていると、妙な現象に遭遇します。
CPU使用率は全体的に余裕がある。
GPUも回っている。なのに、ブラウザ上の描画だけが異様に重い。

「メモリリークか？」
「GPUドライバの不具合か？」
あらゆる可能性を疑ってプロファイリングをかけた結果、最新CPUの売りである「ハイブリッド・アーキテクチャ（P-core / E-core）」が、皮肉にも最大のボトルネックになっている可能性が浮上しました。

高効率コア（E-core）という名の牢獄

ご存知の通り、最近のIntel製CPUなどは、パワー重視のP-coreと、省電力重視のE-coreを組み合わせています。
OSのスケジューラー（Intel Thread Director等）がタスクの負荷を見極め、「重い処理はPへ」「軽い処理はEへ」と振り分ける。
これが理想的な挙動です。

しかし、Antigravityのような「ブラウザベースの高負荷処理」において、この采配が裏目に出ることがあります。

プロファイラを凝視していて気づいたのは、Antigravityの物理演算を担う重要なJavaScript実行コンテキストが、なぜか「バックグラウンド処理」や「優先度低」と誤認されている形跡があること。
その結果、本来ならP-coreでブン回すべき重厚な演算タスクが、非力なE-coreに割り振られ、そこに「幽閉」されてしまっているのです。

「CPU使用率 30%」の罠

これがエンジニアにとって一番気持ち悪いのは、「タスクマネージャー上では余裕があるように見える」点です。
P-coreたちは「仕事ないな～」とあくびをしている（アイドリングに近い）状態で、E-coreだけが悲鳴を上げている。
トータルのCPU使用率は低いため、一見するとハードウェアには余力があるように見えますが、実際はシングルスレッド性能の低いコアで重い計算をさせられているため、アプリ側はカクつきます。

「プロセスの優先度」を手動で「リアルタイム」に変えたり、UEFIでE-coreを無効化（！）したりして挙動が変わるのを確認するたび、「インテリジェントなスケジューリングとは一体……」と虚空を見つめたくなります。 OS、ブラウザエンジン、そしてCPUのスケジューラー。この三者が完璧に協調しないと、この「E-core幽閉問題」は解決しない根深いバグです。

人間側のカーネルパニックを防ぐ

そんなわけで、OSのタスク割り振りと格闘しながら、数時間ぶっ通しでデバッグを続けていたのですが、ふと気づくと私の腰の方が限界を迎えていました。
ソフトウェアの最適化も大事ですが、それを直す人間側のハードウェア（腰・背中）がクラッシュしては元も子もありません。

「E-coreにタスクを逃がす」のはOSの勝手ですが、「着座姿勢の負荷を立ち姿勢に逃がす」のは、我々人間にしかできない最適化です。
デバッグが沼った時こそ、物理的に視点を変える（立つ）ことで、意外な解決策が見つかることもありますからね。