私は何年にもわたって、XOR ax、axを実行する必要があることを何度も読んできました。これは、より高速だからです...または、Cでプログラミングする場合は、INCまたはADDになるため、counter++またはcounter+ = 1を使用します...または、Netburst Pentiumで4 INC は ADD 1 よりも遅かったため、ターゲットが Netburst であることをコンパイラに警告する必要があったため、すべての var++ が ADD 1 に変換されました...
私の質問は、INC と ADD のパフォーマンスが異なるのはなぜですか? たとえば、他のプロセッサでは ADD よりも高速であるのに、Netburst では INC が低速であると主張されたのはなぜですか?
x86 アーキテクチャの場合、INC は条件コードのサブセットを更新しますが、ADD は条件コードのセット全体を更新します。(他のアーキテクチャには異なるルールがあるため、この説明が当てはまる場合と当てはまらない場合があります)。
したがって、INC 命令は、条件コード ビットを更新する他の前の命令が終了するまで待機してから、前の値を変更して最終的な条件コード結果を生成する必要があります。
ADD は、条件コードの以前の値に関係なく最終的な条件コード ビットを生成できるため、以前の命令が条件コードの値の計算を完了するのを待つ必要はありません。
結果: ADD は他の多くの命令と並行して実行でき、INC は他の命令の数が少なくても実行できます。したがって、実際には ADD の方が高速に見えます。
(全幅レジスタ (EAX など) のコンテキストで 8 ビット レジスタ (AL など) を操作する場合も同様の問題があると思います。AL の更新では、以前の EAX の更新が最初に完了する必要があります)。
高性能アセンブリ コードで INC または DEC を使用しなくなりました。実行時間にあまり敏感でない場合は、INC または DEC で問題なく、命令ストリームのサイズを縮小できます。
ちょっとしたことですが、私は数年前XOR ax, axに収集し、ゼロを割り当てることは今ではそれを打ち負かしています（そう言われています）。
Cビットは数十年前のものではcounter++なく約です。counter+=1間違いなく。
最初のアセンブリを使用する単純な理由は、すべての命令がCPU側で何らかの操作に変換されることです。設計者は常にすべてを可能な限り高速化しようとしますが、より良い結果が得られます。他の人よりもいくつかの人と仕事をします。INCは1つのレジスターを処理するだけでよいので、どのように高速化できるかを想像するのは難しいことではありませんが、それは非常に単純化されています（ただし、これらのことについてはよくわからないので、単純化しすぎるだけで実行できます。部）。
Cのものは、しかし、ずっと前にナンセンスです。INCがADDに勝る特定のCPUがある場合、コンパイラ設計者がADDの代わりにINCを使用しないのはなぜcounter++ですかcounter+=1？コンパイラーは多くの最適化を行い、そのような変更は最も複雑なものとはほど遠いものです。