C ++では、わざわざ変数をキャッシュするか、コンパイラーに最適化を行わせる必要がありますか？（エイリアシング）

次のコードを考えてみてください（これpは型unsigned char*でbitmap->widthあり、整数型であり、正確には不明であり、使用している外部ライブラリのバージョンに依存します）。

for (unsigned x = 0;  x < static_cast<unsigned>(bitmap->width);  ++x)
{
    *p++ = 0xAA;
    *p++ = 0xBB;
    *p++ = 0xCC;
}

_{それを最適化する価値があります[..]}

これにより、次のように書くことでより効率的な結果が得られる場合があります。

unsigned width(static_cast<unsigned>(bitmap->width));
for (unsigned x = 0;  x < width;  ++x)
{
    *p++ = 0xAA;
    *p++ = 0xBB;
    *p++ = 0xCC;
}

...または、コンパイラが最適化するのは簡単ですか？

_{「より良い」コードは何だと思いますか？}

_{編集者からのメモ（Ike）：取り消しテキストについて疑問に思っている方のために、元の質問は、フレーズどおり、トピックから外れた領域に危険なほど近く、肯定的なフィードバックにもかかわらず非常に閉じていました。これらは打たれました。ただし、質問のこれらの被害を受けたセクションに対応した回答者を罰しないでください。}

一見すると、コンパイラーは、最適化フラグがアクティブになっている両方のバージョンの同等のアセンブリーを生成できると思いました。確認したところ、その結果に驚きました。

ソース unoptimized.cpp

注：このコードは実行するためのものではありません。

struct bitmap_t
{
    long long width;
} bitmap;

int main(int argc, char** argv)
{
    for (unsigned x = 0 ; x < static_cast<unsigned>(bitmap.width) ; ++x)
    {
        argv[x][0] = '\0';
    }
    return 0;
}

ソース optimized.cpp

注：このコードは実行するためのものではありません。

struct bitmap_t
{
    long long width;
} bitmap;

int main(int argc, char** argv)
{
    const unsigned width = static_cast<unsigned>(bitmap.width);
    for (unsigned x = 0 ; x < width ; ++x)
    {
        argv[x][0] = '\0';
    }
    return 0;
}

コンパイル

• $ g++ -s -O3 unoptimized.cpp
• $ g++ -s -O3 optimized.cpp

アセンブリ（最適化されていない。s）

    .file   "unoptimized.cpp"
    .text
    .p2align 4,,15
.globl main
    .type   main, @function
main:
.LFB0:
    .cfi_startproc
    .cfi_personality 0x3,__gxx_personality_v0
    movl    bitmap(%rip), %eax
    testl   %eax, %eax
    je  .L2
    xorl    %eax, %eax
    .p2align 4,,10
    .p2align 3
.L3:
    mov %eax, %edx
    addl    $1, %eax
    movq    (%rsi,%rdx,8), %rdx
    movb    $0, (%rdx)
    cmpl    bitmap(%rip), %eax
    jb  .L3
.L2:
    xorl    %eax, %eax
    ret
    .cfi_endproc
.LFE0:
    .size   main, .-main
.globl bitmap
    .bss
    .align 8
    .type   bitmap, @object
    .size   bitmap, 8
bitmap:
    .zero   8
    .ident  "GCC: (GNU) 4.4.7 20120313 (Red Hat 4.4.7-16)"
    .section    .note.GNU-stack,"",@progbits

アセンブリ（optimized.s）

    .file   "optimized.cpp"
    .text
    .p2align 4,,15
.globl main
    .type   main, @function
main:
.LFB0:
    .cfi_startproc
    .cfi_personality 0x3,__gxx_personality_v0
    movl    bitmap(%rip), %eax
    testl   %eax, %eax
    je  .L2
    subl    $1, %eax
    leaq    8(,%rax,8), %rcx
    xorl    %eax, %eax
    .p2align 4,,10
    .p2align 3
.L3:
    movq    (%rsi,%rax), %rdx
    addq    $8, %rax
    cmpq    %rcx, %rax
    movb    $0, (%rdx)
    jne .L3
.L2:
    xorl    %eax, %eax
    ret
    .cfi_endproc
.LFE0:
    .size   main, .-main
.globl bitmap
    .bss
    .align 8
    .type   bitmap, @object
    .size   bitmap, 8
bitmap:
    .zero   8
    .ident  "GCC: (GNU) 4.4.7 20120313 (Red Hat 4.4.7-16)"
    .section    .note.GNU-stack,"",@progbits

差分

$ diff -uN unoptimized.s optimized.s
--- unoptimized.s   2015-11-24 16:11:55.837922223 +0000
+++ optimized.s 2015-11-24 16:12:02.628922941 +0000
@@ -1,4 +1,4 @@
-   .file   "unoptimized.cpp"
+   .file   "optimized.cpp"
    .text
    .p2align 4,,15
 .globl main
@@ -10,16 +10,17 @@
    movl    bitmap(%rip), %eax
    testl   %eax, %eax
    je  .L2
+   subl    $1, %eax
+   leaq    8(,%rax,8), %rcx
    xorl    %eax, %eax
    .p2align 4,,10
    .p2align 3
 .L3:
-   mov %eax, %edx
-   addl    $1, %eax
-   movq    (%rsi,%rdx,8), %rdx
+   movq    (%rsi,%rax), %rdx
+   addq    $8, %rax
+   cmpq    %rcx, %rax
    movb    $0, (%rdx)
-   cmpl    bitmap(%rip), %eax
-   jb  .L3
+   jne .L3
 .L2:
    xorl    %eax, %eax
    ret

最適化されたバージョン用に生成されたアセンブリは、各反復でオフセットを計算する最適化されていないバージョン（lea）widthとは異なり、実際に定数をロードしwidthます（movq）。

時間があるとき、私は最終的にいくつかのベンチマークを投稿します。良い質問。

実際には、コードスニペットからは情報を伝えるには不十分な情報があり、私が考えることができる1つのことはエイリアシングです。私たちの観点からは、メモリ内の同じ場所を望まpずbitmapに指し示すことは明らかですが、コンパイラはそれを認識せず、（pタイプがであるためchar*）コンパイラはこのコードを機能させる必要がありますpそしてbitmap重なる。

つまり、この場合bitmap->width、ポインターを介してループが変更された場合、後でp再読み取りするときbitmap->widthにそれを確認する必要があります。つまり、ローカル変数にループを格納することは不正です。

そうは言っても、一部のコンパイラーは実際には同じコードの2つのバージョンを生成することがあります（これについては状況証拠を確認しましたが、この場合にコンパイラーが実行していることに関する情報を直接求めたことはありません）。エイリアスを設定し、問題がなければ高速なコードを実行します。

とは言っても、2つのバージョンのパフォーマンスを単に測定することについての私のコメントはそのままにしています。私のお金は、2つのバージョンのコード間で一貫したパフォーマンスの違いが見られないことです。

私の意見では、このような質問は、コンパイラの最適化の理論と手法について学ぶことを目的とする場合は問題ありませんが、ここでの最終目標がプログラムの実行を高速化することである場合は、時間の無駄です（無駄なマイクロ最適化）。

わかりました、私は測定しましたGCC -O3（Linux x64でGCC 4.9を使用）。

結局、2番目のバージョンは54％高速に実行されます。

ですから、エイリアシングが問題だと思います、私はそれについて考えていませんでした。

[編集]

すべてのポインターがで定義された最初のバージョンを再試行しましたが__restrict__、結果は同じです。奇妙です。エイリアシングは問題ではないか、または何らかの理由で、コンパイラーはを使用してもそれを最適化しません__restrict__。

[編集2]

OK、エイリアシングが問題であることを証明できたと思います。私は元のテストを繰り返しましたが、今回はポインターではなく配列を使用しました。

const std::size_t n = 0x80000000ull;
bitmap->width = n;
static unsigned char d[n*3];
std::size_t i=0;
for (unsigned x = 0;  x < static_cast<unsigned>(bitmap->width);  ++x)
{
    d[i++] = 0xAA;
    d[i++] = 0xBB;
    d[i++] = 0xCC;
}

そして、測定しました（「-mcmodel = large」を使用してリンクする必要がありました）。それから私は試しました：

const std::size_t n = 0x80000000ull;
bitmap->width = n;
static unsigned char d[n*3];
std::size_t i=0;
unsigned width(static_cast<unsigned>(bitmap->width));
for (unsigned x = 0;  x < width;  ++x)
{
    d[i++] = 0xAA;
    d[i++] = 0xBB;
    d[i++] = 0xCC;
}

測定結果は同じでした-コンパイラがそれ自体で最適化できたようです。

次に、元のコード（ポインタ付きp）を試しましたが、今回pは型std::uint16_t*です。繰り返しになりますが、結果は同じです-厳密なエイリアシングのため。その後、「-fno-strict-aliasing」を使用してビルドを試みたところ、時間の違いがわかりました。

他の答えは、ポインタ操作をループの外に引き上げると、charにエイリアスを許可するエイリアスルールが原因で定義済みの動作が変わる可能性があるため、ほとんどの場合それが人間にとって明らかに正しいとしても、コンパイラにとって許容できる最適化ではないことが指摘されていますプログラマー。

彼らはまた、ループの外で操作を引き上げることは、パフォーマンスの観点からは常にではないが通常は改善であり、読みやすさの観点からはしばしば否定的であることを指摘しました。

「第三の方法」がしばしばあることを指摘したいと思います。必要な反復回数までカウントアップするのではなく、ゼロまでカウントダウンできます。これは、ループの開始時に反復回数が1度だけ必要であることを意味し、その後に格納する必要はありません。アセンブラーレベルのほうが優れていますが、デクリメント操作では通常、デクリメントの前（キャリーフラグ）とアフターフラグ（ゼロフラグ）の両方でカウンターがゼロであったかどうかを示すフラグが設定されるため、明示的な比較が不要になることがよくあります。

for (unsigned x = static_cast<unsigned>(bitmap->width);x > 0;  x--)
{
    *p++ = 0xAA;
    *p++ = 0xBB;
    *p++ = 0xCC;
}

このバージョンのループは、0 ..（width-1）の範囲ではなく、1..widthの範囲のx値を提供することに注意してください。実際にはxを何も使用していないため、これは問題ではありませんが、注意する必要があります。xの値が0 ..（width-1）の範囲のカウントダウンループが必要な場合は、実行できます。

for (unsigned x = static_cast<unsigned>(bitmap->width); x-- > 0;)
{
    *p++ = 0xAA;
    *p++ = 0xBB;
    *p++ = 0xCC;
}

また、ビットマップ->幅で実行しているのは変数に直接割り当てるため、比較ルールへの影響を心配せずに、上記の例のキャストを取り除くこともできます。

最適化を妨げる可能性があるのは、厳密なエイリアシングルールだけです。つまり：

「厳密なエイリアシングは、C（またはC ++）コンパイラによって作成された、異なるタイプのオブジェクトへのポインタの逆参照は決して同じメモリ位置を参照しない（つまり、相互にエイリアシングする）ことを前提としています。」

[…]

ルールの例外は、char*任意のタイプを指すことができるです。

例外はunsigned、signed charポインタにも適用されます。

これはあなたのコードの場合です：あなたは*pを通してpを変更しているunsigned char*ので、コンパイラはそれがを指すことができると仮定しなければなりませんbitmap->width。したがって、のキャッシュbitmap->widthは無効な最適化です。この最適化を防ぐ動作は、YSCの回答に示されています。

非型および非型をp指し示している場合にのみ、キャッシングは可能な最適化となるでしょう。chardecltype(bitmap->width)

最初に尋ねられた質問：

最適化する価値はありますか？

そして、それに対する私の答え（賛成票と反対票の両方を上手く組み合わせて得ています。）

コンパイラにそれについて心配させてください。

コンパイラはほぼ間違いなくあなたより良い仕事をします。そして、あなたの「最適化」が「明白な」コードよりも優れているという保証はありません-それを測定しましたか？

さらに重要なことに、最適化しているコードがプログラムのパフォーマンスに影響を与えているという証拠はありますか？

反対票が投じられたにもかかわらず（そして今ではエイリアシングの問題が発生しています）、それでも有効な答えとして満足しています。何かを最適化する価値があるかどうかわからない場合は、おそらくそうではありません。

もちろん、かなり異なる質問は次のとおりです。

コードのフラグメントを最適化する価値があるかどうかはどうすればわかりますか？

まず、アプリケーションまたはライブラリは、現在よりも速く実行する必要がありますか？ユーザーは長時間待ち続けていますか？ソフトウェアは、明日の天気予報ではなく、昨日の天気予報を予測していますか？

ソフトウェアの用途とユーザーの期待に基づいて、実際にこれを知ることができるのはあなただけです。

ソフトウェアに何らかの最適化が必要であると仮定すると、次に行うことは測定を開始することです。プロファイラーは、コードが時間を費やす場所を教えてくれます。フラグメントがボトルネックとして表示されない場合は、そのままにしておくことをお勧めします。プロファイラーやその他の測定ツールも、変更によって違いが生じたかどうかを教えてくれます。コードを最適化するために何時間も費やすことは可能ですが、認識できるほどの違いはないことがわかります。

とにかく、「最適化」とはどういう意味ですか？

「最適化された」コードを作成していない場合は、コードをできるだけ明確、簡潔、簡潔にする必要があります。「時期尚早な最適化は悪だ」という議論は、ずさんなコードや非効率なコードの言い訳にはなりません。

最適化されたコードは通常、パフォーマンスのために上記の属性の一部を犠牲にします。追加のローカル変数の導入、予想よりも広いスコープを持つオブジェクトの作成、通常のループの順序の逆転などが含まれる場合があります。これらはすべて、あまり明確ではないか簡潔になる可能性があるため、これを行う理由についてコードを（簡潔に！）文書化してください。

しかし、しばしば「遅い」コードでは、これらのマイクロ最適化は最後の手段です。最初に調べるのは、アルゴリズムとデータ構造です。作業をまったく回避する方法はありますか？線形検索をバイナリ検索に置き換えることはできますか？リンクされたリストはベクトルよりも高速ですか？それともハッシュテーブル？結果をキャッシュできますか？ここで適切な「効率的な」決定を行うと、多くの場合、桁違いにパフォーマンスに影響を与える可能性があります。

このような状況では、次のパターンを使用します。それはあなたの最初のケースとほとんど同じくらい短く、ループに対してローカルな一時変数を保持するため、2番目のケースよりも優れています。

for (unsigned int x = 0, n = static_cast<unsigned>(bitmap->width); x < n; ++x)
{
  *p++ = 0xAA;
  *p++ = 0xBB;
  *p++ = 0xCC;
}

これは、スマートコンパイラ、デバッグビルド、または特定のコンパイルフラグよりも高速です。

Edit1：ループ外に定数演算を配置することは、優れたプログラミングパターンです。特にC / C ++でのマシン操作の基本の理解を示しています。自分自身を証明するための努力は、この慣行に従わない人々にあるべきだと私は主張します。コンパイラが良いパターンを罰する場合、それはコンパイラのバグです。

Edit2：：vs2013で元のコードに対して提案を測定しましたが、％1改善されました。もっと上手にできる？単純な手動最適化により、エキゾチックな命令に頼ることなく、x64マシンの元のループの3倍の改善が得られます。以下のコードは、リトルエンディアンシステムと適切に配置されたビットマップを想定しています。テスト0はオリジナル（9秒）、テスト1は高速（3秒）です。私は誰かがこれをさらに速くできると思います、そしてテストの結果はビットマップのサイズに依存するでしょう。将来的には間違いなく、コンパイラーは常に最速のコードを生成できるようになるでしょう。これはコンパイラがプログラマAIになる将来になるのではないかと心配しています。ただし、今のところは、ループ内での追加の操作は不要であることを示すコードを記述してください。

#include <memory>
#include <time.h>

struct Bitmap_line
{
  int blah;
  unsigned int width;
  Bitmap_line(unsigned int w)
  {
    blah = 0;
    width = w;
  }
};

#define TEST 0 //define 1 for faster test

int main(int argc, char* argv[])
{
  unsigned int size = (4 * 1024 * 1024) / 3 * 3; //makes it divisible by 3
  unsigned char* pointer = (unsigned char*)malloc(size);
  memset(pointer, 0, size);
  std::unique_ptr<Bitmap_line> bitmap(new Bitmap_line(size / 3));
  clock_t told = clock();
#if TEST == 0
  for (int iter = 0; iter < 10000; iter++)
  {
    unsigned char* p = pointer;
    for (unsigned x = 0; x < static_cast<unsigned>(bitmap->width); ++x)
    //for (unsigned x = 0, n = static_cast<unsigned>(bitmap->width); x < n; ++x)
    {
      *p++ = 0xAA;
      *p++ = 0xBB;
      *p++ = 0xCC;
    }
  }
#else
  for (int iter = 0; iter < 10000; iter++)
  {
    unsigned char* p = pointer;
    unsigned x = 0;
    for (const unsigned n = static_cast<unsigned>(bitmap->width) - 4; x < n; x += 4)
    {
      *(int64_t*)p = 0xBBAACCBBAACCBBAALL;
      p += 8;
      *(int32_t*)p = 0xCCBBAACC;
      p += 4;
    }

    for (const unsigned n = static_cast<unsigned>(bitmap->width); x < n; ++x)
    {
      *p++ = 0xAA;
      *p++ = 0xBB;
      *p++ = 0xCC;
    }
  }
#endif
  double ms = 1000.0 * double(clock() - told) / CLOCKS_PER_SEC;
  printf("time %0.3f\n", ms);

  {
    //verify
    unsigned char* p = pointer;
    for (unsigned x = 0, n = static_cast<unsigned>(bitmap->width); x < n; ++x)
    {
      if ((*p++ != 0xAA) || (*p++ != 0xBB) || (*p++ != 0xCC))
      {
        printf("EEEEEEEEEEEEERRRRORRRR!!!\n");
        abort();
      }
    }
  }

  return 0;
}

考慮すべき点が2つあります。

A）最適化はどのくらいの頻度で実行されますか？

ユーザーがボタンをクリックしたときだけのように、答えがそれほど頻繁ではない場合は、コードが判読できなくても気にしないでください。答えが1秒間に1000回である場合は、おそらく最適化を行う必要があります。少しでも複雑な場合は、コメントを書き込んで、次にやって来る人を助けるために何が起こっているのかを説明してください。

B）これにより、コードの維持/トラブルシューティングが難しくなりますか？

パフォーマンスが大幅に向上していない場合は、コードを暗号化して数クロックの目盛りを節約することはお勧めできません。多くの人は、どんな優れたプログラマーでもコードを見て何が起こっているのかを理解できるはずだと言うでしょう。これは本当です。問題は、ビジネスの世界では、その計算に余分な時間がかかるとお金がかかるということです。だから、あなたがそれを読んでよりきれいにすることができるなら、それをしてください。あなたの友人はそれをあなたに感謝します。

それは私が個人的にBの例を使用すると言った。

コンパイラーは多くのことを最適化できます。あなたの例では、読みやすさ、保守性、そしてコード標準に準拠するために行く必要があります。（GCCを使用して）何を最適化できるかについて詳しくは、このブログ投稿を参照してください。

原則として、引き継ぐ必要があると判断するまで、コンパイラーに最適化を行わせます。このロジックはパフォーマンスとは関係ありませんが、人間の可読性とは関係ありません。で、広大な大多数の場合、あなたのプログラムの可読性は、その性能よりも重要です。人間が読みやすいコードを書くことを目指し、コードの保守性よりもパフォーマンスの方が重要であると確信できる場合にのみ、最適化について心配してください。

パフォーマンスが重要であることがわかったら、コードでプロファイラーを実行して、どのループが非効率的かを判断し、それらを個別に最適化する必要があります。実際にその最適化を行いたい場合もありますが（特に、STLコンテナーが関与するC ++に移行する場合）、読みやすさの点でコストは高くなります。

さらに、実際にコードが遅くなる可能性のある病理学的状況を考えることができます。たとえば、コンパイラーがbitmap->widthプロセス全体で一定であることを証明できなかった場合を考えてみます。width変数を追加することにより、コンパイラーにそのスコープ内のローカル変数を維持するように強制します。あるプラットフォーム固有の理由により、その余分な変数がスタック空間の最適化を妨げた場合、バイトコードの出力方法を再編成し、効率の悪いものを生成する必要があるかもしれません。

例として、Windows x64では__chkstk、関数が2ページ以上のローカル変数を使用する場合、関数のプリアンブルで特別なAPI呼び出しを呼び出す必要があります。この機能により、ウィンドウは、必要に応じてスタックを拡張するために使用するガードページを管理する機会を与えられます。追加の変数によってスタックの使用量が1ページ未満から1ページ以上にプッシュされる場合、関数__chkstkは入力されるたびに呼び出す必要があります。低速パスでこのループを最適化すると、低速パスで節約した速度よりも高速パスの速度が遅くなる可能性があります。

もちろん、それは少し病的ですが、その例の要点は、コンパイラを実際に遅くすることができるということです。それは、最適化がどこに行くかを決定するために作業をプロファイルする必要があることを示しているだけです。それまでの間、重要であるかどうかに関係なく、最適化のために読みやすさを決して犠牲にしないでください。

比較が間違っている 2つのコードスニペットので、

for (unsigned x = 0;  x < static_cast<unsigned>(bitmap->width);  ++x)

そして

unsigned width(static_cast<unsigned>(bitmap->width));
for (unsigned x = 0;  x<width ;  ++x)

同等ではない

最初の場合widthは依存していてconstではなく、後続の反復間で変更されないことを想定することはできません。したがって、最適化することはできませんが、ループごとにチェックする必要があります。

最適化されたケースでは、ローカル変数には、bitmap->widthプログラム実行中のある時点での値が割り当てられます。コンパイラーは、これが実際に変更されていないことを確認できます。

マルチスレッドについて考えましたか、または値が変動するように値が外部に依存している可能性があります。あなたが言わなければ、コンパイラがこれらすべてを理解することをどのように期待しますか？

コンパイラができることは、コードで可能なことだけです。

コンパイラーがコードを最適化する方法を正確に知らない限り、コードを読みやすくして設計することにより、独自の最適化を行うことをお勧めします。実際には、新しいコンパイラバージョン用に作成するすべての関数のアセンブリコードをチェックすることは困難です。

のbitmap->width値はwidth反復間で変更できるため、コンパイラーは最適化できません。最も一般的な理由はいくつかあります。

1. マルチスレッド。コンパイラは、他のスレッドが値を変更しようとしているかどうかを予測できません。
2. ループ内での変更。変数がループ内で変更されるかどうかを判断するのは簡単ではない場合があります。
3. これは関数呼び出しです。たとえばiterator::end()、container::size()常に同じ結果を返すかどうかを予測することは困難です。

高度な最適化が必要な場所について（私の個人的な意見）をまとめると、自分でそれを行う必要があります。他の場所ではそのままにしておくと、コンパイラが最適化するかどうかにかかわらず、コードの可読性が主な目標ではありません。