私はいつも「マイクロ最適化」という用語をかなり曖昧に見つけました。メモリレイアウトとアクセスパターンに対する命令レベルの変更が、アルゴリズムの複雑さを軽減することなく、ホットスポットを測定する規律ある専門家から80倍速くなった場合、それは「マイクロ最適化」ですか？私にとって、それは実世界のユースケースで80倍高速化する「メガ最適化」です。このような最適化が顕微鏡効果をもたらすように、人々はこれらのことについて話す傾向があります。
私はもうgamedevで働いていませんが、VFXでパストレースなどの分野で働いており、複雑なシーンで毎秒約50万レイを処理するBVHとKDツリーの実装をたくさん見ました（そしてこれはマルチスレッド評価）。大まかに言えば、マルチスレッド評価でも、レイトレーシングコンテキストでBVHを100万光線/秒未満で簡単に実装する傾向があります。Embreeを除き、同じハードウェアで同じシーンで1億本以上の光線を処理できるBVHがあります。
これは、完全にEmbreeが200倍高速な「マイクロ最適化」によるものです（同じアルゴリズムとデータ構造）が、もちろん、それが非常に高速である理由は、その背後のIntelの開発者がプロファイラーと測定に頼る専門家であるためです本当に重要な領域を調整しました。彼らは、コードを意のままに変更し、保守性を著しく低下させる代わりに0.000000001％の改善を行った変更をコミットしていませんでした。これらは賢明な手で適用された非常に正確な最適化でした-それらは焦点の点では微視的でしたが、効果の面では巨視的だったかもしれません。
当然、ゲームのリアルタイムフレームレート要件では、ゲームエンジンでの作業のレベルに応じて（UE 4で作成されたゲームでさえ、少なくとも部分的に高レベルスクリプトで実装されることがよくありますが、しかし、たとえば、物理エンジンの最も重要な部分ではありません）、特定の分野ではマイクロ最適化が実用的な要件になります。
毎日私たちを取り巻く別の非常に基本的な領域は、リアルタイムで高解像度画像をぼかしたり、おそらくどこかで見たトランジションの一部としてそれらに他のエフェクトを実行したり、OSエフェクトなどの画像処理です。画像のすべてのピクセルを最初からループして、そのような画像操作を必ずしも実装できず、フレームレートが一致するようなリアルタイムの結果を期待できるわけではありません。CPUの場合、通常はSIMDといくつかのマイクロチューニングを検討しています。または、効果的に書き込むためにマイクロレベルの考え方を必要とする傾向があるGPUシェーダーを検討しています。
はいの場合、ハードウェアが向上するにつれて、より高いレベルの言語がゲーム業界を引き継ぐことを期待する必要がありますか？
むしろ、ハードウェアの進歩だけでそれができるとは思いません。ハードウェアが進歩するにつれて、命令とテクノロジー（GPUの物理学など）、テクニック、そして彼らが見たいものや競争に対する顧客の期待もそうなるからです。 WebGLで低レベルのGLSLシェーダーを作成しているWeb開発者の場合でさえ、開発者が再び低レベルになることが多い方法（この種のWeb開発は、おそらく10年または2年前よりもさらに低レベルです。 GLSLは非常に低レベルのCライクな言語であり、10年または2年前には、一部のWeb開発者がこのような低レベルGPUシェーダーの作成を受け入れるとは思いもしませんでした）。
パフォーマンスが重要な領域を高レベルの言語に移行する方法がある場合、利用可能なソフトウェア、コンパイラ、およびツールからより多くのものを取得する必要があります。近い将来、私にとっての問題は、ハードウェアが十分に強力ではないということです。それは、独自の言語に再び戻ることなく、変化し進歩するたびに最も効果的に話す方法を見つけることができない方法にもっと関係しています。実際、ハードウェアの変化が速いペースであるため、高レベルのプログラミングはこれらの分野で見かけているように見えにくくなります。仮に私たちのハードウェアが次の数十年間で突然前進しなくなった場合、
おもしろいことに、私が真のパフォーマンスクリティカルな領域で作業しているとき、私は（ボーランドターボC DOS時代に始まったとしても）始めたよりも低レベルであると思う必要があります。当時、CPUキャッシュはほとんど存在していなかったためです。それは主にDRAMとレジスタだけでした。つまり、パフォーマンスにあまり影響を与えることなく、アルゴリズムの複雑さにもっと焦点を当て、ツリーのようなリンクされた構造を非常に簡単な方法で書くことができました。最近では、CPUキャッシュの低レベルの詳細が、アルゴリズム自体と同じくらい私の考えを支配しています。同様に、マルチスレッドとアトミック、ミューテックス、スレッドの安全性、同時データ構造などについて考えさせなければならないマルチコアマシンがあります。で、私が始めたときよりも人間的に直感的ではありません）。
奇妙なことに、今では私にはとても真実に思えます。ノスタルジアメガネを脱ぐために全力を尽くすよりも、30年前よりも、今日のハードウェアの根本的な低レベルの複雑さと詳細に影響を受けていると思います。もちろん、ここで少し話し合ったのかもしれませんが、XMS / EMSなどの厄介な詳細を処理する必要がありました。しかし、ほとんどの場合、パフォーマンスが重要な領域で作業している今日よりも、複雑さやハードウェアとコンパイラの認識が以前よりも少なくて済むと思います。そして、私たちが執筆のように脇に置いておくと、それは業界全体にほとんど当てはまるようですif/else 人間が読みやすい方法でステートメントを作成し、最近の一般的な人々がハードウェアの下位レベルの詳細（複数のコアからGPU、SIMD、CPUキャッシュ、およびコンパイラ/インタープリター/ライブラリが動作するなど）。
高レベル！=効率が低い
この質問に戻って：
はいの場合、ハードウェアが向上するにつれて、より高いレベルの言語がゲーム業界を引き継ぐことを期待する必要がありますか？
私にとっては、ハードウェアの問題ではありません。オプティマイザーとツールについてです。私が始めたとき、人々は実際にすべてのコンソールゲームをアセンブリで書いていましたが、6502を生成する高品質のコンパイラが不足していることを考えると、真のパフォーマンス上の利点がありました。
最適化Cコンパイラの最適化がより賢くなると、Cで記述された高レベルのコードが競合するポイントに到達し始め、多くの分野で最高のアセンブリエキスパートによって記述されたコードよりも優れている場合があります（常にではありません）。そのため、少なくともゲームのコーディングの大部分でCを採用するのは簡単でした。そして、C ++のある時点で、同様の変化が徐々に起こりました。アセンブリからCへの移行による生産性の向上は、CからC ++への移行とは対照的に、ASMで完全に非自明なゲームを作成するgamedevsからの満場一致の合意に達する可能性があるため、C ++の採用は遅かったです。
しかし、これらのシフトは、これらの言語のオプティマイザが大幅に低レベルにレンダリングするほどハードウェアが強力になることによるものではありません（常にではありませんが、いくつかのあいまいなケースがあります）。
マルチスレッドやGPU、キャッシュミス、またはそのような（特定のデータ構造でさえない）ことを心配せずに、想像できる最高レベルのコードでコードを書くことができる仮想シナリオを想像でき、オプティマイザーは人工知能のようなものでしたデータを再配置および圧縮する最も効率的なメモリレイアウトを見つけ出し、あちこちでGPUを使用し、コードをあちこちで並列化し、SIMDを使用し、自分自身のプロファイルを作成し、人間としてIRをさらに最適化していくプロファイラーのホットスポットに対応し、世界最高の専門家に勝る方法でそれを行いました。それにより、最もパフォーマンスが重要な分野で働いている人でもそれを採用するのは簡単です...そしてそれは進歩です高速なハードウェアではなく、途方もなくスマートなオプティマイザーから来ています。