Комментарии 29
А итоги то какие, есть адекватные замеры где можно увидеть результат? А то тут недавно писали про студентов которые оптимизировали, оптимизировали, а что соптимизировали сказать не смогли: https://habr.com/ru/post/698988/
www.phoronix.com/news/GCC-12-PGO-TR-3990X-AMD
clang -O2 -fprofile-use=myprog.profdata
clang -O2 -profile-use=myprog.profdata
clang -O2 -profile-sample-use=myprog.profdata
Буковка f не потерялась в двух из трех?
Почему программа не может сама себя постоянно анализировать и адаптироваться под ситуацию, т.е. подправлять себя?
Слишком сложно? Постоянный анализ бьёт по производительности? Или современные ОС и антивирусы будут активно мешать самомодификации?
Это называется JIT-компиляция и она есть, например, в JVM и .NET
Вам в принципе никто не мешает вместе с программой тащить обёртку (и вроде как её даже не очень сложно написать), которая будет снимать профиль, запускать анализ, пересобирать программу из исходников с полученным профилем и далее перезапускать.
Кстати, заметил на страничке LLVM тулзу bolt. Кажется, появилась не очень давно. Судя по описанию, это почти то, что вы ищете, только не автоматизированное.
Буквально - снимаете профиль нагрузки (например, с помощью perf), а потом с помощью этого профиля и bolt обрабатываете бинарь. Получается другой бинарь, перелинкованный так, чтобы работать быстрее при данном профиле. Магия в том, что для этого не нужен ни компилятор, ни исходники. И даже бинарь может быть не прямо тот же самый, а какой-нибудь близкой версии.
Этот подход - "self-driven" - имеет место быть, например, в СУБД. https://noise.page/
Всё же какие-то замеры были бы кстати. А то вдруг у Вас как раз и вышло, что стало медленнее.
Замеры должны делать вы сами, все экспериментальные методы так и помечены в ядре, как экспериментальные. Т.е. вы их используете на свой страх и риск, и сами решаете нужно это вам или нет.
Вы делаете замеры на своей нагрузке и смотрите дает это вам выигрыш с вашей нагрузкой или нет.
Я эти утверждения уже видел в статье.
Вы же говорите, что, мол, наслаждайтесь оптимизированным(!) ядром, но как Вы это без замеров (на Ваших же задачах) можете утверждать? В этом и вопрос.
Эмм, Вы же написали статью про оптимизацию.
Я не автор заданного вам вопроса, но всё-таки вмешаюсь. Вы сказали, что есть некая pgo-оптимизация по умолчанию (текущая реализация), а вы её якобы ещё ускорили и предложили какой-то патч. Вот вас и спросили, а в чем конкретно ваше ускорение состоит?
>Скачайте патч по ссылке Патч PGO Оптимизация.
Вот в этом патче что конкретно ?
Если в кратце я добавил поддержку профиля llvm 13-14, оригинальная версия патча работала с профилем 12 версии, она собирала профиль, но при конвертации сырого профиля выскакивала ошибка т.к. формат профиля отличался.
После того как компания Google выпустила набор патчей для PGO оптимизации, мною была добавлена поддержка LLVM 13 и LLVM 14, т.к. в них менялся формат профиля и с оригинальными патчами clang его не понимает. Также файл профиля и сброса были перенесены из debugfs в proc для устранения проблем с включённым kernel_lockdown (man kernel_lockdown) в ядре Linux, который не даёт прочесть профиль. Данное изменение позволять профилировать ядро с включёнными системами безопасности ядра, без их отключения на этапе загрузки. Дополнительную информацию вы можете найти в файле Documentation/dev-tools/pgo.rst после применения патча ядра.
насчет
>> добавил поддержку профиля llvm 13-14
а в мейнстрим эти изменения никто не хочет добавить?
Что будет у меня не факт, что будет у вас.Так у вас никто не просит гарантий что у всех всё станет быстрее. Но писать статью об оптимизациях без цифр — это что-то крайне странное. Откуда вы знаете, что там что-то соптимизирорвалось? Может наоборот медленнее стало (примеров замедляющих «оптимизаций» навалом). Апелляция к авторитетам («Думаю создатели PGO оптимизации и компании производители программного обеспечения не дураки») тут не работает
Для удобства сравнения результатов можете использовать KDiff3 или Kompare.
arch/x86/tools/insn_decoder_test: warning: Found an x86 instruction decoder bug, please report this.
arch/x86/tools/insn_decoder_test: warning: ffffffff81d68bb2: f2 0f 78 c0 08 08 insertq $0x8,$0x8,%xmm0,%xmm0
arch/x86/tools/insn_decoder_test: warning: objdump says 6 bytes, but insn_get_length() says 0
А что это значит? Компиляция с профилем привела к ошибочным оптимизациям, из-за которых сломался встроенный в ядро декодер длин инструкций? Выглядит опасно, тогда ведь могло сломаться и другое место, но не покрытое такой проверкой.
Оптимизация это (почти) всегда хорошо, особенно если прирост в производительности ощутимый. А какой у Вас он в итоге получился и как производились измерения? Какой метод оптимизации сколько выжал? Просто самое основное не совсем очевидно из статьи.
Оставлю для истории ссылку на большее количество материалов о PGO, вдруг кому интересно будет: https://github.com/ZaMaZaN4iK/awesome-pgo
Выжимаем все соки: PGO Оптимизация ядра Linux