Блог

Исходя в основном из опыта работы с Python, сейчас я изучаю как C, так и сборку x86-64. Ранее я использовал C косвенно через Cython, но теперь я изучаю собственно C в дополнение к сборке.

Мой основной вопрос заключается в том, какое мышление я должен поставить себе, когда дело доходит до оптимизации компиляторов. Должен ли я просто позволить компилятору выполнять свою работу, но, как только я достаточно разбираюсь в сборке, начать проверять и подтверждать вывод сборки? Это то, что делают ответственные программисты на C, желающие писать высокопроизводительный код?

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

• -O3 Были некоторые инструкции, которые я еще не изучил, например movaps XMMWORD PTR [rsp 0x10],xmm0
• Уровни -O2 и -O1 были несколько понятнее, но все же я не до конца понял это
• На уровне -O0 , я полагаю, я мог видеть довольно простой перевод кода, к которому, я думаю messages[idx] , действительно обращались дважды

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

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

 #include <stddef.h>
#include <stdio.h>

int main(int argc, char ** argv)
{
    size_t len_messages = 9;
    int messages[] = {1, 2, 3, 4, 5, 6, 7, 8, 9};

    for(size_t idx=0; idx < len_messages; idx  ) {
        printf("Accessing here %d and there %dn", messages[idx], messages[idx]);
    }

    return 0;
}
  

Мой основной вопрос заключается в том, какое мышление я должен поставить себе, когда дело доходит до оптимизации компиляторов. Должен ли я просто позволить компилятору выполнять свою работу, но, как только я достаточно разбираюсь в сборке, начать проверять и подтверждать вывод сборки?

В основном нет.

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

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

Однако «исследовать улучшения производительности» по-прежнему не обязательно означает переход непосредственно к сборке. Вы думаете об улучшении алгоритма, улучшении структур данных и локальности кэша, улучшении параллелизма («больше потоков!») И т. Д.

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

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

Чтобы обойти это, вам может понадобиться несколько разных версий на языке ассемблера для разных процессоров — одна для «64-разрядной Intel с AVX-512», одна для «64-разрядной Intel с AVX2», одна для «64-разрядной Intel без AVX», еще 2 версии для AMD, потому что выобнаружил, что несколько инструкций занимают больше времени на AMD, а несколько других инструкций выполняются быстрее на AMD; затем еще один набор разных версий для 64-разрядной ARM, затем PowerPC, затем…

В принципе; оптимизация в сборке встречается редко. Для «сильно загруженной» библиотеки (например, декодера MPEG, библиотеки больших чисел, …) это может иметь большой смысл, и для нескольких критически важных частей большой программы это может быть оправдано; но помимо этого, вероятно, у вас есть гораздо более важные дела с вашимвремя.

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