C ++でのステートメント順序の強制

決まった順序で実行したいステートメントがいくつかあるとします。最適化レベル2でg ++を使用したいので、一部のステートメントを並べ替えることができます。ステートメントの特定の順序を強制するためにどのツールが必要ですか？

次の例を考えてみましょう。

using Clock = std::chrono::high_resolution_clock;

auto t1 = Clock::now(); // Statement 1
foo();                  // Statement 2
auto t2 = Clock::now(); // Statement 3

auto elapsedTime = t2 - t1;

この例では、ステートメント1〜3が指定された順序で実行されることが重要です。しかし、コンパイラはステートメント2が1と3から独立していると考え、次のようにコードを実行できないのでしょうか。

using Clock=std::chrono::high_resolution_clock;

foo();                  // Statement 2
auto t1 = Clock::now(); // Statement 1
auto t2 = Clock::now(); // Statement 3

auto elapsedTime = t2 - t1;

これがC ++標準委員会で議論された後、もう少し包括的な答えを提供したいと思います。C ++委員会のメンバーであることに加えて、私はLLVMおよびClangコンパイラーの開発者でもあります。

基本的に、これらの変換を実現するために、シーケンスでバリアまたは何らかの操作を使用する方法はありません。基本的な問題は、整数の加算などの動作セマンティクスが実装に完全に認識されていることです。それはそれらをシミュレートでき、正しいプログラムでは観察できないことを認識しており、常に自由に移動できます。

これを防ぐことはできますが、結果は非常に悪い結果となり、最終的には失敗します。

まず、コンパイラでこれを防ぐ唯一の方法は、これらの基本的な操作がすべて監視可能であることを伝えることです。問題は、これにより、圧倒的多数のコンパイラ最適化が妨げられることです。コンパイラーの内部には、タイミングが観察可能であることをモデル化する優れたメカニズムは基本的にありませんが、それ以外には何もありません。どの操作に時間がかかるかを示す適切なモデルさえありません。例として、32ビットの符号なし整数を64ビットの符号なし整数に変換するには時間がかかりますか？x86-64では時間がかかりませんが、他のアーキテクチャでは時間がかかりません。ここには一般的に正しい答えはありません。

しかし、これらの操作をコンパイラが再順序付けできないようにすることでいくつかの英雄的成功を収めたとしても、これで十分である保証はありません。x86マシンでDynamoRIOを実行するための有効で準拠した方法を検討してください。プログラムのマシンコードを動的に評価するシステムです。それができることの1つは、オンライン最適化であり、タイミングの外にある基本的な算術命令の範囲全体を投機的に実行することさえできます。また、この動作は動的エバリュエーターに固有のものではなく、実際のx86 CPUは（はるかに少ない数の）命令を推測し、それらを動的に並べ替えます。

本質的な認識は、演算が（タイミングレベルでも）観測できないという事実は、コンピューターのレイヤーに浸透するものであるということです。これは、コンパイラー、ランタイム、さらにはハードウェアにも当てはまります。強制的に監視可能にすると、コンパイラが劇的に抑制されますが、ハードウェアも劇的に抑制されます。

しかし、これらすべてがあなたの希望を失う原因にはなりません。基本的な数学演算の実行時間を計測したい場合は、確実に機能する手法を十分に検討しました。通常、これらはマイクロベンチマークを行うときに使用されます。CppCon2015でこれについて講演しました：https ://youtu.be/nXaxk27zwlk

ここに示されている手法は、Googleのようなさまざまなマイクロベンチマークライブラリによっても提供されています。https：//github.com/google/benchmark#preventing-optimization

これらの手法の鍵は、データに焦点を当てることです。計算への入力をオプティマイザに対して不透明にし、計算の結果をオプティマイザに対して不透明にします。これを実行したら、確実にタイミングを合わせることができます。元の質問の例の現実的なバージョンを見てみましょう。ただしfoo、実装から完全に見えるように定義されています。私はDoNotOptimizeここで見つけることができるGoogleベンチマークライブラリから（非ポータブル）バージョンも抽出しました：https : //github.com/google/benchmark/blob/master/include/benchmark/benchmark_api.h#L208

#include <chrono>

template <class T>
__attribute__((always_inline)) inline void DoNotOptimize(const T &value) {
  asm volatile("" : "+m"(const_cast<T &>(value)));
}

// The compiler has full knowledge of the implementation.
static int foo(int x) { return x * 2; }

auto time_foo() {
  using Clock = std::chrono::high_resolution_clock;

  auto input = 42;

  auto t1 = Clock::now();         // Statement 1
  DoNotOptimize(input);
  auto output = foo(input);       // Statement 2
  DoNotOptimize(output);
  auto t2 = Clock::now();         // Statement 3

  return t2 - t1;
}

ここで、入力データと出力データが計算の前後で最適化不可能としてマークされfoo、それらのマーカーの周りのみがタイミングが計算されるようにします。データを使用して計算を正確に把握しているため、2つのタイミングの間に留まることが保証されていますが、計算自体を最適化することができます。Clang / LLVMの最近のビルドによって生成された結果のx86-64アセンブリは次のとおりです。

% ./bin/clang++ -std=c++14 -c -S -o - so.cpp -O3
        .text
        .file   "so.cpp"
        .globl  _Z8time_foov
        .p2align        4, 0x90
        .type   _Z8time_foov,@function
_Z8time_foov:                           # @_Z8time_foov
        .cfi_startproc
# BB#0:                                 # %entry
        pushq   %rbx
.Ltmp0:
        .cfi_def_cfa_offset 16
        subq    $16, %rsp
.Ltmp1:
        .cfi_def_cfa_offset 32
.Ltmp2:
        .cfi_offset %rbx, -16
        movl    $42, 8(%rsp)
        callq   _ZNSt6chrono3_V212system_clock3nowEv
        movq    %rax, %rbx
        #APP
        #NO_APP
        movl    8(%rsp), %eax
        addl    %eax, %eax              # This is "foo"!
        movl    %eax, 12(%rsp)
        #APP
        #NO_APP
        callq   _ZNSt6chrono3_V212system_clock3nowEv
        subq    %rbx, %rax
        addq    $16, %rsp
        popq    %rbx
        retq
.Lfunc_end0:
        .size   _Z8time_foov, .Lfunc_end0-_Z8time_foov
        .cfi_endproc


        .ident  "clang version 3.9.0 (trunk 273389) (llvm/trunk 273380)"
        .section        ".note.GNU-stack","",@progbits

ここでは、コンパイラーが呼び出しをfoo(input)1つの命令に最適化していることを確認できますがaddl %eax, %eax、それをタイミングの外に移動したり、定数入力にもかかわらずそれを完全に削除したりすることはありません。

これがお役に立てば幸いです。C++標準委員会は、DoNotOptimizeここと同様にAPIを標準化する可能性を検討しています。

概要：

並べ替えを防ぐ保証された方法はないようですが、リンク時/完全なプログラムの最適化が有効になっていない限り、呼び出された関数を別のコンパイルユニットに配置するのはかなり良い方法のようです。（少なくともGCCでは、ロジックは他のコンパイラーでもそうであると示唆していますが）これは関数呼び出しを犠牲にして行われます-インラインコードは定義上、同じコンパイルユニット内にあり、並べ替えが可能です。

元の答え：

GCCは-O2最適化の下で呼び出しを並べ替えます：

#include <chrono>
static int foo(int x)    // 'static' or not here doesn't affect ordering.
{
    return x*2;
}
int fred(int x)
{
    auto t1 = std::chrono::high_resolution_clock::now();
    int y = foo(x);
    auto t2 = std::chrono::high_resolution_clock::now();
    return y;
}

GCC 5.3.0：

g++ -S --std=c++11 -O0 fred.cpp ：

_ZL3fooi:
        pushq   %rbp
        movq    %rsp, %rbp
        movl    %ecx, 16(%rbp)
        movl    16(%rbp), %eax
        addl    %eax, %eax
        popq    %rbp
        ret
_Z4fredi:
        pushq   %rbp
        movq    %rsp, %rbp
        subq    $64, %rsp
        movl    %ecx, 16(%rbp)
        call    _ZNSt6chrono3_V212system_clock3nowEv
        movq    %rax, -16(%rbp)
        movl    16(%rbp), %ecx
        call    _ZL3fooi
        movl    %eax, -4(%rbp)
        call    _ZNSt6chrono3_V212system_clock3nowEv
        movq    %rax, -32(%rbp)
        movl    -4(%rbp), %eax
        addq    $64, %rsp
        popq    %rbp
        ret

だが：

g++ -S --std=c++11 -O2 fred.cpp ：

_Z4fredi:
        pushq   %rbx
        subq    $32, %rsp
        movl    %ecx, %ebx
        call    _ZNSt6chrono3_V212system_clock3nowEv
        call    _ZNSt6chrono3_V212system_clock3nowEv
        leal    (%rbx,%rbx), %eax
        addq    $32, %rsp
        popq    %rbx
        ret

ここで、foo（）を外部関数として使用します。

#include <chrono>
int foo(int x);
int fred(int x)
{
    auto t1 = std::chrono::high_resolution_clock::now();
    int y = foo(x);
    auto t2 = std::chrono::high_resolution_clock::now();
    return y;
}

g++ -S --std=c++11 -O2 fred.cpp ：

_Z4fredi:
        pushq   %rbx
        subq    $32, %rsp
        movl    %ecx, %ebx
        call    _ZNSt6chrono3_V212system_clock3nowEv
        movl    %ebx, %ecx
        call    _Z3fooi
        movl    %eax, %ebx
        call    _ZNSt6chrono3_V212system_clock3nowEv
        movl    %ebx, %eax
        addq    $32, %rsp
        popq    %rbx
        ret

しかし、これが-flto（リンク時の最適化）でリンクされている場合：

0000000100401710 <main>:
   100401710:   53                      push   %rbx
   100401711:   48 83 ec 20             sub    $0x20,%rsp
   100401715:   89 cb                   mov    %ecx,%ebx
   100401717:   e8 e4 ff ff ff          callq  100401700 <__main>
   10040171c:   e8 bf f9 ff ff          callq  1004010e0 <_ZNSt6chrono3_V212system_clock3nowEv>
   100401721:   e8 ba f9 ff ff          callq  1004010e0 <_ZNSt6chrono3_V212system_clock3nowEv>
   100401726:   8d 04 1b                lea    (%rbx,%rbx,1),%eax
   100401729:   48 83 c4 20             add    $0x20,%rsp
   10040172d:   5b                      pop    %rbx
   10040172e:   c3                      retq

並べ替えは、コンパイラまたはプロセッサによって行われます。

ほとんどのコンパイラは、読み取り/書き込み命令の並べ替えを防ぐためのプラットフォーム固有の方法を提供します。gccでは、これは

asm volatile("" ::: "memory");

（詳細はこちら）

これは、読み取り/書き込みに依存している限り、間接的にのみ並べ替え操作を防止することに注意してください。

実際には、システムコールインClock::now()がこのようなバリアと同じ効果を持つシステムはまだ見ていません。結果として得られるアセンブリを検査して確認できます。

ただし、テスト中の関数がコンパイル時に評価されることは珍しくありません。「現実的な」実行を強制するにはfoo()、I / Oまたはvolatile読み取りからの入力を導出する必要がある場合があります。

別のオプションはfoo()、インライン化を無効にすることです。これもコンパイラ固有であり、通常は移植できませんが、同じ効果があります。

gccでは、これは __attribute__ ((noinline))

@Ruslanは根本的な問題を提起します：この測定はどの程度現実的ですか？

実行時間は多くの要因の影響を受けます。1つは実行中の実際のハードウェア、もう1つはキャッシュ、メモリ、ディスク、CPUコアなどの共有リソースへの同時アクセスです。

したがって、同等のタイミングを取得するために通常行うことは、エラーマージンが低くても再現可能であることを確認することです。これはそれらを幾分人工的にします。

「ホットキャッシュ」と「コールドキャッシュ」の実行パフォーマンスは、桁違いに簡単に異なる可能性がありますが、実際には、中間的なものになります（「ぬるい」ですか？）

C ++言語は、いくつかの方法で何が観察可能かを定義します。

foo()何も観察できない場合は、完全に排除できます。場合はfoo()、「ローカル」状態に格納値が（スタック上またはオブジェクトのどこかでそれをすること）という計算を行い、のみとコンパイラはそのノー安全由来のポインタが入ることができますことを証明することができClock::now()、コード、そして観察可能な結果にはありませんClock::now()通話を移動します。

場合はfoo()、ファイルやディスプレイ、およびコンパイラと相互作用することが証明できないClock::now()んではない、ファイルやディスプレイとの相互作用が観察できる動作であるため、実行することはできません並べ替え、ファイルやディスプレイとの対話。

コンパイラー固有のハックを使用して、コードが動き回らないようにすることができますが（インラインアセンブリーのように）、別のアプローチは、コンパイラーの裏をかこうとすることです。

動的に読み込まれるライブラリを作成します。問題のコードの前にロードします。

そのライブラリは1つのことを公開します。

namespace details {
  void execute( void(*)(void*), void *);
}

次のようにラップします：

template<class F>
void execute( F f ) {
  struct bundle_t {
    F f;
  } bundle = {std::forward<F>(f)};

  auto tmp_f = [](void* ptr)->void {
    auto* pb = static_cast<bundle_t*>(ptr);
    (pb->f)();
  };
  details::execute( tmp_f, &bundle );
}

これは、nullary lambdaをまとめ、動的ライブラリを使用して、コンパイラが理解できないコンテキストで実行します。

ダイナミックライブラリ内では、次のことを行います。

void details::execute( void(*f)(void*), void *p) {
  f(p);
}

とても簡単です。

ここで、への呼び出しを並べ替えるにはexecute、動的ライブラリを理解する必要があります。これは、テストコードのコンパイル中には理解できません。

それでもfoo()副作用はゼロでsを排除できますが、一部は勝ち、一部は失われます。

いいえ、できません。C ++標準[intro.execution]によると：

14全式に関連付けられているすべての値の計算と副作用は、評価される次の全式に関連付けられているすべての値の計算と副作用の前にシーケンスされます。

全式は、基本的にセミコロンで終了するステートメントです。上記のルールからわかるように、ステートメントは順番に実行する必要があります。これは、ある範囲内コンパイラはより多くの行動の自由を許可されていることを文（すなわち、それ以外の注文で文を作る式を評価することができ、いくつかの状況下にある左から右または何か他の特定）。

as-ifルールを適用するための条件がここでは満たされていないことに注意してください。システム時刻を取得するために呼び出しを並べ替えても、監視可能なプログラムの動作に影響がないことをコンパイラが証明できると考えるのは不合理です。観測された動作を変更せずに時間を取得するための2つの呼び出しを並べ替えることができる状況があった場合、これを確実に推測できるように十分に理解してプログラムを分析するコンパイラを実際に作成することは非常に非効率的です。

番号。

場合によっては、「as-if」ルールによって、ステートメントが並べ替えられることがあります。これは、それらが互いに論理的に独立しているからではなく、その独立性によって、プログラムのセマンティクスを変更することなく、そのような再配列を実行できるためです。

現在の時刻を取得するシステムコールを移動しても、明らかにその条件は満たされません。故意または無意識にそうするコンパイラは、非準拠であり、本当にばかげています。

一般的に、積極的に最適化するコンパイラでさえ、システムコールが「2番目に推測される」結果となる式は期待していません。それはそのシステムコールが何をするかについて十分に知らないだけです。

noinline 関数+インラインアセンブリブラックボックス+完全なデータ依存関係

これはhttps://stackoverflow.com/a/38025837/895245に基づいていますが、なぜ::now()がそこで並べ替えられないのかについて明確な正当化が見られなかったので、私はむしろ偏執的であり、それをnoinline関数の中に入れますasm。

この方法ではnoinline、the ::nowとdataの依存関係が「結び付いている」ため、並べ替えが発生しないと確信しています。

main.cpp

#include <chrono>
#include <iostream>
#include <string>

// noinline ensures that the ::now() cannot be split from the __asm__
template <class T>
__attribute__((noinline)) auto get_clock(T& value) {
    // Make the compiler think we actually use / modify the value.
    // It can't "see" what is going on inside the assembly string.
    __asm__ __volatile__ ("" : "+g" (value));
    return std::chrono::high_resolution_clock::now();
}

template <class T>
static T foo(T niters) {
    T result = 42;
    for (T i = 0; i < niters; ++i) {
        result = (result * result) - (3 * result) + 1;
    }
    return result;
}

int main(int argc, char **argv) {
    unsigned long long input;
    if (argc > 1) {
        input = std::stoull(argv[1], NULL, 0);
    } else {
        input = 1;
    }

    // Must come before because it could modify input
    // which is passed as a reference.
    auto t1 = get_clock(input);
    auto output = foo(input);
    // Must come after as it could use the output.
    auto t2 = get_clock(output);
    std::cout << "output " << output << std::endl;
    std::cout << "time (ns) "
              << std::chrono::duration_cast<std::chrono::nanoseconds>(t2 - t1).count()
              << std::endl;
}

GitHubアップストリーム。

コンパイルして実行：

g++ -ggdb3 -O3 -std=c++14 -Wall -Wextra -pedantic -o main.out main.cpp
./main.out 1000
./main.out 10000
./main.out 100000

このメソッドの唯一のマイナーな欠点は、メソッドに1つの追加のcallq命令を追加するinlineことです。objdump -CD以下をmain含むことを示します：

    11b5:       e8 26 03 00 00          callq  14e0 <auto get_clock<unsigned long long>(unsigned long long&)>
    11ba:       48 8b 34 24             mov    (%rsp),%rsi
    11be:       48 89 c5                mov    %rax,%rbp
    11c1:       b8 2a 00 00 00          mov    $0x2a,%eax
    11c6:       48 85 f6                test   %rsi,%rsi
    11c9:       74 1a                   je     11e5 <main+0x65>
    11cb:       31 d2                   xor    %edx,%edx
    11cd:       0f 1f 00                nopl   (%rax)
    11d0:       48 8d 48 fd             lea    -0x3(%rax),%rcx
    11d4:       48 83 c2 01             add    $0x1,%rdx
    11d8:       48 0f af c1             imul   %rcx,%rax
    11dc:       48 83 c0 01             add    $0x1,%rax
    11e0:       48 39 d6                cmp    %rdx,%rsi
    11e3:       75 eb                   jne    11d0 <main+0x50>
    11e5:       48 89 df                mov    %rbx,%rdi
    11e8:       48 89 44 24 08          mov    %rax,0x8(%rsp)
    11ed:       e8 ee 02 00 00          callq  14e0 <auto get_clock<unsigned long long>(unsigned long long&)>

fooインライン化されていることがわかりますが、インライン化get_clockされていません。

get_clock しかし、それ自体は非常に効率的で、スタックに触れない単一のリーフ呼び出し最適化命令で構成されています。

00000000000014e0 <auto get_clock<unsigned long long>(unsigned long long&)>:
    14e0:       e9 5b fb ff ff          jmpq   1040 <std::chrono::_V2::system_clock::now()@plt>

クロックの精度自体が制限されているため、1つの追加のタイミング効果に気付く可能性は低いと思いますjmpq。は共有ライブラリにあるcallため、いずれかが必要であることに注意してください::now()。

::now()データに依存するインラインアセンブリから呼び出す

これは可能な限り最も効率的なソリューションであり、jmpq上記の余分なものも克服します。

残念ながら、これを正しく実行することは非常に困難です。拡張インラインASMでのprintfの呼び出し

ただし、呼び出しなしでインラインアセンブリで直接時間測定を実行できる場合は、この手法を使用できます。これは、たとえば、gem5マジックインストルメンテーション命令、x86 RDTSC（これが代表的なものかどうか不明）、および場合によっては他のパフォーマンスカウンターの場合です。

関連スレッド：

• C ++オプティマイザがclock（）の呼び出しを並べ替えることは合法ですか？

GCC 8.3.0、Ubuntu 19.04でテスト済み。