genge 6 окт 2017 в 12:29

Оптимизация C/C++ кода

3 мин

34K

C++*C*

-8

Комментарии 20

Einherjar 6 окт 2017 в 13:13

Эх, будто в 2008 год попал. Бумажные книги по разработке 3d игр, 0x5F3759DF, вычисление тригонометрических функций через ряд тейлора…

Akon32 6 окт 2017 в 13:30

следующий код может быть быстрее:
…
Еще лучше перемежать массивы:
...

Чем лучше? Получаем тот же вариант(1), что и со структурой.

Fil 6 окт 2017 в 13:48

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

Akon32 6 окт 2017 в 14:01

Мне кажется, что примеры 1 и 3 скомпилируются в идентичный код.

kosmos89 6 окт 2017 в 14:10

Нет уж, оба варианта не будут векторизованы.

Fil 6 окт 2017 в 14:41

Почему?

        movapd  xmm0, XMMWORD PTR [rsp+159880+rax]
        addpd   xmm0, XMMWORD PTR [rsp+79880+rax]
        add     rax, 16
        movaps  XMMWORD PTR [rsp-136+rax], xmm0

        movsd   xmm0, QWORD PTR [rdx+8]
        add     rdx, 24
        addsd   xmm0, QWORD PTR [rdx-8]
        movsd   QWORD PTR [rdx-24], xmm0

yleo 6 окт 2017 в 14:51

Потому-что «гладиолус». Гляньте код от icc.

kosmos89 6 окт 2017 в 15:42

Речь про первый и третий. Со вторым и так все понятно.

Fil 6 окт 2017 в 15:51

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

oYASo 6 окт 2017 в 13:39

Увы, все это уже не сильно актуально для современного C++. В современном мире плюсов нужно больше думать о своих структурах данных и алгоритмах, и в меньшей степени — о микрооптимизациях, о чем, в общем-то, говорят и сами разработчики языка.

Akon32 6 окт 2017 в 14:26

"Современный мир" разный. После того, как свои структуры данных и алгоритмы идеально реализованы и всё равно тормозят, можно дойти до микрооптимизаций.

yleo 6 окт 2017 в 14:24

Не стану минусовать статью, так как автор перевода точно не виноват.
Но, думаю, стоит пояснить, что тут не так.

Самое главное в оптимизации — это, конечно, результат. Примерно по секундомеру или по количеству необходимой памяти. Беда в том, что "просто оптимизация", особенно описываемые механические приёмы/трюки, быстро приводят к попыткам оптимизировать "всё что плохо лежит".

Выходит даже не преждевременная оптимизация, а это code style — часто очень трудно читаемый.
В таком code style можно написать пару тысяч строк кода, потом будет просто трудно и неудобно. Иногда это оправдано и даже дано. Например, разработчики привыкшие делать именно так, могут автоматически сделать супер-быстрым почти любой код (по любому ТЗ). Но не дай бог, чтобы такого кода было много — его реально сложно поддерживать, дорабатывать, верифицировать, высока вероятность внесения дефектов и т.д. Тем не менее, это не основное "зло" в статье, это побочный эффект.

Главное в оптимизации — правильный вкус: чувство меры и ощущения стиля одновременно. Это трудно достижимый навык, некий дзен, мастерство в искусстве. Уже было много раз составлялись всяческие своды правил и/или наборы механических приёмов — результаты плачевны (хотя точно больше нуля). Более того, получить чувство меры невозможно без набивания достойных шишек.

Собственно, основной принцип оптимизации давно озвучил Буонарроти = уберите лишнее. Просто избавьте машину от лишней работы.

А вот тут внезапно выясняется, что для понимания "лишнего" нужно хорошо представлять как работает машина: всяческие кэш-линии, MESI, зависимости по данным в конвейере u-ops, что делает оптимизирующий компилятор, зачем те или иные конструкции языка, когда/зачем/как случается векторизация, и ещё очень-очень много. И убирать нечно "лишнее" нужно там, где оно действительно лишнее, но не поворачивать реки.

Так вот, основной минус этой статьи в том, что вместо понимания "как на самом деле" по-большей части предлагается культ Карго (делайте так и будет вам счастье).