Большое падение производительности с помощью gcc, возможно, связано с встроенным

Ответ 1

Превращение моих комментариев в ответ, потому что это превратилось в длинную дискуссию. Дискуссия показала, что проблема с производительностью чувствительна к выравниванию.

Есть ссылки на некоторые сведения о настройке в fooobar.com/tags/x86/..., включая руководство по оптимизации Intel и Agner Fog. Некоторые советы по оптимизации сборки Agner Fog в полной мере не применимы к Sandybridge и более поздним процессорам. Однако, если вы хотите получить информацию о низком уровне на конкретном процессоре, руководство по микроархитексу очень хорошее.

Без по крайней мере внешней ссылки на код, который я могу попробовать сам, я не могу сделать больше, чем ручную. Если вы не публикуете код anywher, вам понадобятся инструменты для профилирования/производительности процессора, такие как Linux perf или Intel VTune, чтобы отслеживать это в течение разумного промежутка времени.

В чате OP обнаружил кто-то другой, имеющий эту проблему, но с опубликованным кодом. Это, вероятно, та же проблема, что OP видит, и является одним из основных способов выравнивания кода для кэшей uop в стиле Sandybridge.

Там находится граница 32B в середине цикла в медленной версии. Инструкции, которые начинаются до граничного декодирования до 5 часов. Таким образом, в первом цикле uop cache обслуживает mov/add/movzbl/mov. Во втором цикле в текущей строке кэша осталось только один mov uop. Затем цикл 3-го цикла выдает последние два цикла цикла: add и cmp+ja.

Проблемный mov начинается с 0x..ff. Я предполагаю, что инструкции, которые охватывают границу 32B, входят в (одну из) кавычек uop для их начального адреса.

В быстрой версии итерация требует всего 2 цикла: тот же самый первый цикл, затем mov / add / cmp+ja во втором.

Если одна из первых четырех инструкций была длиннее одного байта (например, с помощью бесполезного префикса или префикса REX), проблем не было. В конце первой строки кэша не было бы нечетного человека, потому что mov начнется после границы 32B и станет частью следующей строки кэша uop.

AFAIK, сборка и проверка вывода разборки - это единственный способ использовать более длинные версии тех же инструкций (см. Agner Fog Optimization Assembly), чтобы получить границы 32B с кратным 4-ю дисками. Я не знаю о графическом интерфейсе, который показывает выравнивание собранного кода при редактировании. (И, очевидно, это делается только для рукописного asm и хрупка. Изменение кода вообще нарушит выравнивание руки.)

Вот почему руководство по оптимизации Intel рекомендует выравнивать критические петли до 32B.

Было бы здорово, если бы ассемблер мог запросить, чтобы предыдущие команды были собраны с использованием более длинных кодировок, чтобы вывести их на определенную длину. Может быть, пара директив .startencodealign/.endencodealign 32, чтобы применить дополнение к коду между директивами, чтобы завершить его на границе 32B. Это может сделать ужасный код, если он используется плохо.

Изменения в параметре inlining изменят размер функций, а другой код - на кратные 16B. Это похоже на изменение содержания функции: она становится больше и меняет выравнивание других функций.

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

Там компромисс. Это ухудшило бы производительность, чтобы выровнять каждую функцию до 64B (начало строки кэша). Плотность кодов снизилась бы, при этом было бы больше строк кэша для хранения инструкций. 16B хорош, так как это размер выборки/декодирования команды на самых последних процессорах.

Agner Fog содержит детали низкого уровня для каждого микроархата. Однако он не обновил его для Broadwell, но кеш-кеп, вероятно, не изменился со времен Sandybridge. Я предполагаю там один довольно небольшой цикл, который доминирует над временем выполнения. Я не уверен, что искать в первую очередь. Возможно, в "медленной" версии есть некоторые цели ветвления ближе к концу блока 32B кода (и, следовательно, ближе к концу кэширования uop), что приводит к значительному меньшему, чем 4 uops за такт, выходящим из интерфейса.

Посмотрите на счетчики производительности для "медленных" и "быстрых" версий (например, с помощью perf stat ./cmd) и посмотрите, не отличаются ли они. например гораздо больше промахов в кеше может указывать на ложное совместное использование строки кэша между потоками. Кроме того, профиль и посмотреть, есть ли новая "горячая точка" в "медленной" версии. (например, с perf record ./cmd && perf report в Linux).

Сколько uops/clock является "быстрой" версией? Если это выше 3, узкие места в интерфейсе (возможно, в кэше uop), которые чувствительны к выравниванию, могут быть проблемой. Либо это, либо L1/uop-cache пропускает, если различное выравнивание означает, что вашему коду требуется больше строк кэша, чем доступно.

В любом случае, это повторяется: использовать счетчики профилировщика/производительности, чтобы найти новое узкое место, которое имеет "медленная" версия, но "быстрая" версия этого не делает. Затем вы можете потратить время на разборку этого блока кода. (Не смотрите на выход gcc asm. Вам нужно увидеть выравнивание при разборке финального двоичного файла.) Посмотрите на границы 16B и 32B, так как предположительно они будут в разных местах между двумя версиями, и мы думаем что причина проблемы.

Выравнивание также может привести к сбою макро-fusion, если сравнение /jcc точно разделяет границу 16B. Хотя это маловероятно в вашем случае, так как ваши функции всегда выровнены с несколькими кратными 16B.

re: автоматизированные инструменты для выравнивания: нет, я не знаю ничего, что может смотреть на двоичный файл и рассказывать вам что-нибудь полезное о выравнивании. Хотелось бы, чтобы редактор показывал группы из 4-х и 32-битных границ вместе с вашим кодом и обновлялся при редактировании.

Intel IACA иногда может быть полезна для анализа цикла, но IIRC он не знает о принятых ветвях, и я думаю, t имеет сложную модель интерфейса, что, очевидно, является проблемой, если несоосность нарушает производительность для вас.

Ответ 2

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

Модификатор 'inline' не указывает, чтобы заставить функцию быть встроенной. Это дает компиляторам подсказку встроить функцию. Поэтому, когда критерии компилятора оптимизации вложения не будут удовлетворены тривиальными модификациями кода, функция, которая модифицируется встроенным, обычно скомпилируется в статическую функцию.

И есть одна вещь, которая делает проблему более сложной, вложенной встроенной оптимизацией. Если у вас встроенная функция fA, вызывающая встроенную функцию fB, выполните следующие действия:

inline void fB(int x, int y) {
    return x * y;
}

inline void fA() {
    for(int i = 0; i < 0x10000000; ++i) {
        fB(i, i+1);
    }
}

void main() {
    fA();
}

В этом случае мы ожидаем, что как fA, так и fB вложены. Но если криволинейный крикет не выполняется, производительность не может быть предсказуемой. То есть большие потери производительности происходят, когда inlining отключается относительно fB, но очень незначительные капли для fA. И вы знаете, что внутренние решения компилятора очень сложны.

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

На самом деле, в С#, я испытываю такое падение производительности. В моем случае падение производительности на 60% происходит, когда одна локальная переменная добавляется к простой функции вложения.

EDIT:

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