бенчмаркинг, переупорядочение кода, изменчивый

Вы можете сделать два файла C, SlowCalculation составлено с g++ -O3 (высокий уровень оптимизации) и эталонный тест, скомпилированный с g++ -O1 (более низкий уровень, все еще оптимизированный — этого может быть достаточно для этой части бенчмаркинга).

Согласно справочная страница, переупорядочение кода происходит во время -O2 а также -O3 уровни оптимизации.

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

Предполагая, что вы используете g++ — но должно быть что-то эквивалентное в другом компиляторе.

Обычный способ предотвратить переупорядочение — это барьер компиляции, т.е. asm volatile ("":::"memory"); (с gcc). Это asm-инструкция, которая ничего не делает, но мы сообщаем компилятору, что она захлопнет память, поэтому не разрешается переупорядочивать код через нее. Стоимость этого является только фактической стоимостью удаления повторного заказа, что, очевидно, не относится к изменению уровня оптимизации и т. Д., Как предлагается в другом месте.

я верю _ReadWriteBarrier эквивалентно для вещей Microsoft.

Согласно ответу Максима Егорушкина, изменение порядка вряд ли станет причиной ваших проблем.

Правильный способ сделать это в C ++ — это использовать учебный класс, например что-то вроде

class Timer
{
std::clock_t startTime;
std::clock_t* targetTime;

public:
Timer(std::clock_t* target) : targetTime(target) { startTime = std::clock(); }
~Timer() { *target = std::clock() - startTime; }
};

и используйте это так:

std::clock_t slowTime;
{
Timer timer(&slowTime);
int answer = SlowCalculation(42);
}

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

Volatile обеспечивает одну вещь и только одну: чтение из переменной volatile будет считываться из памяти каждый раз — компилятор не будет предполагать, что значение может быть кэшировано в регистре. И точно так же, записи будут записаны в память. Компилятор не будет хранить его в регистре «некоторое время, прежде чем записать его в память».

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

_ReadWriteBarrier () — полный забор

_ReadBarrier () — двусторонний забор для грузов

_WriteBarrier () — двусторонний забор для магазинов

ICC включает в себя __memory_barrier () полный забор.

Полные заборы обычно являются лучшим выбором, потому что нет необходимости в более тонкой детализации на этом уровне (заборы компилятора в основном не требуют затрат во время выполнения).

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

Предложит прочитать http://preshing.com/20120625/memory-ordering-at-compile-time чтобы увидеть потенциальные проблемы, с которыми мы можем столкнуться при переупорядочении компилятора и т. д.

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

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

Другая возможность состоит в том, чтобы сделать функцию SlowCalculation(42); extern функция (определите эту функцию в отдельном файле .c / .cpp и свяжите файл с вашей основной программой) и объявите start а также stop как глобальные переменные. Я не знаю, каковы оптимизации, предлагаемые оптимизатором времени компоновки / компоновки.

Кроме того, если вы компилируете в O1 или O0, скорее всего, компилятор не будет беспокоиться о переупорядочении команд.
Ваш вопрос несколько связан с (Барьеры времени компиляции — переупорядочение кода компилятора — gcc и pthreads)

Переупорядочение, описанное вашим коллегой, просто ломается 1.9 / 13

Последовательность перед — это асимметричное, транзитивное, попарное отношение между оценками, выполненными одним
поток (1.10), который вызывает частичный порядок среди этих оценок. Учитывая любые две оценки A и B, если
Последовательность A предшествует B, тогда выполнение A должно предшествовать выполнению B. Если A не упорядочено до
B и B не секвенируются до A, тогда A и B не секвенируются. [Примечание: выполнение непоследовательного
оценки могут совпадать. — конец примечания] Оценки A и B имеют неопределенную последовательность, когда либо A
секвенируется до того, как B или B секвенируется до A, но не указано, какой именно. [Примечание: неопределенно
последовательные оценки не могут перекрываться, но любая из них может быть выполнена первой. —Конечная записка]

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