Обеспечение порядка операторов в C++

резюме:

кажется, нет гарантированного способа предотвратить переупорядочивание, но пока оптимизация времени связи/полной программы не включена,размещение вызываемой функции в отдельном блоке компиляции кажется довольно хорошей ставкой. (По крайней мере, с GCC, хотя логика предполагает, что это вероятно и с другими компиляторами.) Это происходит за счет функции call-inlined код по определению находится в том же блоке компиляции и открыт для переупорядочивание.

оригинальный ответ:

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    , %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    , %rsp
        popq    %rbp
        ret

но:

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

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

теперь, с foo () в качестве функции extern:

#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    , %rsp
        movl    %ecx, %ebx
        call    _ZNSt6chrono3_V212system_clock3nowEv
        movl    %ebx, %ecx
        call    _Z3fooi
        movl    %eax, %ebx
        call    _ZNSt6chrono3_V212system_clock3nowEv
        movl    %ebx, %eax
        addq    , %rsp
        popq    %rbx
        ret

но, если это связано с-flto (оптимизация времени связи):

0000000100401710 <main>:
   100401710:   53                      push   %rbx
   100401711:   48 83 ec 20             sub    x20,%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    x20,%rsp
   10040172d:   5b                      pop    %rbx
   10040172e:   c3                      retq

переупорядочивание может выполняться компилятором или процессором.

большинство компиляторов предлагают метод, специфичный для платформы, чтобы предотвратить переупорядочение инструкций чтения и записи. На gcc это

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

(подробнее здесь)

обратите внимание, что это только косвенно предотвращает операции переупорядочивания, если они зависят от чтения / записи.

на практике я еще не видел систему, где системный вызов в Clock::now() имеет тот же эффект, что такой барьер. Вы можете проверить полученную сборку, чтобы быть уверенным.

однако не редкость, что тестируемая функция оценивается во время компиляции. Чтобы обеспечить "реалистичное" выполнение, вам может потребоваться получить входные данные для foo() от ввода / вывода или volatile читать.

другой вариант-отключить встроенное для foo() - опять же, это специфичный компилятор и обычно не переносимый, но будет иметь то же самое эффект.

на gcc это будет __attribute__ ((noinline))

@Ruslan поднимает фундаментальный вопрос: насколько реалистично это измерение?

время выполнения зависит от многих факторов: один-это фактическое оборудование, на котором мы работаем, другой-одновременный доступ к общим ресурсам, таким как кэш, память, диск и ядра процессора.

Итак, что мы обычно делаем, чтобы получить сравнима тайминги: убедитесь, что они являются воспроизводимость С a низкая погрешность. Это делает их несколько искусственными.

производительность выполнения"горячего кэша" и "холодного кэша" может легко отличаться на порядок, но на самом деле это будет что - то среднее ("теплое"?)

язык C++ определяет, что можно наблюдать несколькими способами.

если foo() не делает ничего наблюдаемого, тогда его можно полностью устранить. Если foo() только вычисление, которое хранит значения в "локальном" состоянии (будь то в стеке или в объекте где-то),и компилятор может доказать, что никакой безопасно-производный указатель не может попасть в Clock::now() код, тогда нет никаких наблюдаемых последствий для перемещения Clock::now() звонки.

если foo() взаимодействовал с файлом или дисплей, и компилятор не может доказать, что Clock::now() тут не взаимодействовать с файлом или дисплеем, то переупорядочивание не может быть сделано, потому что взаимодействие с файлом или дисплеем является наблюдаемым поведением.

хотя вы можете использовать специфичные для компилятора хаки, чтобы заставить код не перемещаться (например, встроенная сборка), другой подход-попытаться перехитрить ваш компилятор.

создайте динамически загружаемую библиотеку. Загрузить его до код в вопрос.

эта библиотека раскрывает одну вещь:

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 );
}

который упаковывает нулевую лямбду и использует динамическую библиотеку для ее запуска в контексте, который компилятор не может понять.

внутри динамической библиотеки, мы делаем:

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

что довольно просто.

теперь, чтобы изменить порядок вызовов execute, он должен понимать динамическую библиотеку, которую он невозможно при компиляции тестового кода.

он все еще может ликвидировать foo()s с нулевыми побочными эффектами, но вы выигрываете некоторые, вы теряете некоторые.

нет, не может. Согласно стандарту C++ [вступление.исполнение]:

14 каждое вычисление значения и побочный эффект, связанный с полное выражение применяется перед каждым вычислением стоимости и побочных эффект, связанный со следующим полным выражением для оценки.

полное выражение-это в основном оператор, заканчивающийся точкой с запятой. Как вы можете видеть выше правило оговаривает заявления должны быть выполнены в порядке. Это внутри утверждения о том, что компилятору разрешено больше свободы действий (т. е. при некоторых обстоятельствах разрешено оценивать выражения, которые составляют оператор в порядках, отличных от слева направо или чего-либо еще конкретного).

обратите внимание, что здесь не выполняются условия для применения правила as-if. Неразумно думать, что любой компилятор сможет доказать что переупорядочивание вызовов для получения системного времени не повлияет на наблюдаемое поведение программы. Если было обстоятельство, в котором два вызова, чтобы получить время, могут быть переупорядочены без изменения наблюдаемого поведения, было бы крайне неэффективно фактически создать компилятор, который анализирует программу с достаточным пониманием, чтобы иметь возможность сделать это с уверенностью.

нет.

иногда, по правилу "как будто", операторы могут быть переупорядочены. Это не потому, что они логически независимы друг от друга, а потому, что эта независимость позволяет такие реорганизации происходят без изменения семантики программы.

перемещение системного вызова, который получает текущее время, очевидно, не удовлетворяет этому условию. Компилятор, который сознательно или неосознанно делает это, несовместим и действительно глупый.

В общем, я бы не ожидал, что любое выражение, которое приводит к системному вызову, будет" угадано " даже агрессивно оптимизирующим компилятором. Он просто не знает достаточно о том, что делает этот системный вызов.