27

数日前の Facebook での講演 -スライドビデオで、Andrei Alexandrescu は、私たちが間違っていることを証明するかもしれない共通の直感について語っています。私にとって非常に興味深い点がスライド 7 で出てきました。彼は、 「命令が少ない = コードが速くなる」という仮定は正しくなく、命令が多いからといって必ずしもコードが遅くなるとは限らないと述べています。

ここに私の問題があります: 彼の講演 (約 6:20 分) の音質はそれほど良くなく、説明がよくわかりませんが、私が得たのは、彼が廃止された命令とアルゴリズムの最適性を比較していることです。パフォーマンスレベル。

しかし、私の理解では、これらは 2 つの独立した構造レベルであるため、これを行うことはできません。指示 (特に実際に廃止された指示) は 1 つの非常に重要な尺度であり、基本的に、目標を達成するためのパフォーマンスについてのアイデアを提供します。命令のレイテンシを除外すると、廃止された命令が少ないほどコードが高速になると一般化できます。もちろん、ループ内で複雑な計算を実行するアルゴリズムは、ループ内で実行されてもパフォーマンスが向上する場合があります。これは、ループを早期に中断するためです (グラフ トラバーサルを考えてください)。しかし、このループが他のループよりも多くの命令を持ち、優れていると言うよりも、複雑さのレベルでアルゴリズムと比較する方が有益ではないでしょうか? 私の視点から、

誰かが彼の例で彼がどこに向かっていたのかを理解するのを手伝ってもらえますか? また、(大幅に) 廃止された命令がパフォーマンスの向上につながる場合はどうすればよいでしょうか?

4

2 に答える 2

20

品質は確かに悪いですが、CPUは計算には適していますが、メモリシーク(RAMはCPUよりもはるかに遅い)と分岐(CPUはパイプラインとして機能し、分岐するため)のパフォーマンスが悪いという事実につながると思いますパイプラインが破損する可能性があります)。

より多くの命令がより速いいくつかのケースはここにあります:

  1. 分岐予測-より多くの命令を実行する必要がある場合でも、より良い分岐予測が得られるため、CPUのパイプラインはより多くの時間でいっぱいになり、CPUから「スローアウト」される操作が少なくなり、最終的にはパフォーマンスが向上します。 。たとえば、このスレッドは同じことを行う方法を示していますが、最初に並べ替えるとパフォーマンスが向上します。

  2. CPUキャッシュ-コードがよりキャッシュ最適化されており、局所性の原則に従っている場合-命令の半分の量を実行しないコードであっても、そうでないコードよりも高速になる可能性が高くなります。このスレッドは、小さなキャッシュ最適化の例を示しています。同じ数の命令を使用すると、キャッシュが最適化されていない場合、コードの速度が大幅に低下する可能性があります。

  3. どの指示が行われるかも重要です。たとえば、一部の命令は他の命令よりも実行が遅い場合があります。たとえば、除算は整数加算よりも遅い場合があります。

:上記はすべてマシンに依存しており、実際にパフォーマンスを変更する方法/変更するかどうかは、アーキテクチャごとに異なる場合があります。

于 2012-12-20T13:27:35.267 に答える
6

命令の数自体は、適切な尺度ではありません。

廃止された命令が少ない (これ以上何もすることがないため) = 高速なコード。

廃止された命令が少ない (依存関係を待つ必要があるため) = コードが遅くなります。

コード内の命令が増えると、廃止された命令が増えることを意味する場合もあります。これは、ケース 2 で無駄になる実行スロットを使用する可能性があるためです。

于 2012-12-20T13:36:10.613 に答える