https://www.opennet.ru/openforum/vsluhforumID3/122094.html После шести месяцев разработки представлен релиз проекта LLVM 11.0 - GCC-совместимого инструментария (компиляторы, оптимизаторы и генераторы кода), компилирующего программы в промежуточный биткод RISC-подобных виртуальных инструкций (низкоуровневая виртуальная машина с многоуровневой системой оптимизаций). Сгенерированный псевдокод может быть преобразован при помощи JIT-компилятора в машинные инструкции непосредственно в момент выполнения программы...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=53874<br> https://www.opennet.ru/openforum/vsluhforumID3/122094.html#89 Tue, 27 Oct 2020 12:03:52 GMT Не мог пройти мимо и не потыкать палочкой :)<br>Проверка Clang 11 с помощью PVS-Studio - https://habr.com/ru/company/pvs-studio/blog/525248/<br> https://www.opennet.ru/openforum/vsluhforumID3/122094.html#88 Wed, 21 Oct 2020 09:44:10 GMT &gt; Как насчёт pgo? Все эти ручные твики на редкость не универсальны. А <br>&gt; сам компилятор туп, как пробка. Поэтому ему нужны статы для эффективной <br>&gt; оптимизации, шланг уделает.<br><br>В данном конкретном случае Clang (безо всяких твиков!) выполнил во время трансляции то что происходит при профилировке. Посчитал количество вызовов нескольких мелких функций (они все вызываются в циклах) и тело самой часто вызываемой подставил в место вызова. <br><br>&gt; А lto в целом вещь довольно бесполезная (практически). <br><br>Её не от нечего делать прикрутили. Лет 15 назад на паре call+ret была сушественная просадка по скорости, потому инлайн мелких функций из другой единицы трансляции давал заметный выигрыш.<br> https://www.opennet.ru/openforum/vsluhforumID3/122094.html#87 Wed, 21 Oct 2020 07:51:31 GMT Как насчёт pgo? Все эти ручные твики на редкость не универсальны. А сам компилятор туп, как пробка. Поэтому ему нужны статы для эффективной оптимизации, шланг уделает. А lto в целом вещь довольно бесполезная (практически).<br> https://www.opennet.ru/openforum/vsluhforumID3/122094.html#86 Sun, 18 Oct 2020 05:46:25 GMT Ну да, я не понял, какое отношение имеет оптимизация графа вызовов (когда оптимизатор на основании количества вызовов решает, что вот этот вызов функции надо заинлайнить, а вон те - не надо) к целевому коду и его внутреннему представлению? <br> https://www.opennet.ru/openforum/vsluhforumID3/122094.html#85 Sun, 18 Oct 2020 05:38:14 GMT &gt; Вероятно, она объявлена не static и visibilty для DSO оставлен по-умолчанию, что <br>&gt; заставляет GCC допускать возможность переопределения функции в другом DSO.<br><br>Проверил гипотезу так:<br>объявил задействованные функции как static inline;<br>включил #include *.c с их определением в одну единицу трансляции, откуда происходит вызов;<br>добавил к -flto вот такое: -finline-limit=200000 --param inline-unit-growth=10000 -fwhole-program<br><br>Не инлайнит.<br><br>Clang инлайнит с -flto и без вышеуказанных манипуляций.<br><br>[code]<br>// сюда передаётся указатель на функцию, и отсюда осуществляется вызов.<br>/**<br> * \param painter изменяет цвет вершин, либо NULL для раскрашивания в базовый цвет<br> */<br>static inline<br>void poly_draw(const struct polygon *p, struct vec4 coordinate,<br> fn_painter painter, struct color color, struct draw_ctx *restrict ctx);<br><br>// вот на что передаётся указатель<br>static inline __attribute__((always_inline))<br>void colorer(struct vertex *restrict vert, struct color src, unsigned i)<br>{<br> i https://www.opennet.ru/openforum/vsluhforumID3/122094.html#84 Sat, 17 Oct 2020 14:55:19 GMT &gt;&gt;&gt;&gt; Т.е не ясно, почему 1й вариант, а не 2й.<br>&gt;&gt;&gt; Там четыре варианта в зависимости от целевого ядра.<br>&gt;&gt;&gt; Поиграйтесь флагом -march на https://godbolt.org/z/j9q4oG <br>&gt;&gt; <br>&gt;&gt;Так варианты машинного кода не объясняют причину, почему выбрана именно такая. В моём случай "ясно", это когда я найду что-то вроде: <br>&gt; Ну как-бы очевидно что компилятор руководствуется подобными правилами, которые более-менее <br>&gt; скрупулезно закодированные у него внутри.<br><br>Так вопрос в том, насколько эти правила адекватны железу. Когда-то мне приходилось писать __asm nop, что бы MSVC не разворачивал цикл. Этот ноп давал +10% скорости.<br><br>&gt; С явным описанием таких правил у Штеуда достаточно плохо, по многим инструкциям <br>&gt; нет даже базовой информации.<br><br>А где разработчики GCC их взяли? Может они изучают код после Intel C Compiler, или получают эмпирически? Посмотрел бумажное издание Optimization Manual, там раздел "General Optimization" почти в сотню страниц, а в текущей версии на четверть сокращён (правда, и ядра другие), вероятно, в п https://www.opennet.ru/openforum/vsluhforumID3/122094.html#83 Sat, 17 Oct 2020 14:49:55 GMT n00by, erthink, Аноним84701 - втроём полнедели обсуждали обсуждали да таки ничего не поняли.<br>Тсс!!! только не говорите им, что ассемблер синтаксиса AT&T в GCC просто и гениально превращяется в машинный код.<br> https://www.opennet.ru/openforum/vsluhforumID3/122094.html#82 Fri, 16 Oct 2020 12:45:56 GMT &gt;&gt;&gt; Т.е не ясно, почему 1й вариант, а не 2й.<br>&gt;&gt; Там четыре варианта в зависимости от целевого ядра.<br>&gt;&gt; Поиграйтесь флагом -march на https://godbolt.org/z/j9q4oG<br>&gt;<br>&gt;Так варианты машинного кода не объясняют причину, почему выбрана именно такая. В моём случай "ясно", это когда я найду что-то вроде:<br><br>Ну как-бы очевидно что компилятор руководствуется подобными правилами, которые более-менее скрупулезно закодированные у него внутри.<br>С явным описанием таких правил у Штеуда достаточно плохо, по многим инструкциям нет даже базовой информации.<br>Если хотите поднатореть в этом больше чем позволяют официальные штеуд-мануалы и (например) рекомендации Agner Fog, то это болезненный и малополезный путь.<br><br>&gt; Почему GCC не заинлайнил функцию из 5-ти строк, вызываемую из единственного места, загадка.<br><br>Чудес не бывает.<br>Вероятно, она объявлена не static и visibilty для DSO оставлен по-умолчанию, что заставляет GCC допускать возможность переопределения функции в другом DSO.<br>Либо еще какие-то проблемы с опциями оптимизации https://www.opennet.ru/openforum/vsluhforumID3/122094.html#81 Fri, 16 Oct 2020 10:07:37 GMT &gt;&gt; Т.е не ясно, почему 1й вариант, а не 2й.<br>&gt; Там четыре варианта в зависимости от целевого ядра.<br>&gt; Поиграйтесь флагом -march на https://godbolt.org/z/j9q4oG <br><br>Так варианты машинного кода не объясняют причину, почему выбрана именно такая. В моём случай "ясно", это когда я найду что-то вроде:<br><br>Assembly/Compiler Coding Rule 35. (M impact, ML generality) Use dependency-breaking-idiom<br>instructions to set a register to 0, or to break a false dependence chain resulting from re-use of<br>registers. In contexts where the condition codes must be preserved, move 0 into the register instead.<br>This requires more code space than using XOR and SUB, but avoids setting the condition codes.<br><br>&gt;&gt; На массиве нулей. А если данные случайны? На каждом одном слове из <br>&gt;&gt; 256, то есть 1/256 такта. При этом кеш инструкций расходуется непропорционально.<br>&gt; Тут "трусы vs крестик".<br>&gt; Если gcc опросили -Ofast он делает быстрее, если -Os то компактнее.<br>&gt; При необходимости более оптимального решения нужно использовать PGO, либо раз