fastDOOMの驚異的な速度の秘密とは？最適化技術に迫る！
引用元：https://news.ycombinator.com/item?id=43258709
MPVパッチのv0.1は間違いなくbuild 36（e16bab8）で、”Cripy optimization”のおかげでステータスバーのパーセント描画が変更されていない場合は無処理になる。これによりスクラップバッファへの描画と画面へのブリッティングがなくなり、合計2fpsのブーストがかかる。最初は信じられなかったけど、PCDOOMv2でこのパッチを適用してみたらすごい速度向上が確認できた。ボトルネックは予想しているところにないことが多いから、プロファイルと計測が大事だね。ステータスバーのパーセント？Doomアーキテクチャに詳しい人なら目に見えてわかるところかもしれないけど、俺は事前にボトルネックだとは思わなかった。
例えば、”ウチのアプリは謎にCPUを60％、GPUを25％使ってた。原因は小さなCSSアニメーション（イコライザアイコンの）だった。”
Slackが複数のアニメーション付き絵文字を表示するとCPUを食うのを覚えてる。20個以上の絵文字を使うと、Intel MB Proが耐えられなかった。幸い、アニメーションを無効にするオプションがあったけど、今はそれが修正されたかどうかは知らない。20～30年前のPCが何の問題もなくできたことが、現代でどうしてこんなことが起きるのか知りたい。
現代の技術で20～30年前のPCができたことができてないのはどうしてなのか、詳しく知りたい。
でも、それってただのブラウザじゃん？2005年のブラウザでも何十個もGIFを表示できたと思う。開発者たちの中で何か特別な決定があった結果、複雑な方法でやるようになったんじゃないかな。各絵文字がiframeになってフルボリュームのReactアプリでアニメーションしてる可能性だってある。でも、それでも問題ないはずじゃない？
そりゃただのブラウザって言うけど、LinuxカーネルやGNUを”ただのOS”って呼ぶのと同じだよ。それは人間が設計したシステムの中で最も複雑なソフトウェアかもしれないし、今は数ポリゴンやドロップシャドウを描画するために使われてる。C++のコミティーが数十年前に犯したミスがあって、今のウェブデベロッパーがCMakeやQt/QML、GTKに苦しんでるんだ。BlinkとV8の開発者たちがインターネット全体と複雑なウェブ開発を支えるためにしたトレードオフは、アニメーション描画のような単純な用途にはリソースの効率的な使用を妨げる。
それもそうだけど、パフォーマンスへの注力がほとんどないのも原因だよ。開発者は自分たちの作ったシステムを信頼していて、アニメーションはパフォーマンスの問題は解決済みと思っている。
ティーンエイジャーの頃に自分で発見したこと：進行状況バーを毎ループで更新しないこと。
フロントエンド開発者（ウェブでもグラフィカルターミナルでも）がゲーム開発の世界から学べることがたくさんあると思う。Pico 8を試してみることを勧めるよ。制約があるから、普段の安易な作業ではなく、限界に挑戦することになる。LUAコーディングだから、JS開発者でも特に問題ないと思うよ（20カラムのコードエディタで作業するのが平気なら）。
俺もこないだやったやり方だ。nを適当な値にして、iterationがnで割り切れるときに進捗状況を更新する感じだね。
なんでアニメーションを最適化する解決策にしたの？静的なアセットを使う方がよくね？
アプリがユーザーの声入力を受けてるって示すためじゃない？
アニメーション付きのPNGやGIFを提案してるんじゃないかな。
それか、アニメーション付きSVGを、サイズが分かってるタグの中に入れるのが良いね。
SVGアニメーションもCSSアニメーションと同じ描画経路を使ってると思う。むしろ、CSSアニメーションの方が、古いSMILの要素や属性よりもブラウザ開発者から重視されてる気がする。
アニメーション付きのPNGやGIFはユーザーが話してる時にどう反応するんだ？
声の活動に応じて異なるPNGに切り替えればいいんじゃね？
たまにでもWebコンソールで「Paint Flashing」をオンにするのが良いってことで、確かにそう思う。
ゲーム開発者として言わせてもらうと、遅延はよくあること。特にUIの描画は透過やレイヤー重ねがあって再描画しなきゃならんから、遅くなることがある。古いものと新しいものを比べてから再描画するのは大事だよ。
私もMatrixクライアント（NeoChat）で似たようなケースがあった。アカウントの読み込みが遅い理由を開発仲間と考えてたんだけど、ローディングスピナーを外したら劇的に速くなった。スピナーのアニメーションにCPUを100％使っていたから。
サーバーアプリの共通の問題は、特にコンソールへのログ出力。思ったより高コストで、単一スレッドになっていることが多いから、ログがスケーラビリティのボトルネックになることも。 『シリアル』コンソールへのログ出力が全体のカーネルを止めちゃって、レイテンシを悪化させることがある。特にVMでは、ほとんどが最低限のUARTインターフェースをエミュレートしているから、カーネルコンソールとしてそれが見えることがある。 オリジナルのDoomは、idにかなりプロファイルされてたんじゃない？もちろん見逃していることもいくつかあったけど、あの頃はゲームデベロップメントをしていてプロファイルが半分の仕事だったよ。 そうだね。パフォーマンスエンジニアリングの素晴らしい成果だよ。だけど、それ以降に別の誰かが3000回以上のマイクロ最適化を実行したんだ。 本当だね。Carmackとチームは一日に使える時間が限られていたんだ。 1993年にはどんなツールがあったの？id Softwareは、ツールが仕事に応じていなかったからNeXTを使ったと聞いたよ。 あー、記憶を押しやってるな。Visual Studioにプロファイラーがあったし、外部のツールも使っていたと思う。シリアルケーブルでデバッグとプロファイリングするシステムがあって、EXEを隣のテストPCにダウンロードしてた。だが、idにとってはNeXTのDOSポートをプロファイルする sane な方法が無かったんだよね。 Visual Studio？最初にリリースされたVisual Studio(Boston)は1997年だよ。Doomは1993年に開発されたんだからね！ 彼はMicrosoft Visual C++のことを考えてるのかもね。これは1993年にさかのぼって、Visual Studioに進化したんだ。プロファイラーもあったし。 これだ！ありがとう！Visual Studioだと思ってたけど、しばらく前のことだから忘れちゃってた！ゲームはC++、C、x86の混合だったんだな。 DoomはWindows上ではなく、NeXTマシンで開発されたんだよ。 ソースコードでのプロファイリングの証拠はないね。1993年にはそんなことはしてなかった。できることは、全ゲームを新しい変更でコンパイルして、ベンチマークループを走らせて結果を比較するくらいだった。 gprofプロファイラーは1993年前からあったよ。1982年にさかのぼるんだ。1994年にゲームエンジンの開発をしたことがあって、GCCとgprofを使って関数レベルのプロファイリングをしたり、メモリ使用量を測ったりしてた。でも大抵の時間はコードを変えて再度ゲームを実行して、フレームレートや流れる感じを確認してたんだ。 でもそれはWatcomでの話？DJGPP v1が出るまでgccはDOSにはなかったと思うし、gprofが移植されたかは覚えてない。iDは1996年のQuakeでDJGPPを使ったから、NeXTでgccを使ってたのかもね。ただそのプラットフォームでのプロファイリングは意味がなかったかも、異なるコンパイラ、異なるCPU、異なるOSだし。ゲームはTurboColorで開発されて、Motorola 68030が33MHzで動いてて、15FPSしか出なかったらしい。 Watcomも当時プロファイラーを持ってたよ。 今、人生で二つ目の仕事をしてるんだけど、プログレスバーの更新が全体のパフォーマンスに非常に大きな割合を占めてるよ。なぜなら、私たちの“エンジニア”がプロファイラーを使ったことがないからさ。大手国際テック企業でね。 分かるよ、大きな会社だと小さなことを気にしないことが多いからね。もちろん、カスタムのプログレスバーを実装したのではなく、オフ・ザ・シェルフのものを使ったと賭けることもできるけど。 性能の進化を把握するためにfastDOOM、PCDOOMv2、元のDOOM.EXEのリリースを52個ダウンロードし、全てに対して-timedemo demo1を実行するRUN.BATを作成したんだ。mTCPのNETDRIVEを使ってそれをマウントしたよ。あまりターゲット層ではないけど、これは面白いね。昔はこんなに良いネットワーク越しのストレージオプションがあったなんて思わなかった。 90年代初頭、学校にあったコンピュータラボでは、25台のMac PlusがAppleTalkでMac IIに接続されていて、PlusからはMac IIのファイルシステムをマウントしてた。しかし、それは非常に遅かったよ。生徒たちは授業の最初に5分から10分も待たされた。ネットワークがあればファイルをコピーしたくなるのは当然だけど、ローカルファイルシステムに見えると一番使いやすいよね。DOSは当時ネットワークに遅れをとってたから、手間がかかった。 1990年代初頭には、企業や大学でこのようなシステムはすでに普及してたよ。私が通ってた学校ではAFSがあって、任意のUnixワークステーションにログインすれば、自分の環境がそのまま使えた。Windowsが入ってきたときは、なんか石器時代みたいで、SMBはクソだったな。今はデスクトップアプリが減って、クラウドベースのシステムに移行してる感じがする。正直、OneDriveよりも90年代の選択肢の方が良く感じる。 90年代初頭にHP Apolloシステムを使ってた時、基本的にトークンリングネットワークを通じて一つのファイルシステムを共有してた。2台以上のシステムを接続して、一つにログインすれば、他のシステムのファイルも簡単にアクセスできたんだ。共有されるものに制限はあったか覚えてないけど、みんなで共有するにはかなり便利だった。 あの頃が懐かしい。複数のコンピュータがあるのに、ファイルシステムを共有するのが苦労するってのが変だよね。実際、多くのアプリがその共有をサポートしてないんだよね。ウェブは良いけど、ローカルアプリの方がずっとパワフルで早い気がする。 私の学校ではWindows NTを使っていて、どのワークステーションでも同じようにデータにアクセスできたよ。その後、Citrix設定を見たことがあって、サーバーからアプリケーションをロードする仕組みもまあまあ機能してた。99年後半にはWindowsにもかなりの選択肢があったね。 Windowsにおいて、多くはAppData（Remote, Local, LocalLow）が正しく使用されてたかどうかにかかってたよ。NTでは名前が違ってたけど、コンセプトは昔からあったんだ。9xではこの分離がなかったから、それに合わせて作られたアプリが少なかったんだよね。 90年代初頭には、こうしたシステムが企業や大学に深く浸透していた。Novell NetWareのことを覚えている人はいるかな？ Appletalkは速度が遅い、230.4 kbit/s。時には10mbitのEthernetがあったけど、高かったからな。ワープロを各マシンにインストールして、ファイルだけネットワーク越しに保存するのが一般的なベストプラクティスだったけど、プラス機械にハードドライブを必要とするから、コストがかかったんだ。 AppleTalkはLocalTalkケーブルで遅かったけど、Ethernetならその速度を出せたよね。 ＞the worLd processor iPXEを使えば、iscsiターゲットからDOSをネットブートできる方法があるんだ。ドライバーとか設定なしで、DOSがネット上のブロックデバイスへアクセスできるって不思議だよね。iPXEがBIOSをパッチしているのかな。 DOS時代にNASやWebDAVマウントはあったのかな？FTPやtelnetはあったけど、リモートマウントはどうだったんだろう？ はい、Novell Netwareがリモートドライブをマウントできたし、DOSにはファイル同時アクセスのためのAPIもあったよ。DOOMのマルチプレイヤーコードもNovell Netwareスタックの一部を使ってたんだ。主にLANで使われてたけどね。 うん、Netwareがそれだったし、Novellはすごい大企業だったよ。SMB（samba）もDOS時代のもので、ほとんどの人はWindowsからしか知らないだろうね。DOSのシンプルなドライブインターフェースを使ったネットワークドライブの作り方はいろいろあった。Win95が出るまではネット接続が有料だったんだ。 90年代に、学生会館でDOS PCを使ってGaming Networkを運営してたんだ。NovellをLinuxサーバーで動かして、インターネットもなかったけどゲームが楽しかったよ。Command & ConquerやDOOM、Quakeをみんなネットマウントからスタートしてた。懐かしいな。 ネットワークリダイレクタインターフェースは1985年のDOS 3.1で追加されたんだ。おそらく3.0の1984年より前からあったかも。 WebDAVは90年代後半に出てきたけど、最初はなかなか浸透しなかったよ。昔はGruntPageで直接ウェブページを作って、FPSEがインストールされたサーバーにそのまま公開してたんだ。WebDAVはそのオープンスタンダード的な反応だったんだ。 WebDAV自体は1999年、Windows 95の時代に登場したんだ。Novellのシステムはそれよりずっと前からあったよ。 Ken SilvermanとのGitHubスレッド、めっちゃ面白い！FastDOOMの作者とKenが486のレジスタやクロックサイクルの効率について議論してる様子が素晴らしい。Doomがパフォーマンス向上してるのは嬉しいね！ KenSを思い出すのは久しぶりだけど、90年代はDuke3Dのモッディングにめっちゃハマってた。スクリプトを書くのが初めての”コーディング”だったんだ。そういう意味で、KenSには感謝してるよ！ Duke 3Dは初めてのメインストリームのモッディング可能なFPSだったと思う。Doomもレベルエディタはあったけど、DukeはAIをスクリプトするためのテキスト形式のCONファイルがあったし、BUILDエンジンで学んだスキルは他のゲームでも通用したよね。 Dukeも3Dエディタのマップエディタがあって、床や天井を上げたり下げたり、テクスチャを選んだりできた。時代を先取りしてたね。ブラシベースの本格的な3Dは良いエディタを作るのを難しくしたけど。 Command and ConquerのRules.iniも似たような感じで、自分にとって懐かしい思い出がある。 C&C Red Alert。C&C 1はモッドしにくかったけど、Dune 2000は結構モッドしやすかった。 彼のブログは最初に見たページだった。Duke3Dのマップエディタやボクセルを使った大きなプロジェクトについて話してたんだ。 去年、似たような2.5Dレンダリングエンジンを作ってて、Build Engineのある難しい点についてKen Silvermanにメールしたら、まるで昨日やったかのように答えてくれた。 そこには本当に素晴らしいアイデアがある。特に、メモリアクセスが遅い時のCR2とCR3をスクラッチパッドレジスタとして使うアイデアや、ESPをループカウンタとして使うトリックは天才的だと思った。 そうそう！低レベルプログラミングはよく知らないけど、使わないレジスタを使って速い‘メモリ’位置にするアイデアは特に賢いと思う。 FastDOOMの特徴の一つに、変なビデオモードがたくさんあるのが面白い。例えば、IBM MDAテキストモード、EGAとPlantronics ColorPlus、クラシックな青とピンクのCGA、320x200x16の‘ANSI from Hell’ハック、Herculesとか。VGAより色の再マッピングがあるから、ほとんどのモードは動作が悪いみたい。 これはすごい、ゲームのこの要素は分離すべきだってのを示してるね。現代のClean Architectureを思い出す。 “IBM PS/1 486-DX2 66MHz、ミニタワー2168。学生の頃にずっと欲しかったパソコンだけど、買えなかった。” “Wow”？92年の時に持ってたパソコンを買えなかった人を悪く言う必要あるのかな？ 懐かしい思い出。92年頃、貧乏学生だったから、信用金庫から約2000ドルを借りて486 DX2-50を買った。今の価値で言えば、基本的なPCに4000ドル以上だよ。DOSとLinuxをデュアルブートしてた。 486DXと487？487はSXチップにしか役立たないと思ってたけど…調べたら、標準の487は元の486SXを無効にして置き換えたフル486DXとのこと。他に聞いたことのない特別なコプロセッサだったの？ 特定の計算タスクでスループットが倍増したかも。マザーがサポートしてればの話だけど、Mapleみたいなソフトが活用できるかもね。 486SXは16ビット外部バスで386チップセットと使えるけど、DXはフル32ビットバスでスループットが良いんだ。486にはFPUが内蔵されてないから、コプロセッサを追加しないといけなかった。 486SLCのこと考えてるでしょ。486SXは32ビットで486DXはFPU内蔵、487は486DXで486SXを無効にするためのものだよ。 386のことを考えてるんでしょ。486の話じゃないよ。386SXは16ビット外部バスで286チップセットと使えるけど、DXはフル32ビットバスでスループットが良いよ。 ちょっと考えたら、世代を一つ飛ばしてしまったことに気づいた。35年前に組んだPCの詳細は忘れがちだな。 間違ってるよ。486SXもDXと同じ32ビットバスを持ってる。ただ、DXはFPU内蔵でSXはそれを無効にして487コプロセッサを追加しないといけないんだ。 486DXにはFPUがある。486SXはそれが無い。486SX用のFPUアップグレードは486DXの特別版でSXを完全に無効にするものだよ。 ”Pentiumのいくつかのモデルを超えて、計算ミスもなかった。”何か自慢だけど、技術的に勝ってたんだ。よくやった。もっとコメントを表示（1）
＞NetDriveは、他のマシンがホストするリモートディスクイメージをローカルデバイスのように扱えるDOSデバイスドライバーだよ。もっとコメントを表示（2）
めっちゃ笑ったわ！ネットワーク使ってたの？すごい！こっちじゃそんなの無いからFloppy-netとかbus-304-netがあったんだよ。フロッピー書いて304バス乗って他のキャンパスへ行く感じ。
[1] https://www.os2museum.com/wp/redirectors-and-dos-3-0/もっとコメントを表示（3）
92年には、自作PCを4台目にしてた。マールボロMAのKCSコンピュータショーは自作好きには最高の資源だった。部品を買ってPCを作ってしばらく使い、売ってまた部品を買う…を繰り返してた。92年の終わりには、ULSI 487数学コプロセッサ付き486-DX3 100を使ってた。しばらくの間、キャンパスで最速のPCだったかも。Excelの21ページの論文用にガス/ディーゼル熱電共生プラントをシミュレーションしてたから、再計算にめっちゃ時間かかってた。学位は環境科学で、キャリアは全てコンピュータ。
それに、‘DX3’なんて存在しないし、最初の100MHzの486（DX4）は94年3月に出たから、92年の終わりにそれを使ってたとは思えない。私の家族の初めてのPCは、92年頃に手に入れたXTを除いて、95年初めに購入した66MHz 486-DX2だった。
