エンジニアリング哲学:John Carmack、道徳的な営みとしてのパフォーマンス

要点
- Carmackはパフォーマンスを最適化の工程ではなく、道徳の問題として捉えます。自分のコードとハードウェアの物理的限界との間に開く差は無駄であり、その無駄は自ら選んだ結果なのです。
- 彼の手法は引き算です。問題を土台から理解し、速くてシンプルな核まで削ぎ落とし、その核を遅くするあらゆる機能を拒む。
- 根底にある問題そのものが変わったときには、ゼロから書き直します。Quakeは、idを有名にしたエンジンを捨て去りました。本物の3Dは、それらしく見せかける3Dとはまったく別の問題だったからです。
- 彼は開かれた場で仕事をしました。毎日の
.planログ、やがてはエンジンのオープンソース化です。その根底にあったのはひとつの信念でした。いずれ公開するコードは、より誠実に書かれるものだ、と。
原則
「光の速さは最悪だ」――John Carmack1
これは冗談であり、同時に哲学のすべてです。Carmackはネットワークのレイテンシ――パケットが大陸を横断する速さに課せられた、動かしようのない物理的な下限――についてこう言ったのですが、その感覚は彼が書いてきたすべての行に通っています。機械は物理法則に支配されており、エンジニアの仕事は、問題が許す限り物理的限界に肉薄することにあります。「十分に近い」ではありません。物理が許す限界まで近づくのです。ユーザーと光の速さとの間にあるものはすべて無駄であり、その無駄はあなた自身が選んだものです。
Carmackはパフォーマンスを最適化の工程ではなく、道徳の問題として扱います。たいていのソフトウェアは、家が散らかっていくのと同じように遅さを溜め込みます――一度にひとつずつ、それぞれは筋の通った判断でありながら、その総和は弁解の余地がないものになる。Carmackの規律は、その積み重なりを拒むことにあります。問題を土台から理解し、速くてシンプルな核まで削ぎ落とし、それを出荷する。同じ信念は、パフォーマンスとは後から足す機能ではなく、失わずに守り抜く性質であるという主張の根底にも横たわっています――遅いシステムを最適化して速いシステムにするのではなく、速いものを作り、それを守り抜くのです。
そして彼は、その過程を公開しました。10年以上にわたって、Carmackは毎日のエンジニアリング日誌――.planファイル――を開かれたインターネットに公開し、fingerクライアントを持つ者なら誰でも読めるようにしていました。2 1990年代で最も難しかった3Dレンダリングの問題が、ほぼリアルタイムに、公衆の面前で解かれていったのです。開かれた場で仕事をすることは、宣伝ではありませんでした。それはコードそのものと同じ本能でした。隠された状態はなく、検証できないものは何もない。
背景
John D. Carmackは1970年8月21日、カンザス州ショーニー・ミッションに生まれました。3 ミズーリ大学カンザスシティ校に2学期間在籍したのち中退し、ソフトウェアを書いて生計を立てる道に進みます。正式な徒弟修業もなく、学位もありませんでした。彼はグラフィックスプログラミングを、デモシーンがそうしたように――ハードウェアのマニュアルを読み、チップが実際に何をしているかを計測し、数字が正しく出るまでアセンブリを書き続けることで――身につけたのです。
彼が職を得たのは、ルイジアナ州シュリーブポートにあった、ソフトウェアとディスクマガジンの会社Softdiskでした。そこでGamer’s Edgeというゲームの定期購読サービスに携わります。ここで彼はJohn Romero、Tom Hall、そして(血縁関係のない)Adrian Carmackと出会いました。1990年9月、CarmackはPCでは不可能なはずのデモを作り上げます。EGAハードウェア上での、なめらかでコンソール並みの横スクロールでした。1990年当時のIBM PCは、フレームごとに画面全体を描き直していました――スクロールするゲームには遅すぎたのです。Carmackの技法、アダプティブタイルリフレッシュは、知る人ぞ知るEGAハードウェアの機能を使って、すでに描かれた画面をずらし、新たに現れた縁だけを描き直すものでした。4 チームはこれを証明するために、任天堂のスーパーマリオブラザーズ3の最初の面をPCデモとして作り直しました。任天堂は申し出を断りました。チームはエンジンを手元に残しました。
1991年2月、彼らはSoftdiskを離れてid Softwareを設立します。型はすでに定まっていました。誰も解いていない問題を見つけ、ハードウェアのレベルで解き、その解の上に製品を築く。Carmackはこれを、テクスチャマッピングされた3Dで、次いで本物のポリゴン3Dで、さらにはバーチャルリアリティで、繰り返すことになります。彼を取り巻く環境――Michael AbrashのGraphics Programming Black Book、デモシーンのサイクル数を数え上げる文化――は、プロセッサを近似するのではなく、正確に理解すべきものとして扱っていました。Carmackはその文化を有名にしたのです。

仕事
Commander KeenとDoom――速い核(1990〜1993年)

Commander Keen in Invasion of the Vorticons(1990年12月)は、アダプティブタイルリフレッシュの上に作られた最初の商用ゲームでした。ゲームとしての意味よりも、ひとつの証明としての意味のほうが大きかったのです――ハードウェアを丹念に読み解けば、汎用PCと専用コンソールの差を埋められるという証明でした。なめらかなスクロールは、上に重ねられたグラフィックスの小細工ではありません。それ自体がエンジンだったのです。
Doom(1993年)は、Carmackの手法を象徴する例です。1993年のPC上で環境を十分速くレンダリングするために、彼はバイナリ空間分割――BSP木――を採り入れました。これは1980年の学術論文で定式化されたもので、Carmackが探し出して応用したのです。壁を描くべき順序を事前に計算しておくことで、エンジンは後から覆い隠されるピクセルを二度と上書きしないようにしました。5 Doomは本物の3Dではありません。十分な工夫で立体的に感じられるよう描き出された2Dマップです。その区別こそが要点なのです。Carmackは最も汎用的なシステムを作ったのではありません。現に存在するハードウェア上で速く動くシステムを作り、核となるループを遅くするあらゆる機能を拒んだのです。速くてシンプルな核を、出荷する。
Quake――ソフトウェアによる本物の3D(1996年)

Quake(1996年)は、ゼロからの再構築でした。Doomが奥行きを見せかけていたのに対し、Quakeは本物の三次元ポリゴン世界――傾いた面、上下を見回す視点、本物のジオメトリ――を、消費者向けの3Dアクセラレータがまだ一般的でなかった時代に、ソフトウェアでレンダリングしました。6 このエンジンは、事前計算したBSPの可視性判定、オフラインのライトマップ、そして手で調整したアセンブリを組み合わせ、当時のCPUには不可能だと常識が告げていたことをやってのけたのです。idは後にOpenGLレンダラーであるGLQuakeをリリースし、消費者向け3Dグラフィックスカードの地位を確立する一助となりました。
Quakeは、Carmackの姿勢の全体が一度に見て取れる仕事です。会社を有名にしたエンジンを捨て去り、新しい問題(本物の3D)を土台から理解し、そして再構築した。再利用のための再利用はしない。それまでの解は神聖なものではなく、神聖なのは問題のほうだったのです。
オープンになったidのエンジンと.planファイル(1997〜2011年)
Carmackは、自分を富ませたコードに対して、ふたつの異例なことをしました。彼は毎日の作業日誌――.planファイル――を公開し、エンジニアリングが進む様子をその場で読めるようにしました。2 そしてエンジンそのものを譲り渡したのです。idは1997年にDoomエンジンを、1999年にQuakeをオープンソース化し、その後も新世代が出荷されるたびに各世代のid Techのソースを公開し続けました。Doom 3やそれ以降に至るまでです。7 彼の主張は明快でした。古いコードを公開すれば、若い開発者たちはそれが実際にどう作られたかを学べるし、「人々が価値を認める自由なソフトウェアは、世界に富を加える」のだと。8
その意志こそ、パフォーマンスに取り憑かれたエンジニアのほとんどが到達できない部分です。Carmackの技は、私的な規律を公のものにしたものでした。読まれることを厭わない姿勢――毎日の日誌を、やがてはソースを、誰にでも検めさせる姿勢――それ自体が品質をめぐるひとつの取引なのです。いずれ公開するコードは、より誠実に書かれるものです。
Oculus VR――レイテンシの下限(2013〜2019年)

Oculusでは、Carmackが生涯にわたって敵としてきたもの――レイテンシ――が、問題のすべてになりました。彼はこう書いています。「ユーザーの頭部の物理的な動きと、ヘッドマウントディスプレイから更新された光子が眼に届くまでのレイテンシは、高品質な体験を提供するうえで最も重要な要因のひとつである」、そして知覚できるヘッドトラッキングのレイテンシは「シミュレーター酔いの主たる原因のひとつでもある」と。9 彼は予算を設定し――目標はモーション・トゥ・フォトンでおよそ20ミリ秒という水準でした――パイプラインのあらゆる段階を、マイクロ秒を取り返すための場として扱いました。彼のタイムワープ技法は、すでにレンダリングされたフレームを表示直前の最後の瞬間に再投影し、レンダリング中に起きた頭部の動きを吸収します。9 これは23年後のアダプティブタイルリフレッシュにほかなりません――再利用できるものは描き直さず、その結果を物理的限界に照らして計測する。
手法
その手法は、30年と4つの問題領域を通じて一貫しています。
問題を土台から理解する。 Carmackはハードウェアのマニュアルを読み、実際の挙動を計測し、慣例ではなく第一原理から仕事を進めます。BSP木も、ライトマップも、タイムワープも、どんな定石にも載っていませんでした。それらは問題が実際に求めていたものから導き出されたのです。
速くてシンプルな核まで削ぎ落とす。 Doomが3Dでないのは、1993年のハードウェア上で3Dに感じさせるのに3Dが必要なかったからです。規律は引き算にあります。内側のループを特定し、それを速くし、それを遅くする機能を拒むのです。
問題が変わったらゼロから書き直す。 QuakeはDoomエンジンを拡張しませんでした。Carmackは、根底にある問題が動いた瞬間に、動いているシステムを使い捨てのものとして扱います。サンクコストは論拠になりません。
深く、途切れない集中。 Carmackのマラソンのようなコーディングは、それ自体を目的とした耐久勝負では決してありませんでした。エンジン全体をワーキングメモリに保持すること――データのレイアウト、内側のループ、エッジケースをすべて同時に――には、読み込みに何時間もかかり、コンテキストを切り替えた瞬間に砕け散ります。彼はその状態を、レンダーループのサイクルを守ったのと同じように守りました。仕事が実際に動く土台となる、希少な資源として。
のちには――Cにおける関数型のスタイル。 Doom 3の時代やそれ以降になると、CarmackはCやC++においてさえ純粋関数を好み、可変状態を最小化するようになりました――流行のためではなく、隠された状態のないコードは挙動を予測できるコードであり、それはバグが減ることを意味するからです。10 これは.planファイルと同じ本能です。検証できないものは何もない。
影響の連なり
彼を形づくった人々
Michael Abrashは、この系譜において師に最も近い存在です。x86グラフィックスについてのAbrashの著述――のちにGraphics Programming Black Bookとしてまとめられました――は、Carmackが実践した、サイクル数を数え、すべてを計測する文化を体系化しました。二人は後にidで、そしてずっと後にOculusで共に働き、Abrashはそこでチーフサイエンティストとなりました。(直接的な影響)
1980年代後半のデモシーンとアセンブリ最適化の文化は、根底にある信念を教えました。プロセッサは正確に知ることができ、自分のコードとハードウェアの天井との差は自分の責任だ、という信念です。(形成的な影響)
John Romeroは、idでの彼の相棒であり、師ではなく補完者でした。Romeroのデザインとレベル制作は、Carmackのエンジンに動かす価値のあるものを与えました。この相棒関係は、速い核が必要条件であって十分条件ではないことを思い出させてくれます――エンジンはプレイされるために存在するのです。
彼が形づくった人々
ゲームエンジン業界の全体。 BSPによる可視性判定、ライトマップ、そして成熟したエンジンのオープンソース化は、標準的な実践になりました。一世代のエンジンプログラマーが、Carmackが公開を選んだid Techのソースを読むことで3Dレンダリングを学んだのです。
消費者向け3Dグラフィックスハードウェア。 QuakeのOpenGLパスは、3Dアクセラレータカードを支持する初期の商業的な論拠となり、GPUを主流のPCへと引き上げる一助となりました。
現代のバーチャルリアリティ。 タイムワープと、レイテンシ予算への執拗なこだわりは、いまやあらゆるVRパイプラインで標準的な語彙です。Carmackが追い求めた20ミリ秒という目標こそ、今日のヘッドセットが人を酔わせない理由なのです。
貫くもの
Andrej Karpathyがニューラルネットワークをゼロから作り直すのは、理解は譲り渡せないものだからです――自分で導き出すしかない。Carmackも同じやり方でレンダラーを導き出します。フレームワークからではなく、ハードウェアと問題から。そしてLinus Torvaldsが「良いセンス」――特殊ケースが一般ケースへと溶け込む、あの感覚――を重んじるのに対し、Carmackは物理が許す限り最小の仕事しかしない内側のループを重んじます。両者は、違う服をまとった同じ信念です。正しい構造は問題の上に施す装飾ではない。それは、正しく見られた問題そのものなのです。(シリーズの架け橋)
ここから受け取るもの
私が忘れずにいる教えは、パフォーマンスとは誠実さだ、ということです。遅いシステムとはたいてい、その作者が問題を十分に理解できず、速い核を見つけられなかったものです――彼らは動くまで抽象を積み重ね、「動いた」ところで手を止めました。Carmackは代わりに物理的限界で手を止めます。それは品質こそが唯一の変数であるという基準と同じものです。問いは決して「これは出荷できるほど速いか」ではなく、「なぜこれがこれほど遅いのか、自分は本当に理解しているか」なのです。
私がいま身を置く世界――エージェント、ツールのループ、AIシステム――では、誘惑はCarmackの規律とは正反対です。フレームワークを積み重ね、モデル呼び出しを増やしてレイテンシをごまかし、システムが実際に何をしているかを決して読まない。Carmack流のやり方は、ループをプロファイルし、支配的な部分を見つけ、それを土台から理解し、残りを削ぎ落とすことです。その信念――センスとは測定できる技術的なシステムであって、言い張る雰囲気ではない、という信念――こそが、1990年のEGAスクロールの妙技から2026年のエージェントハーネスまでを貫くものなのです。
FAQ
John Carmackのエンジニアリング哲学とは何ですか?
Carmackはパフォーマンスを後回しの事柄ではなく、道徳の問題として扱います。その規律とは、問題を土台から理解し、速くてシンプルな核まで削ぎ落とし、その核を遅くする機能を拒み、根底にある問題が変わったときにはゼロから書き直すことです。彼はこれを、開かれた場での仕事――毎日のエンジニアリング日誌の公開と、成熟したエンジンのオープンソース化――と組み合わせています。検証できるコードは、より誠実に書かれるという信念に基づいて。28
John Carmackは何を作ったのですか?
Carmackは1991年にid Softwareを共同設立し、Commander Keen(1990年、アダプティブタイルリフレッシュ)、Wolfenstein 3D(1992年)、Doom(1993年、BSPベースのレンダリング)、Quake(1996年、本物の3Dソフトウェアレンダリング)のリードプログラマーを務めました。彼は20年にわたってid Techのエンジンをオープンソース化し、Oculus VRのCTOとしてモーション・トゥ・フォトンのレイテンシの仕事を牽引し、後にAI企業Keen Technologiesを設立しました。5679
アダプティブタイルリフレッシュとは何ですか?
これは、IBM PCのEGAハードウェア上でなめらかな横スクロールを実現するために、Carmackが1990年に考案した技法です。EGAハードウェアはフレームごとに画面全体を描き直すため、本来はスクロールには遅すぎました。アダプティブタイルリフレッシュは、EGAハードウェアの機能を使ってすでに描かれた画面をずらし、縁に新たに現れたタイルだけを描き直すことで、フレームごとの作業量を劇的に削減します。これがCommander Keenを可能にし、Carmackの代名詞となる手口を確立しました。ボトルネックをハードウェアのレベルで解く、という手口です。4
なぜCarmackは.planファイルを公開し、エンジンをオープンソース化したのですか?
.planファイルは毎日のエンジニアリング日誌で、もともとはfingerプロトコル経由で読めるものであり、idの開発をほぼリアルタイムに記録していました。2 Carmackは後に、各世代のid Techをその後継が出荷されるたびにオープンソース化しました。古いコードを公開すれば、新しい開発者たちがゲームが実際にどう作られているかを学べるし、価値ある自由なソフトウェアは「世界に富を加える」のだと論じて。8 このふたつの実践は、彼のコードと同じ原則を映し出しています。隠された状態はなく、検証できないものは何もない。
出典
-
John D. Carmack, “The speed of light sucks.” Wikiquote, ネットワークレイテンシについて。彼のQuakeWorld時代のネットワーク関連の仕事から広く引用されている。Data Center Knowledgeでの議論も参照。 ↩
-
Robbie, “The Carmack Plan,” Garbage Collected, 2017年10月――
.planファイル、fingerプロトコル、そして開かれた場で仕事をすることについて。oliverbenns/john-carmack-planにアーカイブされたログは1996年から2000年代にまで及び、この実践が複数年にわたって続いたことを記録している。 ↩↩↩↩ -
“John Carmack.” DoomWiki. 1970年8月21日、カンザス州ショーニー・ミッション生まれ。ミズーリ大学カンザスシティ校、Softdisk、id Software設立。 ↩
-
David Kushner, Masters of Doom: How Two Guys Created an Empire and Transformed Pop Culture (Random House, 2003), 第3章――Carmackのなめらかなスクロールのブレークスルーと、一晩でのスーパーマリオブラザーズ3の再現を、1990年9月のSoftdiskでの出来事として位置づけている。Romeroの協力者John Andersonの「The Saga of Dangerous Dave」によって裏づけられており、こちらは「Dangerous Dave in Copyright Infringement」を1990年9月としている。技法の詳細:「Adaptive tile refresh,」 Wikipedia、およびFabien Sanglard, 「Commander Keen’s Adaptive Tile Refresh.」 ↩↩
-
“Doom rendering engine,” DoomWiki――BSP木は1993年5月のアルファ版と1993年10月のベータ版の間に採り入れられた。セグメントクリッピングによる上書き描画の排除。技法の起源について:Sinclair Target, “How Much of a Genius-Level Move Was Using Binary Space Partitioning in Doom?,” Two-Bit History (2019)――BSP木をHenry Fuchs、Zvi Kedem、Bruce Naylorによる1980年の論文「On Visible Surface Generation by A Priori Tree Structures」(およびその1969年の米空軍フライトシミュレーターの前身)まで遡り、CarmackがそれをDoom向けに応用したことを記録している。 ↩↩
-
“Quake engine.” Wikipedia. ソフトウェアによる本物の3Dポリゴンレンダリング(1996年)、事前計算された可視性、ライトマップ、Cとアセンブリで記述、後のOpenGLパス。 ↩↩
-
“id Tech,” Wikipedia――ソースの公開を記録:Doomエンジン1997年(1999年にGPLへ再ライセンス)、Quakeエンジン1999年、Quake II 2001年、Quake III 2005年、そしてDoom 3(id Tech 4)エンジンが2011年で、これが最後のGPL公開。概観:“A graphical history of id Tech,” PC Gamer. ↩↩
-
Brad Cook, John Carmackへのインタビュー, Apple.com(アーカイブ済み), Wikiquoteに引用。「コードを共有することは、ただ正しいことのように思える……人々が価値を認める自由なソフトウェアは、世界に富を加える」。次も参照:TechRadar, “id’s John Carmack sings praises of open source.” ↩↩↩
-
John Carmack, “Latency Mitigation Strategies”(アーカイブ済み。原文は2013年2月投稿)。原文のまま:「ユーザーの頭部の物理的な動きと、ヘッドマウントディスプレイから更新された光子が眼に届くまでのレイテンシは、高品質な体験を提供するうえで最も重要な要因のひとつである」、そして「頭部の動きへの応答におけるレイテンシを知覚することは、シミュレーター酔いの主たる原因のひとつでもある」。この文章はタイムワープ再投影の技法を説明している。VRのレイテンシ目標の背景:PCGamesN, “John Carmack’s battle for 20 millisecond latency.” ↩↩↩
-
John Carmack, “In-Depth: Functional Programming in C++,” Gamasutra/Game Developer, 2012年4月30日:「ソフトウェア開発における欠陥の大きな割合は、プログラマーが自分のコードが実行されうるすべての状態を完全には理解していないことに起因する。関数型のスタイルでプログラミングすることは、コードに提示される状態を明示的にする」。バグを減らすために純粋関数を好み、可変状態を最小化することについて。 ↩