ジョン・カーマック、信頼性を高める手段としてのインラインコードをめぐる古い議論を再提起

# ジョン・カーマック、信頼性を高める手段としてのインラインコードをめぐる古い議論を再提起

発生日：2024年10月6日

NeoTechNews編集部

2024年10月6日に再び出回った10年前の投稿によって、ジョン・カーマックのより異色なソフトウェア設計論の一つが改めて注目を集めた。それは、一部のシステムでは、深いコールスタックからロジックを取り出してインラインで配置することで、理解、信頼性、さらには製品の成果まで改善できるというものだ。元資料は、カーマックが2007年に送ったメールを振り返った2014年のコメントであり、単なるスタイル上の好みというより、リアルタイム・ソフトウェアがどのように不具合を起こすかについてのケーススタディのように読める。

カーマックの核心的な主張は、しばしば結び付けられる簡略版の説明よりも限定的だ。関数呼び出しを避けること自体が、本質的にパフォーマンス最適化になると主張しているのではない。むしろ、インライン化の実用的な価値は、開発者に状態の変更と実行順序を直接直視させる点にあると述べている。毎フレーム実行されるコードが、呼び出しの階層、オーバーロードされた演算子、暗黙的な動作に分散していると、パフォーマンスと正確性の中心を担っている場合でさえ、システムの大部分が頭の中で見えないままになり得る。

この論考は、その主張を、彼が直接知っていたソフトウェアと結び付けている。カーマックは、信頼性の極めて高い航空宇宙システムに関する議論について説明し、その中には、サーブ・グリペンの飛行ソフトウェアではメインループを除き、サブルーチン呼び出しと後方分岐が禁止されていたとされる逸話もある。彼は、そのモデルを業界全体が模倣すべきものとして提示してはいない。実際、航空宇宙分野のプロセスの多くは一般的なソフトウェアでは逆効果になると明確に警告している。そこから彼が得たのは、より限定的な教訓、すなわち制御フローを単純化すれば、テストと論理的検討が容易になり得るということだ。

続いて彼は、この考え方をアルマジロのロケット飛行制御コードに適用した経験を説明している。メインのtick関数内でサブルーチンをインライン化した後、壊滅的な隠れたバグは一つも見つからなかったものの、変数が複数回設定されている箇所、疑わしい制御フローのパターン、そして最終的なコードをより小さく簡潔にできる機会を発見したという。それが論考全体を貫くテーマだ。インライン配置に価値があるのは、システムが実際に何をしているのかを明らかにするからであり、特に継続的に実行されるコードや、処理の配置ミスによって抽象化だけでは見つけにくい遅延や信頼性の問題が生じ得るコードにおいて有用だ。

カーマックは、2014年の視点から重要な補足も加えている。時間の経過とともに、CやC++においてさえ、純粋関数型プログラミングにより強気になったと彼は述べている。この修正された見方では、本当の敵は関数呼び出しそのものではなく、予期しない依存関係と状態の変更だ。関数型設計は、そこにより直接的に対処する。それでも、プログラムが状態を大幅に変更するのであれば、その変更をインラインで明示することで、コードが行っていることの「完全な恐怖」にエンジニアを直面させ、構造が明確になった後で初めて各部分を純粋関数へリファクタリングできると、彼はなお主張している。

その見解は、危うく問題になりかけた具体的な一例によって補強されている。カーマックによると、『Doom 3 BFG Edition』のリリース作業中、彼が警告していたような、入力サンプリングが1フレームずれることによる遅延を含んだまま、危うく出荷されるところだったという。応答性とゲームエンジンの性能に長年結び付けられてきたプログラマーにとって、この出来事は、隠れた処理順序の誤りが理論上のものではないことの証拠として提示されている。そうした誤りは、経験、抽象化、善意をくぐり抜けて残る。

この文章が今なお共感を呼ぶのは、現代のソフトウェア工学における緊張関係を扱っているからだ。開発者は、モジュール性、表現力のある言語機能、再利用可能なコンポーネントを求める。カーマックの論考は、そうした目標を否定してはいない。そうした道具によって、プログラム内の最も重要な経路が見えにくくなったときに何が起きるのかを問いかけている。ゲームループ、制御システム、その他の時間的制約が厳しい環境では、可読性が、より多くではなく、より少ない間接参照を意味する場合もある。