そこにいるすべてのハードコアな低レベルのハッカーに質問があります。私はブログでこの文に出くわしました。それは一般的な声明のように思われるので、私はソースが重要であるとは本当に思いません（あなたが本当に気にかけているならそれはHaackです）。
たとえば、最近の多くの3Dゲームには、C ++とアセンブリで記述された高性能コアエンジンがあります。
アセンブリに関する限り、コンパイラが余分な命令を発行したり、過剰なバイトを使用したりしたくないため、またはCで表現できない（またはなしで表現できない）より優れたアルゴリズムを使用しているため、アセンブリで記述されたコードです。コンパイラはそれらを混乱させます）？
低レベルのものを理解することが重要だと完全に理解しています。あなたがそれを理解した後、私はアセンブリのなぜプログラムを理解したいだけです。
回答:
私はあなたがこの声明を誤解していると思います：
たとえば、最近の多くの3Dゲームには、C ++とアセンブリで記述された高性能コアエンジンがあります。
ゲーム（および最近のほとんどのプログラム）は、「C ++で書かれた」のと同じように「アセンブリで書かれた」わけではありません。そのブログは、ゲームのかなりの部分がアセンブリで設計されているとか、プログラマーのチームが彼らの第一言語としてアセンブリで座って開発していると言っているのではありません。
これが実際に意味するのは、開発者が最初にゲームを作成し、C ++で動作させることです。次に、プロファイルを作成し、ボトルネックが何であるかを把握し、それが価値がある場合は、アセンブリでそれらを最適化します。または、すでに経験を積んでいる場合は、どの部分がボトルネックになるかを知っており、構築した他のゲームから最適化された部分を使用しています。
アセンブリでのプログラミングのポイントは、これまでと同じです：速度。アセンブラーで多くのコードを書くのはばかげていますが、コンパイラーが認識していない最適化がいくつかあり、コードのウィンドウが十分に小さい場合は、人間の方がうまくいくでしょう。
たとえば、浮動小数点の場合、コンパイラはかなり保守的である傾向があり、アーキテクチャのより高度な機能のいくつかを認識していない可能性があります。エラーを受け入れても構わないと思っている場合は、通常、コンパイラよりも優れた方法を実行できます。多くの時間が費やされていることがわかった場合は、アセンブリでその少しのコードを記述する価値があります。
より関連性の高い例を次に示します。
ゲームの例
SSE組み込み関数を使用したゲームエンジンの最適化に関するIntelの記事。最終的なコードは組み込み関数（インラインアセンブラではない）を使用するため、純粋なアセンブリの量は非常に少なくなります。しかし、彼らはコンパイラーによって出力されたアセンブラーを見て、何を最適化するかを正確に把握します。
Quakeの高速逆平方根。繰り返しになりますが、ルーチンにはアセンブラが含まれていませんが、この種の最適化を行うには、アーキテクチャについて何かを知っている必要があります。著者は、どの操作が速いか（乗算、シフト）、どれが遅いか（除算、sqrt）を知っています。そのため、彼らは、遅い操作を完全に回避する、非常にトリッキーな平方根の実装を考え出します。
ハイパフォーマンスコンピューティング
ゲームの領域外では、科学計算の人々は、最新のハードウェアで高速に実行できるように、物事のがらくたを最適化することがよくあります。これは、物理学をだますことができないゲームと考えてください。
この素晴らしい最近の例は、格子量子色力学（格子QCD）です。 このホワイトペーパーでは、IBM Blue Gene / L上のPowerPC440用に大幅に最適化された1つの非常に小さな計算カーネルに問題がどのように要約されるかについて説明します。各440には2つのFPUがあり、コンパイラが悪用するのが難しいいくつかの特別な三項演算をサポートしています。これらの最適化がなければ、Lattice QCDの実行速度は大幅に低下します。これは、高価なマシンで問題に数百万時間のCPU時間が必要な場合にコストがかかります。
なぜこれが重要なのか疑問に思っている場合は、この研究から出てきたサイエンスの記事をチェックしてください。格子QCDを使用して、これらの人は第一原理から陽子の質量を計算し、昨年、質量の90％が強い力の結合エネルギーから来ており、残りがクォークから来ていることを示しました。だとE = mcの2アクションインチ これが要約です。
上記の全てのために、アプリケーションがされないように設計又はアセンブリで100％に書き込ま-も近くありません。しかし、人々が本当にスピードを必要とするとき、彼らは特定のハードウェア上で飛ぶために彼らのコードの重要な部分を書くことに集中します。
私は長年アセンブリ言語でコーディングしていませんが、よく見かけるいくつかの理由を挙げられます。
すべてのコンパイラが特定のCPU最適化と命令セット（たとえば、Intelが時々追加する新しい命令セット）を利用できるわけではありません。コンパイラの作成者が追いつくのを待つことは、競争上の優位性を失うことを意味します。
実際のコードを既知のCPUアーキテクチャおよび最適化に簡単に一致させることができます。たとえば、フェッチメカニズム、キャッシングなどについて知っていること。これは開発者には透過的であるはずですが、実際にはそうではないため、コンパイラの作成者は最適化できます。
特定のハードウェアレベルのアクセスは、アセンブリ言語を介してのみ可能/実用的です（たとえば、デバイスドライバーを作成する場合）。
コードの最終またはほぼ最終的なレイアウトが何であるかをすでに知っているので、正式な推論は、高水準言語よりもアセンブリ言語の方が実際に簡単な場合があります。
APIを使用せずに特定の3Dグラフィックカード（1990年代後半頃）をプログラミングすることは、アセンブリ言語ではより実用的かつ効率的であることが多く、他の言語では不可能な場合もありました。しかし、繰り返しになりますが、これには、データを特定の順序で手動で出し入れするなど、アクセラレータアーキテクチャに基づく本当にエキスパートレベルのゲームが含まれていました。
高水準言語が使用する場合、特にその言語がCの場合、多くの人がアセンブリ言語を使用するのではないかと思います。大量の汎用コードを手動で最適化することは実用的ではありません。
アセンブラプログラミングには、他の人が言及していない側面が1つあります。それは、アプリケーションのすべてのバイトがコンパイラの努力ではなく、自分の努力の結果であるという満足感です。80年代初頭のように、アセンブラーでアプリ全体を作成することに一瞬戻りたくはありませんが、その気持ちを見逃すこともあります...
通常、素人のアセンブリはCよりも遅いですが（Cの最適化のため）、多くのゲーム（Doomをはっきりと覚えています）は、通常のマシンでスムーズに実行できるように、ゲームの特定のセクションをアセンブリに含める必要がありました。
私は最初の仕事（80年代）でアセンブリ言語でプロのプログラミングを始めました。組み込みシステムの場合、メモリの需要（RAMとEPROM）は低かった。リソースを使いやすいタイトなコードを書くことができます。
80年代後半までに、私はCに切り替えました。コードの記述、デバッグ、および保守が容易になりました。非常に小さなコードスニペットがアセンブラーで記述されました。私にとっては、独自のRTOSでコンテキストスイッチングを記述していたときでした。（「科学プロジェクト」でない限り、もうやるべきではないこと。）
一部のLinuxカーネルコードにアセンブラースニペットが表示されます。最近、私はそれをスピンロックや他の同期コードで閲覧しました。これらのコードは、アトミックなテストアンドセット操作、キャッシュの操作などにアクセスする必要があります。
最近のCコンパイラをほとんどの一般的なプログラミング用に最適化するのは難しいと思います。
私は@altCognitoに同意します。あなたの時間は、問題についてもっとよく考え、物事をより良くするために費やされたほうがよいでしょう。何らかの理由で、プログラマーはしばしばミクロ効率に焦点を合わせ、マクロ効率を無視します。パフォーマンスを向上させるためのアセンブリ言語は、非常に効率的です。システムの全体像を把握するために戻ると、システムのマクロの問題が明らかになる可能性があります。マクロの問題を解決すると、多くの場合、パフォーマンスが向上します。マクロの問題が解決されたら、ミクロレベルに崩壊します。
ミクロの問題は、1人のプログラマーの管理下にあり、より小さな領域にあると思います。マクロレベルで動作を変更するには、より多くの人とのコミュニケーションが必要です。これは、一部のプログラマーが避けていることです。そのカウボーイ全体対チームのもの。
"はい"。ただし、ほとんどの場合、アセンブラーでコードを記述することの利点は、努力する価値がないことを理解してください。アセンブリでそれを書くことで得られる見返りは、単に問題についてより深く考えることに集中し、より良い方法を考えることに時間を費やすよりも小さい傾向があります。
Quakeの作成を主に担当したJohnCarmackとMichaelAbrash、およびIDゲームエンジンに組み込まれたすべての高性能コードについては、この本で詳しく説明します。
また、今日のコンパイラーは非常に賢く、隠れたアーキテクチャーのブーストを利用する多くの手法を採用しているというÓlafurWaageにも同意します。
最近では、少なくともシーケンシャルコードの場合、適切なコンパイラは、ほとんどの場合、高度な経験を積んだアセンブリ言語プログラマに勝っています。しかし、ベクトルコードの場合、それは別の話です。たとえば、広く展開されているコンパイラは、x86SSEユニットのベクトル並列機能を利用するような優れた仕事をしません。私はコンパイラーのライターであり、SSEを悪用することは、コンパイラーを信頼するのではなく、自分でやる理由のリストのトップにあります。
私のソースには、3つまたは4つのアセンブラルーチン（約20 MBのソース）があります。それらはすべてSSE（2）であり、（かなり大きい-2400x2048以上と考えてください）画像の操作に関連しています。
趣味はコンパイラーですが、アセンブラーが増えています。ランタイムライブラリはそれらでいっぱいであることが非常に多く、それらのほとんどは通常の手続き体制に反するものと関係があります（例外のヘルパーなど）
マイクロコントローラー用のアセンブラーがありません。最新のマイクロコントローラーのほとんどは、非常に多くの周辺ハードウェア（割り込み制御カウンター、さらには直交エンコーダー全体やシリアルビルディングブロック）を備えているため、アセンブラーを使用してループを最適化する必要がなくなることがよくあります。現在のフラッシュ価格では、同じことがコードメモリにも当てはまります。また、多くの場合、ピン互換デバイスの範囲があるため、CPU電力またはフラッシュスペースが体系的に不足している場合のアップスケーリングは、多くの場合問題になりません。
実際に100000個のデバイスを出荷し、プログラミングアセンブラを使用しない限り、フラッシュチップをカテゴリを小さくするだけで、大幅な節約が可能になります。しかし、私はそのカテゴリーに属していません。
多くの人が組み込みはアセンブラーの言い訳だと思っていますが、彼らのコントローラーはUnixが開発されたマシンよりも多くのCPUパワーを持っています。（Microchipには40および60 MIPSマイクロコントローラーが10米ドル未満で付属しています）。
ただし、マイクロチップアーキテクチャの変更は容易ではないため、多くの人がレガシーに固執しています。また、HLLコードはアーキテクチャに大きく依存します（ハードウェア周辺機器、レジスタを使用してI / Oを制御するためなど）。そのため、アセンブラーでプロジェクトを維持し続ける正当な理由がある場合があります（新しいアーキテクチャーで最初から業務をセットアップできたのは幸運でした）。しかし、多くの場合、人々は自分たちが本当にアセンブラーを必要としていると自分自身をからかいます。
GOTOを使用できるかどうかを尋ねたときに教授が答えた回答は今でも気に入っています（ただし、アセンブラーとしても読むことができます）。「この機能が必要な理由について3ページのエッセイを書く価値があると思われる場合は、それを使用できます。 。結果とともにエッセイを提出してください。」
私はそれを低レベルの機能の指針として使用しました。窮屈すぎて使用しないでください。ただし、適切に動機付けてください。正当化としての複雑な推論を避けるために、（エッセイのように）人工的な障壁を1つか2つ投げることさえできます。
一部の命令/フラグ/制御は、単に経営幹部レベルにはありません。
たとえば、x86でのオーバーフローのチェックは、単純なオーバーフローフラグです。このオプションはCでは使用できません。
他の言及されたものに加えて、すべての高等言語には特定の制限があります。そのため、コードを完全に制御するために、ASMでプログラムすることを選択する人もいます。
その他には、インスタンスのチェックのために、20〜60キロバイトの範囲で、非常に小さな実行ファイルを楽しむHiEditor HiEdit制御、唯一〜50キロバイトで構文強調表示し、タブを持つWindows用の優れた強力な編集コントロール）の著者によって実現され、。私のコレクションには、ssheetsのようなExcellからhtmlレンダリングまで、20を超えるそのようなゴールドコントロールがあります。
非常に小さなCPUでの非常に小さなプロジェクトを除いて、プロジェクト全体をアセンブリでプログラムすることは決してありませんでした。ただし、パフォーマンスのボトルネックは、一部の内部ループを戦略的に手動でコーディングすることで軽減できることがよくあります。
場合によっては、実際に必要なのは、一部の言語構造を、オプティマイザーが使用方法を理解することを期待できない命令に置き換えることだけです。典型的な例は、ベクトル演算と積和演算がオプティマイザーにとって発見が難しいが、コーディングが簡単なDSPアプリケーションです。
たとえば、SH4の特定のモデルには、4x4行列と4ベクトル命令が含まれています。私が見た巨大なハードウェアの仮定と一致するように4×4に補正行列を拡大する小さなコストで、適切な命令で3x3の行列に等価なCの動作を置き換えることによって、色補正アルゴリズムにおける性能向上を。これは、12行以下のアセンブリを記述し、関連するデータ型とストレージに一致する調整を周囲のCコードのいくつかの場所に実行することで実現されました。
言及されていないようですので、追加したいと思いました。最近のゲーム開発では、作成されているアセンブリの少なくとも一部はCPU用ではないと思います。シェーダープログラムの形で、GPU用ですです。
これは、さまざまな理由で必要になる場合があります。使用する高レベルのシェーディング言語では、サイズの制約、速度、または任意の組み合わせに合わせて、必要な命令の正確な数で正確な操作を表現できない場合があります。 。アセンブリ言語プログラミングではいつものように、私は推測します。
これまでに見たほとんどすべての中規模から大規模のゲームエンジンまたはライブラリには、4x4行列連結などの行列演算に使用できる手動で最適化されたアセンブリバージョンがいくつかあります。コンパイラーは、大きな行列を処理するときに、巧妙な最適化（レジスターの再利用、ループの展開、マシン固有の命令の利用など）の一部を必然的に見逃しているようです。これらの行列操作関数は、ほとんどの場合、プロファイルの「ホットスポット」でもあります。
また、手動でコーディングされたアセンブリがカスタムディスパッチに多く使用されていることも確認しました。FastDelegateなどですが、コンパイラとマシンに固有です。
最後に、割り込みサービスルーチンがある場合、asmは世界にすべての違いをもたらすことができます。割り込みの下で発生させたくない特定の操作があり、割り込みハンドラーに「すばやく出入り」させたい場合があります。 .. ISRがasmの場合、ISRで何が起こるかをほぼ正確に知っているので、血まみれのことを短くすることをお勧めします（とにかく良い習慣です）。
ゲームはかなりパフォーマンスに飢えています。それまでの間、オプティマイザーはかなり優れていますが、「マスタープログラマー」は、アセンブリ内の適切なパーツを手動でコーディングすることで、パフォーマンスをさらに引き出すことができます。
最初にプロファイリングせずにプログラムの最適化を開始しないでください。プロファイリング後、ボトルネックを特定できるはずです。より良いアルゴリズムなどを見つけてもそれがうまくいかない場合は、アセンブリでいくつかのものを手動でコーディングしてみてください。
多くの人は、アセンブリ言語を使ってコーディングすることを学んだことがなく、漠然としか遭遇しておらず、それが彼らを驚かせたり、やや脅迫したりしているため、アセンブリ言語を軽蔑するのが大好きです。真の才能のあるプログラマーは、CやAssemblyは補完的であるため、bashするのは無意味であることを理解するでしょう。実際、一方の利点はもう一方の欠点です。Cの体系化された構文規則は明確さを向上させますが、同時に、すべてのパワーアセンブリが構造規則から解放されることを放棄します。Cコード命令は、プログラミングの意図を明確にするために議論される可能性のある非ブロッキングコードを作成するために作成されますが、これは電力損失です。Cでは、コンパイラーはif / elseif / else / end内でのジャンプを許可しません。または、互いにオーバーラップする異なる変数に2つのfor / endループを書き込むことは許可されていません。自己修正コードを書くことはできません（またはシームレスで簡単な方法で書くことはできません）など。従来のプログラマーは上記に驚かされ、従来のルールに従うように育てられているため、これらのアプローチの力をどのように使用するかさえわかりません。 。真実は次のとおりです。今日、私たちはそれらを使用するアプリケーションよりもはるかに多くのことを実行できるコンピューティング能力を備えたマシンを持っていますが、人間の脳はルールのないコーディング環境（=アセンブリ）でそれらをコーディングすることができず、非常に制限的なルールが必要ですスペクトルを減らし、コーディングを簡素化します。私は、上記の制限のために非常に非効率になることなくCコードで書くことができないコードを自分で書いています。そして、私はまだほとんどの人がアセンブリで書く主な理由であると考える速度について話していません、もしあなたがCで考えることに限定されているのなら、あなたは永遠にあなたのコンパイラの奴隷です。チェスプレイヤーのマスターは理想的なアセンブリプログラマーであり、Cプログラマーは「Dames」をプレイするだけだといつも思っていました。
gotoただし、Cは関数内で構造化されていないジャンプを許可します。if()同じ関数のorループ内のブロックに含める。例：godbolt.org/z/IINHTg。Duff's Deviceも参照してください。スイッチ/ケースをdo{}while()ループに使用して、展開されたループへのジャンプを表現します。しかし、ある時点で、そのレベルの混乱に陥っている場合は、asmで記述することがより明確になる可能性があります。
私はかつて、前のプログラマーがほとんどアセンブリコードで書いたDSPプロジェクトを引き継ぎました。ただし、浮動小数点（固定小数点DSP上で！）を使用してCで記述されたトーン検出ロジックは除きます。トーン検出ロジックは、リアルタイムの約1/20で実行されました。
結局、ほとんどすべてを一から書き直しました。いくつかの小さな割り込みハンドラーと、古いコードの100倍以上の速度で実行される割り込み処理と低レベルの周波数検出に関連する数十行のコードを除いて、ほとんどすべてがCでした。
覚えておくべき重要なことは、多くの場合、特に手書きのアセンブラがすべてをレジスタに収めることができるがコンパイラがそうではない場合、大きなルーチンよりも小さなルーチンで速度を向上させる機会がはるかに多いということです。かなり管理します。ループが十分に大きく、とにかくすべてをレジスタに保持できない場合、改善の機会ははるかに少なくなります。